SBDH ou S tandard B usiness D ocument H eader est une spécification de l’UNCEFACT. - PowerPoint PPT Presentation

slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
SBDH ou S tandard B usiness D ocument H eader est une spécification de l’UNCEFACT. PowerPoint Presentation
Download Presentation
SBDH ou S tandard B usiness D ocument H eader est une spécification de l’UNCEFACT.

play fullscreen
1 / 17
SBDH ou S tandard B usiness D ocument H eader est une spécification de l’UNCEFACT.
148 Views
Download Presentation
orenda
Download Presentation

SBDH ou S tandard B usiness D ocument H eader est une spécification de l’UNCEFACT.

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Programme TICPME2010 Minefe - DGCIS 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 Présentation de SBDH

  2. Programme TICPME2010 Minefe - DGCIS 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.htm Présentation de SBDH

  3. Programme TICPME2010 Minefe - DGCIS • 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. Présentation de SBDH

  4. Programme TICPME2010 Minefe - DGCIS • 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 Présentation de SBDH

  5. Programme TICPME2010 Minefe - DGCIS 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). Présentation de SBDH

  6. Programme TICPME2010 Minefe - DGCIS • 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. Présentation de SBDH

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

  8. Programme TICPME2010 Minefe - DGCIS • 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). Présentation de SBDH

  9. Présentation de SBDH

  10. 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 Présentation de SBDH

  11. Programme TICPME2010 Minefe - DGCIS • Bloc Expéditeur : identifiant, autorité, localisation; répétable pour les besoins de routage interne chez l'expéditeur • <Bloc 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 fax Optionnel • N° de téléphone : Optionnel • Rôle du contact Optionnel Bloc Récepteur: idem à Expéditeur Présentation de SBDH

  12. 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. <Bloc Identification du document> 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 Présentation de SBDH

  13. 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 • <Bloc Manifeste> 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 Présentation de SBDH

  14. 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 : • <Bloc Domaine d’affaires> Optionnel • Détermine quel(s) processus d’affaires standardisé les partenaires utilisent. • <Bloc Domaine> • 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 Présentation de SBDH

  15. 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). • <Bloc Service d’affaires> Optionnel • <Nom du service d’affaires> Description du service à assurer sur le document.Optionnel • <Service pour une transaction> 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 ? Présentation de SBDH

  16. 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. <Bloc Information de corrélation> 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 Présentation de SBDH

  17. 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.html ses choix relativement à SBDH. Trois blocs seulement sont retenus. Présentation de SBDH