SBDH ou Standard Business Document Header est une spécification de l’UNCEFACT. En-tête de message (e-Doc) permettant de savoir que faire du document GS1.

Présentation au sujet: "SBDH ou Standard Business Document Header est une spécification de l’UNCEFACT. En-tête de message (e-Doc) permettant de savoir que faire du document GS1."— Transcription de la présentation:

1 SBDH ou Standard Business Document Header est une spécification de l’UNCEFACT. En-tête de message (e-Doc) permettant de savoir que faire du document GS1 propose un Guide d’implémentation de SDBH http://www.gs1pt.org/documentos/xml/SBDH_v1.3_Technical_Implementation_Guide.pdf 19/03/20091Présentation de SBDH Programme TICPME2010 Minefe - DGCIS

2 SBDH est une spécification tout à fait au point Son statut ODP 7 en atteste. Un alignement CCTS / NDR est cependant souhaitable.. … mais a besoin de ressources Version 1 is at ODP7 status. We recognize the need to align this specification to CCTS and NDR, and have an approved project to do so. However at the moment we have no volunteers for the work. Précision : ODP est le processus par étapes du progrès d’un travail UNCEFACT. ODP 7 est la phase ultime. Voir http://www.ebxml.eu.org/French/ODP.htmhttp://www.ebxml.eu.org/French/ODP.htm 19/03/20092Présentation de SBDH Programme TICPME2010 Minefe - DGCIS

3 SBDH est exprimé en tant que schéma XML Est effectivement un en-tête de document C’est-à-dire une partie spéciale s'ajoutant à tout document quel que soit le format des données composant le document servant au routage et au traitement de ce document. 19/03/20093Présentation de SBDH Programme TICPME2010 Minefe - DGCIS

4 Les besoins que couvre le SBDH : Fournir une sémantique … …et une syntaxe XML d'en-tête normalisé de document d'affaires indépendamment de tout protocole d’échange (messagerie ou Web service) Afin d’alimenter un traitement de ces documents déterminé par les données de cet en-tête. SBDH ajoute une enveloppe à un e-Doc produit par une application pour faciliter le traitement de cet e-Doc par l’application qui le reçoit 19/03/20094Présentation de SBDH Programme TICPME2010 Minefe - DGCIS

5 La signification et la portée des service de SBDH restent entièrement dans une couche logique..alors qu'avec la messagerie ebXML et le WSDL des services Web, il y a des opérations ou actions qui sont prescrites dans le déploiement physique donc : rattachements sur une plateforme donnée. Mais fortes similarités (ebMS est, en quelque sorte, une implémentation « clés en mains » de SBDH). 19/03/20095Présentation de SBDH Programme TICPME2010 Minefe - DGCIS

6 Ce que permet SBDH : le routage d’un émetteur à un destinataire, le cas échéant via un intermédiaire. la fixation d’informations expliquant ce qui doit être fait du document, comment il doit être traité l’association d’un document à son émetteur Ce que le SBDH ne contient pas : Des informations utiles pour la transmission du document qui relèvent de la couche Transport : protocoles de communication, adresse physique. 19/03/20096Présentation de SBDH Programme TICPME2010 Minefe - DGCIS

7 Les cas d’utilisation de SBDH Ils sont au nombre de 4 : 1.Translation d’un e-Doc via un middleware et contribution au paramétrage du transport de cet e-Doc 2.Service Interface avec l’application recevant un e-Doc 3.En-tête XML pour faciliter l’envoi par messagerie d’un e-Doc EDI. 4.Contribution au traitement d’aspects légaux des échanges électroniques. 19/03/20097Présentation de SBDH Programme TICPME2010 Minefe - DGCIS

8 Où se place SBDH ? En dehors de l’e-Doc et/ou intégré dans l’e-Doc ? En faveur de l’intégration : Si le SDBH (XML) est partie du document (également instance XML), le document peut être analysé à haut niveau et les décisions de routage et de traitement aisément prises et exécutées Si le document SDBH est dissocié du document, cas fréquent avec les systèmes anciens, la partie Mime qui le contient peut être égarée à la réception et le routage et le traitement s’en trouve plus difficile. Militent en faveur de la séparation : Le document peut être crypté sans que le SBDH le soit et routage et traitement peuvent être facilement exécutés. L’acheminement au destinataire d’un document crypté permet à lui et à lui seul, disposant des informations nécessaires, de lire le document. Les systèmes de messagerie modernes savent associer plusieurs Parties MIME (Mime Body Parts). 19/03/20098Présentation de SBDH Programme TICPME2010 Minefe - DGCIS

9 19/03/20099Présentation de SBDH

10 19/03/2009Présentation de SBDH10 Programme TICPME2010 Minefe - DGCIS Les blocs d’information définis par SBDH sont :  Bloc Expéditeur  Bloc Récepteur  Bloc Identification du document  Bloc Manifeste  Bloc Domaine d'affaires  Bloc Service d’Affaires  Bloc Information de Corrélation

11 19/03/2009Présentation de SBDH11 Programme TICPME2010 Minefe - DGCIS Bloc Expéditeur : identifiant, autorité, localisation; répétable pour les besoins de routage interne chez l'expéditeur Identifiant : Requis Autorité : Requis, qualifie l’identifiant Information au sujet des contacts : Optionnel Nom du contact : Requis Adresse de courriel : Optionnel N° de faxOptionnel N° de téléphone :Optionnel Rôle du contactOptionnel Bloc Récepteur : idem à Expéditeur

12 19/03/2009Présentation de SBDH12 Programme TICPME2010 Minefe - DGCIS Bloc Identification du document : type « codé » et dictionnaire référé (SWIFT, OAG, EAN.UCC, EDIFACT, X12), version du type, identifiant de l'instance de document d'affaires, occurrence de types multiples en un document, horodatage de création du document (éventuellement, hors du SBDH, sera ajouté l'horodatage du transport sur l'enveloppe de messagerie. Requis Standard : Nom (EDIFACT, SWIFT, OAG etc.) Requis Version du standard : ex 96 A (si EDIFACT) Requis Identifiant d’instance du document Requis Type du document (Facture, Commande..) Requis Type multiple : une balise précisant qu’il y plus d’un type de document dans l’instance - Optionnel Date et heure de création

13 19/03/2009Présentation de SBDH13 Programme TICPME2010 Minefe - DGCIS Bloc Manifeste : nombre d'items joints, pour chaque item son type MIME ou son URI ou un indicateur codé de langue Optionnel Bloc définissant le contenu d’un paquetage Nombre d’items dans le paquetage Requis Items du manifeste : Requis, répétable Type (X12, XML, EDIFACT, autre.) Requis, codé Identifiant unique de l’article (URI) Requis, codé, Description de l’article Optionnel Langue Optionnel

14 19/03/2009Présentation de SBDH14 Programme TICPME2010 Minefe - DGCIS Bloc Domaine d'affaires : source, type, identifiant d'instance (cycle) du processus d'affaires englobant, identifiant d'entente de collaboration (CPA…). Deux premiers objets ont été définis comme premières extensions de la Portée d'affaires : Optionnel Détermine quel(s) processus d’affaires standardisé les partenaires utilisent. Type : Exemples de types : e-Doc, Spécification UMM de collaboration, BPSS ebXML, Business Collaboration Framework Identifiant d’instance (partie de processus) Identifiant : précise l’accord auquel les parties se réfèrent, tel qu’un Trading Partner Agreement Rosettanet ou un CPA ebXML

15 19/03/2009Présentation de SBDH15 Programme TICPME2010 Minefe - DGCIS Bloc Service d’Affaires : description par l'initiateur du service attendu du récepteur sur le document, soit le nom du service, la spécification d'une action à poser, le nom du processus d'affaires englobant mené en collaboration et son URI principal, étape dans le processus (statut). Optionnel Description du service à assurer sur le document.Optionnel Instruction particulière à assurer pour un e-Doc. Type de service : Service demandé, Service en réponse Non répudiation Requise ? Authentification Requise ? Une vérification d’intégrité par le récepteur est-elle requise ? Une vérification de recevabilité applicative est-elle requise ? Temps maximum pour accuser réception ? Temps maximum pour accuser la recevabilité applicative ? Temps maximum de traitement du document ?

16 19/03/2009Présentation de SBDH16 Programme TICPME2010 Minefe - DGCIS Bloc Information de Corrélation : sert à établir le lien entre un document de requête, un document de réponse, et une entente de collaboration donnée ou contrat qui définit la chorégraphie de l'échange. Optionnel Cette information permet de mettre en rapport différents documents intervenant dans un scénario. Date/Heure du document initiant le processus (dit requérant) Identifiant du document Date/Heure de la réponse

17 19/03/2009Présentation de SBDH17 Programme TICPME2010 Minefe - DGCIS Conclusions L’objectif premier de SBDH est de combler le fossé existant pour les standards e-Docs tels qu’EDIFACT ou X12 qui, ne disposant pas des moyens de gérer une collaboration complète – à la différence d’ebXML – peuvent le faire grâce à SBDH. SBDH propose à ces cadres techniques les concepts ordonnés qui leur permettront de gérer des collaborations, au prix d’implémentations qui exploiteront les blocs de données du SBDH. C’est aux utilisateurs de déterminer s’ils préfèrent utiliser un cadre complet, couvrant à la fois la vue opérationnelle des affaires et la vue fonctionnelle des services (cas d’ebXML avec ebMS mais aussi d’autres cadre techniques tels que Rosettanet), ou s’ils aiment mieux développer eux-mêmes en faisant un choix raisonné parmi les possibilités offertes par SBDH. Au nombre des grands utilisateurs, on peut signaler GS1 qui décrit ici http://www.gs1.org/services/gsmp/kc/ecom/xml/xml_sbdh.htmlhttp://www.gs1.org/services/gsmp/kc/ecom/xml/xml_sbdh.html ses choix relativement à SBDH. Trois blocs seulement sont retenus.