Pour modéliser une Business Transaction, vous créez un processus ayant le stéréotype <<BusinessTransaction>>.
Les attributs étendus suivants (accessibles sur l'onglet Attributs étendus de la feuille de propriétés du processus) s'appliquent au processus BusinessTransaction :
|
Nom |
Description |
|---|---|
|
Requiert une livraison garantie |
Tous les partenaires acceptent d'utiliser un moyen de transport qui garantit la livraison. Valeur par défaut : false Nom dans le script : IsGuaranteedDeliveryRequired |
|
Pré-conditions |
[BPSS 1.01] Description d'un état externe à cette transaction et qui est requis avant que cette transaction ne puisse commencer. Nom dans le script : preConditions |
|
Post-conditions |
[BPSS 1.01] Description d'un état qui n'existe pas avant l'exécution de cette transaction, mais qui existera à l'issue de l'exécution de cette transaction. Nom dans le script : postConditions |
|
Commence quand |
[BPSS 1.01] Description d'un événement externe à la collaboration/transaction et qui provoque normalement le début de cette collaboration/transaction. Nom dans le script : beginsWhen |
|
Se termine quand |
[BPSS 1.01] Description d'un événement externe à la collaboration/transaction et qui provoque normalement la fin de cette collaboration/transaction. Nom dans le script : endsWhen |
|
Requiert un transport sécurisé |
[BPSS 1.04] Tous les partenaires acceptent d'échanger les informations métiers via un canal sécurisé. Les contrôles de sécurité s'assurent que le contenu du document métiers et les services concernés sont protégés contre les accès non autorisés. Ceci est une condition de la sécurité point-à-point. On note que cette condition ne protège pas l'information métiers en dehors du réseau et au sein de l'entreprise. Nom dans le script : IsSecureTransportRequired |
|
Motif |
[BPSS 1.04] Le nom du motif (optionnel) sur lequel se base cette BT. Nom dans le script : Pattern |
Requesting et Responding Business Activities
Le processus BusinessTransaction est un processus composite doté d'un sous-diagramme qui modélise les échanges de signaux métiers entre partenaires. Ce sous-diagramme contient une Responding Business Activity (un processus avec le stéréotype <<RespondingBusinessActivity>>) et une Requesting Business Activity (un processus avec le stéréotype <<RequestingBusinessActivity>>) :
Les signaux sont modélisés à l'aide de flux entre les activités demandeur (Requesting) et répondeur (Responding). Les stéréotypes de flux <<ReceiptAck>> et <<AcceptanceAck>> permettent de modéliser un Receipt Acknowledgment Signal et un Acceptance Acknowledgment Signal. Request Document et Response Document sont également modélisés à l'aide de flux ayant des formats de message qui modélisent le format de document.
Les attributs étendus suivants (accessibles sur l'onglet Attributs étendus de la feuille de propriétés du processus) s'appliquent à la fois aux processus RequestingBusinessActivity et RespondingBusinessActivity :
|
Nom |
Description |
|---|---|
|
Requiert une autorisation |
Si le partenaire nécessite une autorisation pour faire une requête ou répondre à une requête, alors le partenaire qui envoie doit signer le document métiers échangé et l'autre partenaire doit valider et approuver l'autorisation. Le partenaire sollicité doit signaler une exception si l'autre partenaire n'est pas autorisé à exécuter la Business Activity. Le partenaire demandeur doit envoyer une notification d'échec d'autorisation si l'autre partenaire n'est pas autorisé à répondre à sa requête. Valeur par défaut : false Nom dans le script : IsAuthorizationRequired |
|
Requiert une vérification intelligible |
Le partenaire receveur doit vérifier que le document envoyé n'est pas altéré (non lisible, non compréhensible) avant d'envoyer un accusé de réception. Valeur par défaut : false Nom dans le script : IsIntelligibleCheckRequired |
|
Requiert une non répudiation |
Si l'origine et le contenu du document métiers ne peuvent être répudiés, la Business Activity doit sauver le document métiers sous sa forme initiale durant tout le temps agréé par les partenaires. Le partenaire sollicité doit signaler une exception métiers si l'autre partenaire n'a pas envoyé proprement son document métiers. Le partenaire demandeur doit envoyer une notification d'échec dû aux règles métiers si l'autre partenaire n'a pas envoyé correctement son document métiers. Valeur par défaut : false Nom dans le script : IsNonRepudiationRequired |
|
Requiert un certificat de non répudiation |
Tous les partenaires acceptent de vérifier mutuellement la réception des documents métiers envoyés et de ne pas les répudier. Le partenaire destinataire envoie une notification d'échec (qui peut être l'annulation de l'offre contractuelle) si l'autre partenaire n'a pas correctement envoyé son document métiers. La non répudiation de la réception met en oeuvre les contrôles suivants : Vérification de l'identité du rôle répondeur (authentification) – Vérifie l'identité du rôle répondeur (individu ou organisation) qui a reçu le document métiers demandeur Vérification de l'intégrité du contenu – Vérifie l'intégrité du contenu d'origine de la demande de document métiers. Valeur par défaut : false Nom dans le script : isNonRepudiationReceiptRequired |
|
Heure d'accusé réception de l'acceptation |
L'intervalle de temps dont dispose le répondeur pour accepter le document métiers. Nom dans le script : TimeToAcknowledgeAcceptance (specific to the Requesting Activity) |
|
Heure d'accusé réception |
L'intervalle de temps dont dispose le répondeur pour accuser réception du document métiers. Nom dans le script : TimeToAcknowledgeReceipt |
|
Nombre de tentatives supplémentaires |
Nombre de tentatives autorisées par les règles métiers. Valable pour l'activité demandeur et disponible uniquement pour BPSS 1.04. Valeur par défaut : false Nom dans le script : retryCount |
Une boîte à outils spécifique à ebXML permet de créer directement un processus composite Business Transaction dans le diagramme courant et d'initialiser le processus composite avec des activités Requesting et Responding. Le tableau suivant récapitule les flux distincts qui existent entre l'activité demandeur (Requesting) et l'activité répondeur (Responding) :
Enveloppe de document (Document Envelope)
Une enveloppe de document (Document Envelope) transporte des informations métiers entre les deux rôles dans une Business Transaction. Une enveloppe de document convoie la demande émanant du rôle demandeur vers le rôle répondeur, et une autre enveloppe de document convoie le cas échéant la réponse du rôle répondeur vers le rôle demandeur. Ce concept est modélisé à l'aide d'un flux et d'un format de message dans le Modèle de Processus Métiers.
Les attributs étendus suivants (accessibles dans l'onglet Attributs étendus de la feuille de propriétés du format de message) s'appliquent à l'enveloppe de document :
|
Nom |
Description |
|---|---|
|
DocTypeDocumentation |
Documentation de DocumentType. Nom dans le script : DocTypeDocumentation |
|
Est une réponse positive |
Si TRUE, l'enveloppe de document fait office de réponse positive à la demande. Ce paramètre n'est pertinent que sur l'enveloppe de réponse. Nom dans le script : IsPositiveResponse |
|
Est authentifié |
Un certificat électronique est associé au document. Ceci constitue une preuve de l'identité du signataire. Valeur par défaut : false Nom dans le script : isAuthenticated |
|
Est confidentiel |
Le document est crypté afin d'interdire des accès non autorisés à l'information. Valeur par défaut : false Nom dans le script : isConfidential |
|
Est infalsifiable |
Le document possède une empreinte cryptée du message qui permet de vérifier que le message n'a pas subi de violation. Ceci implique une signature électronique (un certificat électronique de l'envoyeur et l'empreinte cryptée du message) associée au Document. Valeur par défaut : false Nom dans le script : isTamperProof |