Flows/Actions: What level of Granularity?

[Cantor, Scott]

On 1/22/14, 7:56 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>Consider the CryptoPrincipal.  We need to
>
>1) Get the Id from the NameID (or NameIdentifier)
>2) Decode it
>3) Parse it
>4) Check the NameQualifier
>5) Check the SPNameQualifier
>6) Check the responderId
>7) Set the principal
>
>So is this best set up one action, or seven, or some number in between.  I
>strikes me that (1) needs to be separate (so we can easily build the SAML1
>and SAML2 flows) and off the top of my head I'd put (2,3) and (4,5,6)
>together and again leave (7) separate.  That way (1, 4-5-6, 7) can be
>shared
>amongst all flows.  I guess we can put 4,5,6 and 7 together as well.

Honestly I probably would do it as one action, or at most split off (1),
but then you have to have some place to store the intermediate value. One
way to avoid that is to use a strategy function to get the ID and have it
take a SAMLObject. Then install a default one that can pull from either
type of Name* object.

>A supplementary question is whether it would be usual to have a distinct
>subcontext to carry information between these actions?

That's exactly why I would avoid decomposition unless it's unavoidable. My
view was that we'd best share code between the legacy PrincipalConnectors
and the flow versions by just pushing the logic behind an interface and
having a single action that called into that interface for the flow
version.

-- Scott