Modélisation d'une Business Transaction

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. Le tableau suivant montre quels sont les attributs disponibles pour le langage de processus ebXML BPSS 1.01 ou ebXML BPSS 1.04 :

Nom	Code interne	Description	BPSS 1.01	BPSS 1.04
Requiert une livraison garantie	IsGuaranteedDeliveryRequired (true \| false) "false"	Tous les partenaires acceptent d'utiliser un moyen de transport qui garantit la livraison.	Yes	Yes
Pré-conditions	preConditions	Description d'un état externe à cette transaction et qui est requis avant que cette transaction ne puisse commencer.	Yes	No
Post-conditions	postConditions	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.	Yes	No
Commence quand	beginsWhen	Description d'un événement externe à la transaction et qui provoque normalement le début de cette transaction.	Yes	No
Se termine quand	endsWhen	Description d'un événement externe à cette transaction qui provoque normalement la fin de cette transaction.	Yes	No
Requiert un transport sécurisé	IsSecureTransportRequired	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	No	Yes
Motif	Pattern	Le nom du motif (optionnel) sur lequel se base cette BT	No	Yes

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	Code interne	Description
Requiert une autorisation	IsAuthorizationRequired (true \| false) "false"	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.
Requiert une vérification intelligible	IsIntelligibleCheckRequired (true \| false) "false"	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.
Requiert une non répudiation (true \| false) "false"	IsNonRepudiationRequired (true \| false) "false"	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.
Requiert un certificat de non répudiation	isNonRepudiationReceiptRequired (true \| false) "false"	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.
Heure d'accusé réception de l'acceptation	TimeToAcknowledgeAcceptance (specific to the Requesting Activity)	L'intervalle de temps dont dispose le répondeur pour accepter le document métiers.
Heure d'accusé réception	TimeToAcknowledgeReceipt	L'intervalle de temps dont dispose le répondeur pour accuser réception du document métiers.
Nombre de tentatives supplémentaires	retryCount	Nombre de tentatives autorisées par les règles métiers. Valable pour l'activité demandeur et disponible uniquement pour BPSS 1.04.

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) :

Flux	Request Document	Response Document	Receipt on Response	Acceptance on Response	Receipt on Request
Without response	Oui	Non	Non	Non	Non
Default	Oui	Oui	Non	Non	Non
With receipt on response	Oui	Oui	Oui	Non	Non
With receipt and acceptance on response	Oui	Oui	Oui	Oui	Non
Full	Oui	Oui	Oui	Oui	Oui

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	Code interne	Description
DocTypeDocumentation	DocTypeDocumentation	Documentation de DocumentType.
Est une réponse positive	IsPositiveResponse	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.
Est authentifié	isAuthenticated (true \| false) "false"	Un certificat électronique est associé au document. Ceci constitue une preuve de l'identité du signataire.
Est confidentiel	isConfidential (true \| false) "false"	Le document est crypté afin d'interdire des accès non autorisés à l'information.
Est infalsifiable	isTamperProof (true \| false) "false"	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.