Sous-parcours

Des sous-parcours peuvent être utilisés pour organiser et simplifier le déroulement des étapes d’orchestration dans un parcours utilisateur. Les parcours utilisateur spécifient des chemins explicites par le biais desquels une stratégie autorise une application par partie de confiance à obtenir les revendications souhaitées pour un utilisateur. L’utilisateur est guidé par ces chemins pour récupérer les revendications qui doivent être présentés à la partie de confiance. Autrement dit, les parcours utilisateur définissent la logique métier de ce par quoi passe un utilisateur final pendant que l’Infrastructure d’expérience d’identité Azure AD B2C traite la requête. Un parcours utilisateur est représenté en tant que séquence d’orchestration qui doit être suivie pour que la transaction réussisse. L’élément ClaimsExchange d’une étape d’orchestration est lié à un seul profil technique qui s’exécute.

Un sous-parcours est un regroupement d’étapes d’orchestration qui peuvent être appelées à tout moment dans un parcours utilisateur. Vous pouvez utiliser des sous-parcours pour créer des séquences d’étapes réutilisables ou implémenter la création de branche pour mieux représenter la logique métier.

Section d’un parcours utilisateur

Les sous-parcours se comportent comme des parcours utilisateur, car ils sont représentés comme une séquence d’orchestration qui doit être suivie pour une transaction réussie. Les parcours utilisateur peuvent être appelés eux-mêmes et nécessiter l’exécution d’une étape SendClaims. Les sous-parcours sont des composants de parcours utilisateur qui ne peuvent pas être appelés de façon indépendante, et sont toujours appelés à partir d’un parcours utilisateur.

Le composant clé de la ramification consiste à permettre un meilleur traitement de logique métier dans un parcours utilisateur. Les étapes courantes d’orchestration sont regroupées en éléments individuels à appeler séparément. Un sous-parcours peut simplifier un parcours dans lequel plusieurs étapes d’orchestration sont couplées (qui ont les mêmes conditions préalables). Un sous-parcours est appelé uniquement à partir d’un parcours utilisateur, il ne doit pas appeler un autre sous-parcours.

Il existe deux types de sous-parcours :

• Appel : retourne le contrôle à l’appelant. Le sous-parcours s’exécute, puis le contrôle est renvoyé à l’étape d’orchestration en cours d’exécution dans le parcours utilisateur.
• Transfert : transfère le contrôle au sous-parcours (section irréversible). Le sous-parcours doit avoir une étape SendClaims pour renvoyer les revendications à l’application de partie de confiance.

Exemples de scénarios

Sous-parcours d’appel

Un sous-parcours d’appel est utile dans les scénarios suivants :

• Vérification de l’âge : Pour une vérification de l’âge, il existe de nombreux composants partagés parmi les parcours utilisateur. La section permet de compiler les éléments communs en composants partageables.
• Consentement parental : La création de branche permet de faciliter la conception du consentement parental en nous permettant d’accéder aux revendications de l’utilisateur au cours de l’exécution mineure, en même temps que la possibilité de brancher un parcours utilisateur de consentement après avoir trouvé l’utilisateur doit donner son consentement.
• De l’inscription à la connexion : Imaginez un scénario dans lequel un utilisateur existe déjà dans le répertoire, mais il a peut-être oublié qu’il avait en fait créé un compte. Il peut être souhaitable, dans ce cas, qu’au lieu de demander à l’utilisateur que les informations d’identification qu’il a entrées existent déjà et de forcer l’utilisateur à redémarrer le trajet, la stratégie soit en mesure d’effectuer un basculement d’un acheminement d’inscription vers un Flow de connexion pour cet utilisateur.

Sous-parcours de transfert

Un sous-parcours de transfert est utile dans les scénarios suivants :

• Présentation d’une page de bloc.
• Test A/B en acheminant la requête vers un sous-parcours pour exécuter et émettre un jeton.

Ajout d’un élément sous-parcours

L’exemple suivant illustre un élément SubJourney de type Call, qui renvoie le contrôle au parcours utilisateur.

<SubJourneys>
  <SubJourney Id="ConditionalAccess_Evaluation" Type="Call">
    <OrchestrationSteps>
      <OrchestrationStep Order="1" Type="ClaimsExchange">
       <ClaimsExchanges>
        <ClaimsExchange Id="ConditionalAccessEvaluation" TechnicalProfileReferenceId="ConditionalAccessEvaluation" />
       </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="2" Type="ClaimsExchange">
        <Preconditions>
          <Precondition Type="ClaimsExist" ExecuteActionsIf="false">
            <Value>conditionalAccessClaimCollection</Value>
            <Action>SkipThisOrchestrationStep</Action>
          </Precondition>
        </Preconditions>
        <ClaimsExchanges>
          <ClaimsExchange Id="GenerateCAClaimFlags" TechnicalProfileReferenceId="GenerateCAClaimFlags" />
        </ClaimsExchanges>
      </OrchestrationStep>
    </OrchestrationSteps>
  </SubJourney>
</SubJourneys>

L’exemple suivant illustre un élément SubJourney de type Transfer, qui renvoie le jeton à l’application par partie de confiance.

<SubJourneys>
  <SubJourney Id="B" Type="Transfer">
    <OrchestrationSteps>
      ...
      <OrchestrationStep Order="5" Type="SendClaims">
    </OrchestrationSteps>
  </SubJourney>
</SubJourneys>

Appeler une étape de sous-parcours

Une nouvelle étape d’orchestration de type InvokeSubJourney est utilisée pour exécuter un sous-parcours. Voici un exemple qui montre tous les éléments d’exécution de cette étape d’orchestration.

<OrchestrationStep Order="5" Type="InvokeSubJourney">
  <JourneyList>
    <Candidate SubJourneyReferenceId="ConditionalAccess_Evaluation" />
  </JourneyList>
</OrchestrationStep>

Composants

Pour définir les sous-parcours que la stratégie prend en charge, ajoutez un élément Sous-parcours sous l’élément de niveau supérieur du fichier de stratégie.

L’élément SubJourneys contient l’élément suivant :

Élément	Occurrences	Description
Sous-parcours	1:n	Sous-parcours utilisateur qui définit toutes les constructions nécessaires pour un flux utilisateur complet.

L’élément SubJourneys contient les attributs suivants :

Attribut	Obligatoire	Description
Id	Oui	Identificateur de sous-parcours que le parcours utilisateur peut utiliser pour référencer le sous-parcours dans la stratégie. L’élément SubJourneyReferenceId de l’élément Candidate pointe vers cet attribut.
Type	Oui	Valeurs possibles : Call ou Transfer. Pour plus d’informations, consultez Branche de parcours utilisateur

L’élément SubJourney contient l’élément suivant :

Élément	Occurrences	Description
OrchestrationSteps	1:n	Séquence d’orchestration qui doit être suivie pour que la transaction réussisse. Chaque parcours utilisateur est composé d’une liste ordonnée d’étapes d’orchestration qui sont exécutées de manière séquentielle. Si une étape échoue, la transaction échoue.

OrchestrationSteps

Pour obtenir la liste complète des éléments de l’étape d’orchestration, consultez UserJourneys.

Étapes suivantes

Découvrir les Sous-parcours