Statut : ébauche
Date de création: 2 février 2003
Date de dernière modification: 9 mai 2003
Résumé : Ce document a pour buts de recenser les façons dont on pouvait spécifier les processus d'affaires lors de la création de l'instance XML du processus d'affaires, décrire la méthodologie ebXML, énoncer les critères qui ont été respectés lors de la création de l'instance du processus d'affaires ainsi que mentionner d'autres informations connexes.
Partie I : Cette première partie contient plusieurs façons de créer ou spécifier des processus d'affaires.
Lorsque disponible utiliser lors de la création de vos processus d'affaires les modèles UMM pour les transactions et collaborations d'affaires. Ces modèles généraux sont spécifiés lors de leur utilisation dans un processus d'affaires spécifique. Présentement, les transactions d'affaires possèdent six modèles UMM.
Réutilisation des processus d'affaires communs, UN/CEFACT eBTWG – Common Business Process Catalog -Technical Specification - Version 0.90 (Candidate for Version 1.0).
Cet élément permet de rendre plus spécifique un processus d'affaires en redéfinissant selon les besoins les documents échangés et les valeurs des attributs contenus dans le processus d'affaires. [ligne 720]
Cet élément est disponible au niveau processus seulement, il est l'enfant direct de l'élément racine ProcessSpecification. Il est optionnel et répétable.
L'instance du processus spécifique contient les éléments SubstitutionSet.
On inclut le nombre d'éléments SubstitutionSet nécessaires pour spécifier, au niveau approprié, les transactions d'affaires pour lesquelles un ou des documents ou un ou des attributs doivent être modifiés. La portée de cet élément est définie dans l'attribut applyToScope[Specifies the path to attributes or documents that are to be substituted for.] Toutes les occurrences du document identifié dans l'attribut OriginalBusinessDocument dans la portée de l'élément SubtitutionSet, sont modifiées. Cet attribut est de type xsd:string.
Cette façon de procéder sera probablement employée lorsque les profils de métadonnées utilisés seront modifiés pour tenir compte des particularités des M/O sans que le processus d'affaires pangouvernemental de l'enregistrement institutionnel d'un document n'est besoin d'être modifié.
Cet exemple montre comment il est possible de spécifier le processus d'enregistrement institutionnel d'un document afin de limiter celui-ci aux documents de transaction. Le document d'affaires utilisé pour demander un enregistrement institutionnel général a été remplacé par un document permettant uniquement la demande d'enregistrement institutionnel de documents de transaction. Cet exemple montre également que la valeur de l'attribut isNonRepudiationRequired a été modifiée pour "false". A noter que cette dernière opération aurait pu être effectuée via le profil de protocole de collaboration.
<?xml version="1.0" encoding="UTF-8"?>
<ProcessSpecification xmlns="http://www.ebxml.org/BusinessProcess"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.ebxml.org/BusinessProcess
S:\enregistrement-institutionnel\org\ebxml\BusinessProcess\ebBPSS.xsd"
name="enrg-inst-doc-trans" uuid="jhaiehutiarhfjkshfkl" version="0.1">
<SubstitutionSet name="demande_enrg-inst-doc" applyToScope="//BusinessTransaction[@name = 'enrg-inst-doc_demander']">
<DocumentSubstitution originalBusinessDocument="enrg-inst-doc_demander" substituteBusinessDocument="enrg-inst-doc-trans_demander">
<Documentation>Exemple pour la substitution d'un document dans une transaction d'affaires.</Documentation>
</DocumentSubstitution>
<AttributeSubstitution attributeName="isNonRepudiationRequired" value="false">
<Documentation>Exemple pour la modification de la valeur de l'attribut "isNonRepudiationRequired"
de "true" à "false" dans la portée de cet élément de substitution donc pour les éléments
"RequestingBusinessActivity" et "RespondingBusinessActivity".
</Documentation>
</AttributeSubstitution>
</SubstitutionSet>
<BusinessDocument name="enrg-inst-doc-trans_demander" specificationLocation="enrg-ins-doc-trans_demander.xsd"/>
<!-- ... Instance du processus d'affaires -->
</ProcessSpecification>Erreur connue: la description des documents, pointée à l'aide de l'identifiant unique n'est pas fonctionnelle car l'attribut est de type ID. Le problème se retrouve également dans la version 1.05 pour le document original. Le problème a été mentionné par courriel au début du mois de mars 2003.
Cet élément permet d'inclure d'autres instances de processus d'affaires dans celle que l'on est entrain de décrire. Celui-ci se retrouve donc sous l'élément ProcessSpecification. Cet élément est optionnel et répétable.
Voici la description de cet élément provenant de la spécification ebBPSS 1.0 :
Includes another process specification document and merges that specification with the current specification. Any elements of the same name and in the same name scope must have exactly the same specification except that packages may have additional content. Documents are merged based on name scope. A name in an included package will be indistinguishable from a name in the base document [??? indistinguishable : dans quel sens]. [ligne 2633]
Si j'ai bien compris, les éléments d'un processus d'affaires possédant le même nom qu'un élément contenu dans le processus maître servent à ajouter du contenu. Par contre, si un include est pour un processus d'affaires complètement nouveau il n'y a aucun problème.
Exemple de code permettant d'inclure une instance de processus d'affaires dans une autre.
<?xml version="1.0" encoding="UTF-8"?> <ProcessSpecification xmlns="http://www.ebxml.org/BusinessProcess" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.ebxml.org/BusinessProcess S:\enregistrement-institutionnel\org\ebxml\BusinessProcess\ebBPSS.xsd" name="enrg-inst-doc-trans" uuid="jhaiehutiarhfjkshfkl" version="0.1"> <Include name="enrg-inst-doc_état" uuid="slajdkjsakjfkajfksf" uri="http://www.gouv.qc.ca/schemas/processus-affaires/enrg-inst-doc_état.xml" version="0.1"> <Documentation>Exemple de l'inclusion du processus d'affaires demande du statut de l'enregistrement institutionnel d'un document.</Documentation> </Include> <!-- ... Instance du processus d'affaires --> </ProcessSpecification>
A package defines the namespace of the elements inside it. You cannot have two model elements with the same name within the same package. [ligne 706]
Il est donc extrêmement important d'avoir une excellente convention de nommage pour les processus d'affaires afin de permettre l'inclusion de processus d'affaires sans conflit de nom d'élément à l'intérieur des paquetages.
Permet de redéfinir les caractéristiques suivantes pour chaque transaction d'affaires sans modifier l'instance du processus d'affaires:
Cet élément bien qu'il ne permettent pas de spécifier une instance de processus d'affaires lui est complémentaire.
Cet élément permet de définir pour chaque mode de livraison (Delivery Channel) les caractéristiques de la messagerie suivantes:
Partie II: méthodologie
Cette méthodologie est constituée de 4 phases, le retour en arrière est permis. Elle est utilisée par les partenaires d'affaires afin de mettre en place les composants permettant d'effectuer du commerce électronique selon les spécifications ebXML.
Première partie:
Deuxième partie: création CPP
Les informations suivantes se retrouveront dans le profil de protocole de collaboration (CPP):
Dernière partie: le partenaire peut enregistrer son ou ses CPP dans le ou les registre-référentiel(s) de son domaine pour que ceux-ci en effectue la gestion et que des partenaires les retrouvent.
Découverte et extraction d'informations sur les partenaires possibles de commerce électronique, donc leur CPP;
Un des buts de cette phase est d'éviter la duplication des composants élémentaires existants [ligne 1103]
Cette phase va amener le modélisateur probablement à retourner à la phase de découverte.
Some of the activities that may be undertaken during this phase include: 1. Designing Business Processes and assembling associated information models. 2. Modeling Business Collaborations, patterns and commitments. 3. Configuring or constraining business information so it is context specific. 4. Creating a Trading Partner Agreement by binding two or more Trading Partner Profile documents together. 5. Working with XML or other syntax-specific representations of eBusiness Artifacts. Artifacts that may be used during this phase include: 1. Business Process and associated information models. 2. Business Entities 3. Business Process Runtime Expression (Business Process Runtime Expression) instances 4. Business Context information. 5. Core Components 6. Business Information Entities 7. Trading Partner Profile instances. 8. Trading Partner Agreement instances.
Exécution de la collaboration d'affaires.
Les partenaires d'affaires doivent avoir exactement la même entente de protocole de collaboration (CPA) pour la configuration de leurs systèmes.
Some Runtime artifacts include: - Trading Partner Agreement Documents - Business Process Runtime Expression instances - Business Message Payload Metadata - Messages Instances and associated Error messages. - BPS Guard condition messages. - Business Service Interfaces
[Implementation Note: There is no Runtime access to the Registry. [ ligne 624]
During the modeling process, modelers SHOULD have access to Core Components, Business Information Entities, Business Process instances and Business Entities. [ligne 772]
Using a single modeling methodology will improve the quality of artifacts by ensuring they are developed consistently. [ligne 782] Intéressant à mentionner dans la méthodologie.
Les trois premières phases de la méthodologie ebXML doivent être effectuées pour modifier des processus existants.
NOTE: lors de la création du processus d'enregistrement institutionnel d'un document, les consignes ci-dessous ont été utilisées lorsque pertinentes et composants disponibles.
Regarder dans les registres ebXML pour voir ce qui est disponible et recenser ce qui existe qui pourrait être réutilisé tel quel ou avec des modifications.
... can select from a catalog of Business Processes, Business Entities and associated business information models and chose the processes that are applicable to their particular purposes. [ligne 294]
Points importants à tenir compte afin de permettre la réutilisation des composants:
Note: Compte-tenu que l'on veut pouvoir réutiliser des instances ou portion de processus d'affaires dans une instance de processus d'affaires primaire via l'élément Include, la stratégie de nommage des éléments contenus dans les Package est primordiale sinon l'instance risque d'être invalide dû a des dédoublements d'identifiants ou de noms d'éléments.
L'espace nominatif déclaré pour les processus d'affaires est http://www.ebxml.org/BusinessProcess. Celui pour les protocoles de collaboration est http://www.oasis-open.org/committees/ebxml-cppa/schema/cpp-cpa-2_0.xsd.
Les structures des documents véhiculées dans les processus d'affaires pourront être contenu dans un ou plusieurs espace(s) nominatif(s) selon le choix des modélisateurs.
REMARQUES : les espaces nominatifs sont là pour regrouper les éléments de la structure des documents et non pas le contenu. Les "QNAME" peuvent être utilisés pour avoir l'unicité à l'aide d'un préfixe.
NOTE: Évidemment le processus d'enregistrement institutionnel d'un document devra être modifié en conséquence avec les modifications effectuées sur les profils de métadonnées, dans plusieurs cas ceci se résumera peut-être à la modification des structures utilisées et pointées.
Il y a deux acteurs dans ce processus:
Le processus d'enregistrement institutionnellement permet d'enregistrer un seul document à la fois.
Un document peut être constitué de plusieurs fichiers.
Le document sous format électronique est toujours transmis avec l'instance du profil de métadonnées au registraire. La responsabilité de la gestion documentaire passe sous le contrôle organisationnel.
Réflexions effectuées:
Peut-être serait-il plus approprié d'inscrire le contenu des attributs EndsWhen et BeginsWhen, dans l'instance XML, sous forme la plus compacte possible et lorsque possible utiliser XPath. NON, car la description de la chorégraphie explicite le contenu de ces deux attributs.
La demande peut-être de plusieurs types: simple demande d'un profil, demande d'ajout ou de modification d'une instance de profil existant, changement de profil ou demande d'enregistrement d'une nouvelle version d'un document. Le soumetteur doit fournir l'information de base sur le document initiant la demande c'est à dire le titre et le(s) créateur(s) ou identifiants équivalents pour d'autres profils, dans le cas de modifications le soumetteur peut envoyer l'identifiant de l'instance du profil de métadonnées. Cette étape est optionnelle dans le processus d'enregistrement institutionnel d'un document, car le soumetteur peut déjà avoir le profil approprié en sa possession.
Vaudrait-il mieux avoir une transaction d'affaire par type de demande? Selon moi non, car la transaction d'affaires retourne selon la demande les mêmes documents et suit la même chorégraphie d'affaires. Les différentes demandes étant bien identifiées le workflow interne au registraire peut les acheminer selon les différentes branches de traitement si nécessaire.
L'instance XML du profil de métadonnées et le document en format électronique est transmis au registraire.
Est-ce que les modifications doivent être effectuées dans l'instance du profil de métadonnées et constituer une deuxième version du profil? Est-il réaliste de penser que l'on peut pointer vers le profil pour effectuer les modifications à distance? Si oui, ajouter simplement une condition sur l'occurrence de l'attachement et un élément "URL-profil-métadonnées". Le registraire doit conserver chaque version de la fiche ou être en mesure de reconstituer grâce à des métadonnées de journalisation les différentes versions de la fiche (intégrité?). Il est donc préférable pour assurer l'intégrité de chaque version et ne pas ouvrir de brèche de sécurité qu'une copie de la fiche soit envoyée au soumetteur plutôt que pointer vers une copie du coté registraire que le soumetteur pourrait venir modifier à sa guise.
POUR: 1)Minimise le nombre de documents échangés.
CONTRE: 1)L'accès à l'entrepôt d'instance de profils de métadonnées avec droit d'écriture et de modification. 2)L'instance ainsi complétée peut être sauvegardée en tant que n+1 version. 3)L'intégrité du document peut également être prouvé si besoin est.
Est-ce que la version de la fiche doit être mentionnée dans la confirmation. OUI et une confirmation d'enregistrement institutionnel d'un document correspond toujours à une version majeure de l'instance d'un profil de métadonnées.
Tous les messages transférés sont conservés et ce dans l'ordre où ils ont été échangés via la messagerie.
Le sous-sous-élément PersistDuration de l'élément DocExchange dans les CPP et CPA permet d'indiquer le temps de conservation du message contenant le ou les documents. (type : xs:duration)
Particularités : A)preuve légal B)signature C)droits d'accès
Le SGBD devrait être en mesure de conserver quelques métadonnées (journalisation).
Le SGBD devrait être en mesure de gérer les différentes versions des fiches de métadonnnées (mineure et majeure).
Partie IV: État de ebBPSS et notes diverses sur les spécifications
Le schéma de la version mineure 1.05 et la spécification des processus d'affaires comportent beaucoup trop de contradictions pour être utilisables présentement. Les différents logiciels regardés n'ont pas débutés son implantation.
Voici les liens vers les messages envoyés au groupe de développement visant à produire une version 2 de la spécification ebBPSS Observations et DocumentSubstution element. Les éléments mentionnés ont reçu la cote de priorité #5 soit la moins importante, dans le document BPSS – IN SCOPE ISSUES for next BPSS maintenance version 1.1 release du 10 avril qui recense les commentaires sur la spécification.
Par contre, la version 1.0 de la spécification des processus d'affaires disponible et approuvée par ebXML Plenary, est déjà utilisée par quelques logiciels. À quelques reprises j'ai pu voir que ce ne sont pas les instances XML des processus d'affaires qui sont sauvegardées mais plusieurs fichiers contenant des parties de la spécification avec des éléments et/ou attributs propriétaires aux logiciels. Rappelons, la contradiction pour l'élément SubstitutionSet des renvois à des éléments via des attributs de type xs:id plutôt que xs:idrefs, et le manque d'information sur l'utilisation et le référencement aux éléments des processus d'affaires inclus (via l'élément Include).
Différence entre la version 1.0 et 1.05 de la spécification:
XPath étant un language syntaxique il ne permet pas de référencer un élément d'un paquetage ayant été inclus tandis que JAVA ne l'est pas et ne comporte donc pas cette contrainte. Par contre cette notation n'est pas mentionnée dans la version 1.0 de la spécification.
J'ai communiqué via e-mail avec quelques compagnies inscrites dans la liste des implémentations et aucune pour le moment ne pouvait recevoir sans aucune modification une instance valide selon le schéma ebBPSS pour être utilisée lors du commerce électronique. Certains logiciels par contre permettent la création de processus d'affaires avec des dialectes propriétaires mais basés, bien évidemment, sur la spécification.
Pour la création des CPP et CPA la spécification en ai à sa deuxième version. Celle-ci est un OASIS Open Standard depuis le 2 décembre 2002.
Pour la messagerie ebMS plusieurs logiciels ont été certifiés intéropérables selon la version 2.0 de la messagerie ebMS.
UBL est une application des composants élémentaires décrit dans la spécification UN/CEFACT – ebXML Core Components. Les composants élémentaires sont importants afin de maximiser l'intéropérabilité et la réutilisabilité et ce pour différentes technologies.
Présentement, liste des éléments qui ont été créés :
La version 3 de la spécification ebRIM présentement version 2,36 contient la section "Cooperatings registries feature" qui présentent les classes qui supportent la possibilité de coopération.
Oasis ebXML registry v.3.0 : Building on a solid foundation est une présentation très intéressante sur de nouvelles possibilités des registres.
"Federated registries" : Registre dont l'organisation permet l'apport d'informations provenant d'autres registres.
Permet de référencer des objets entre les registres (Inter-registry).
Permet la recherche dans plusieurs registres à la fois.
Un registre peut faire parties de plusieurs "fédération".
La référence à un objet : objectRef = ID + home (the base URI to the home registry). L'attribut "home" n'était pas définit dans la deuxième version majeure de la spécification.
Les objets d'un registre peuvent être dupliqués dans un autre registre mais sont alors en lecture seulement (replicas).
A Trading Partner Agreement is a technical agreement and is not intended to capture any legal agreement between two Trading Partners. However, entering into a Trading Partner Agreement MAY have legal implications. Trading Partners MAY rely on external documents to capture the legal details of their Business Collaborations. Capturing the details of any legal agreements between Trading Partners is outside the scope of this architecture. [ligne 1140]
The Messaging Service MUST be capable of performing security related functions including: • Identification • Authentication (verification of identity) • Authorization (access controls) • Privacy (encryption) • Integrity (message signing) • Non-repudiation • Logging [ligne 1523]
Définition: are application level documents that ‘signal’ the current state of the business transaction [ligne 715]
La structure des signaux d'affaires est universelle.
acknowledgment signals are not modeled explicitly but parameters associated with the transaction specify whether the signals are required or not [ligne 706]
Since signals do not differ in structure from business transaction to business transaction, they are defined once and for all, and their definition is implied by the conjunction of the Business Process Specification Schema and Message Service Specification.[ligne 3024]
ebXML Business Process Specification Schema Version 1.01 Business Process Project Team. 11 May 2001.
UN/CEFACT TMG – Electronic Business Architecture Technical Specification Working draft - Revision 0.83 - 12 December 2002.
Document Engineering for e-Business Robert J. Glushko et Tim McGrath. Proceeding of the 2002 ACM symposion on Document Engineering (DocEng) Nov. 2002
Design XML schemas using UML - Translating business concepts into XML vocabularies Ayesha Malik (ayesha.malik@objectmachines.com) Senior Consultant, Object Machines, February 2003 (consulté le 12 mars 2003).
L’architecture gouvernementale de la sécurité de l’information numérique (AGSIN) - SGQRI-32 Contenu type et guide à l’élaboration d’une entente de sécurité1
UN/CEFACT' s Modelling Methodology - DRAFT - CEFACT/TMWG/N090R10 - November 2001
1 Lors de l'élaboration de l'entente de sécurité une partie est dédiée à la 4.5 Modalités relatives à la gestion des documents identifiés.
Plusieurs caractéristiques des documents d'affaires échangés lors de la création d'une collaboration d'affaires ebXML doivent être spécifiés lors de la création de l'entente de sécurité. On retrouve également des caractéristiques sur les protocoles de communication qui se retrouvent dans les protocoles de collaboration (CPP/CPA).
Ce document devrait être mentionné dans la méthodologie.
Est-ce qu'au gouvernement une collaboration entre deux parties doit obligatoirement créer et utiliser une entente de collaboration du point de vue de la sécurité?
La partie 4.4 Modalités relatives à la conclusion de l’entente de sécurité contient une section Obligation de collaboration.