Projet BPMS Sagex-18305 Interopérabilité de systèmes d information d entreprise Description du démonstrateur Table des matières 1 Objectif 2 2 Principes de fonctionnement 5 3 Scénarios détaillés 6 3.1 Saisie de la commande par l'interface du démonstrateur 7 3.2 Saisie de la commande autonome 7 4 Plate-forme technique 8 5 Etats-transitions de la commande 9 5.1 Commande interne du détaillant 10 5.2 Commande interne du producteur 11 5.3 Demande de transport du transporteur 12 6 Processus global 13 6.1 Collaborateur du détaillant - Saisie de commande 16 6.2 Détaillant - Envoi de la commande au producteur 17 6.3 Producteur - Demande de transport 17 6.4 Transporteur - Traitement de la demande de transport 18 6.5 Producteur - Conditionnement de la marchandise 18 6.6 Transporteur Chargement et transport de la marchandise 19 6.7 Détaillant Réception de la marchandise 20 Description.doc Diagramme d activités du processus global
1 Objectif L'objectif du démonstrateur est de montrer visuellement l'interopérabilité de systèmes informatiques informatisés (SII) qui collaborent à l'exécution d'un processus. Nous avons retenu un scénario impliquant un détaillant, un fournisseur et un transporteur. Le processus que nous démontrerons est le traitement d'une commande passée par un détaillant à son fournisseur dont la livraison doit être assuré par un 3ème partenaire, en l'occurrence un transporteur. Description.doc 2/20
Le démonstrateur est une interface Web qui nous permet de saisir une commande et de suivre l'évolution de son traitement par chacun des trois partenaires. L'interface Web du démonstrateur, comporte une fenêtre pour chacun des trois partenaires; chacune des trois fenêtres montre les changements d'états des objets associés à la commande: La commande interne du détaillant dont le contenu (produits et quantités de chaque produit) est envoyée au fournisseur. La commande interne du fournisseur dont le contenu (produits et quantités de chaque produit) a été envoyé par le détaillant. La demande de transporteur interne du transporteur dont les modalités ont été envoyées par le producteur. Description.doc 3/20
Nous avons prévu de supporter deux scénarios distincts pour la saisie de la commande par le collaborateur du détaillant: 1. L'interface Web du démonstrateur comporte une fenêtre de saisie de commande interne qui instancie directement une commande interne dans la base de données du SII du détaillant. 2. La saisie de la commande interne est faite par une solution départementale ou de bureautique et la commande est ensuite enregistrée dans le SII centralisé du détaillant par l'intermédiaire d'un service Web interne. Description.doc 4/20
2 Principes de fonctionnement Nous avons créés trois applications distinctes; une pour le détaillant, une pour le producteur et une troisième pour le transporteur. Le démonstrateur est intégré à l'application du détaillant; ainsi, le démonstrateur accède directement aux commandes internes du détaillant. Par contre, le démonstrateur passe par l'intermédiaire de services Web pour accéder aux commandes internes du producteur respectivement aux demandes de transport du transporteur. Dans les scénarios détaillés, nous avons intégré les tâches effectuées par chacun des partenaires lorsqu'il est sollicité par la réception d'un message. Pour simuler le temps d'exécution de ces différentes tâches, nous avons intégré un temps d'attente (paramétrable à terme et actuellement de 30s) entre la réception d'un message et l'envoi du ou des messages au partenaire qui doit prendre la suite. Afin de montrer en temps réel cette dynamique, l'interface Web se réactualise régulièrement (actuellement, toutes les 10s). La réactualisation consiste à vérifier l'état de la commande interne du détaillant et à afficher son nouvel état si un changement a eu lieu. Il en est de même pour le producteur et le transporteur; toutefois, pour les deux partenaires externes, nous passons par l'intermédiaire de services Web. Description.doc 5/20
3 Scénarios détaillés Les tâches internes réalisées par chacun des partenaires lors de la réception d'un message sont préfixées d'une étoile; comme indiqué précédemment, ces tâches internes sont simulées par un délai d'attente retardant l'envoi du ou des messages de fin de tâches. Les tâches internes sont par exemple: La vérification et l'acceptation d'une commande interne du détaillant préalablement à l'envoi au producteur. Le conditionnement de la marchandise par le producteur préalablement à la venue du camion. Description.doc 6/20
3.1 Saisie de la commande par l'interface du démonstrateur 3.2 Saisie de la commande autonome Description.doc 7/20
4 Plate-forme technique Les 3 applications sont réalisées sur la même plate-forme technologique en l'occurrence une base de données Oracle et des modules Web PL/SQL. [Pour une introduction aux modules Web PL/SQL d'oracle] Les 3 applications sont hébergées sur la même instance mais sous forme de 3 schémas distincts. Les services Web sont tous implantés sous forme de procédures PL/SQL. Pour des raisons de coûts, les services Web sont tous implantés sur un même serveur d'application (ias) mais naturellement, ils pourraient être déployés sans autre sur des serveurs spécifiques à chacun des partenaires. Comme dit précédemment, le démonstrateur est intégré à l'application du détaillant. Remarque: Dans un souci de simplification, nous n'avons pas montré les appels aux services offerts par chacun des trois partenaires. Description.doc 8/20
5 Etats-transitions de la commande Pour permettre au démonstrateur d'indiquer quel est le partenaire qui réalise une tâche de traitement de notre commande, il nous faut définir très précisément les états et transitions d'états de notre commande. Naturellement, nous n'aurons pas un seul modèle mais, trois soit: 1. un modèle pour la commande interne du détaillant; 2. un modèle pour la commande interne du producteur; 3. un modèle pour la demande transporteur c/o le transporteur. Remarques relatives à la lecture des modèles: ^Producteur.Envoi commande Envoi du message Envoi commande au SII du Producteur. F2: Transporteur.Chargement en route Réception du message Chargement en route émis par le SII du Transporteur. Le message reçu correspond au message identifié F2 dans le scénario. Les notes en regard des états sont présents lorsqu'un message est émis. Ces notes indiquent le ou les identifiants des messages dans le scénario. ^Producteur.Envoi commande correspond au message identifié A dans le scénario. Description.doc 9/20
5.1 Commande interne du détaillant Description.doc 10/20
5.2 Commande interne du producteur Description.doc 11/20
5.3 Demande de transport du transporteur Description.doc 12/20
6 Processus global Pour comprendre le fonctionnement du processus global de traitement de la commande et sa représentation par le démonstrateur, nous avons réalisé un modèle d'activité représenté par le diagramme de la page suivante. Ce modèle d'activité comporte: 4 travées; une pour le collaborateur du détaillant qui saisit la commande et ensuite une travée pour chacun des 3 partenaires. Les deux alternatives de saisie de commande par le collaborateur du détaillant. Les différents objets traités par les 3 partenaires. Les traitements effectués par chacun des partenaires suite à la réception d'un message. Les services Web proposés par les 3 partenaires. Nous avons fractionné le diagramme d activités en 7 parties pour l expliquer ; ces 7 parties sont traitées spécifiquement par les 7 sous-chapitres qui suivent. Description.doc 13/20
: Collaborateur du détaillant : Détaillant : Producteur : Transporteur Saisie commande par un moyen externe Créer commande Mode de sai sie Saisie commande par le démonstrateur Insertion commande cdedet : CommandeDetaillant [Ouverte] A * Envoi commande au producteur Créer commande cdedet : CommandeDetaillant [Envoyée] cdeprod : CommandeProducteur [Ouverte] B * Demander un transport Créer demande de transport cdeprod : CommandeProducteur [Transport demandé] trsp : DemandeTransport [Ouverte] Mise à jour commande * Traiter demande C D cdeprod : CommandeProducteur [Transport confirmé] trsp : DemandeTransport [Programmée] Mise à jour commande Informer détaillant de la livraison E * Conditionnement du chargement Mise à jour demande cdedet : CommandeDetaillant [Livraison avisée] cdeprod : CommandeProducteur [Chargement conditionné] trsp : DemandeTransport [Marchandise conditionnée] Mise à jour commande * Chargement de la marchandise F F2 Mise à jour commande cdedet : CommandeDetaillant [Chargement en route] cdeprod : CommandeProducteur [Prise en charge] trsp : DemandeTransport [En route] G H * Réception de la marchandise Mise à jour demande Mise à jour commande cdedet : CommandeDetaillant [Livrée] cdeprod : CommandeProducteur [Recue par le détaillant] trsp : DemandeTransport [Quittancée] Description.doc 14/20
Remarques relatives à la lecture du modèle: Le fragment de diagramme ci-contre représente le traitement de vérification et d'acceptation d'une commande interne par le détaillant avant son envoi au producteur. 1. Les traitements internes du partenaire sont préfixés d'une étoile et peints en rose. Rappel: Le temps d'exécution des traitements internes est simulé en appliquant un délai d'attente de 30s. 2. Les traitements internes sont déclenchés par un objet qui a changé d'état. Rappel: Un objet peut changer d'état suite à un traitement déclenché à l'interne ou suite à l'activation d'un service Web par un partenaire. 3. Les traitements internes quittancent leur travail en modifiant l'état d'un objet. Remarque: De manière générale, un traitement peut modifier un ou plusieurs objets de natures différentes voire autre que celui qui l'a déclenché. Pour notre processus, chaque traitement interne ne modifie que l'objet qui l'a déclenché. 4. Si nécessaire, les traitements internes sollicitent un ou plusieurs services Web de partenaires. Remarque: La sollicitation des services Web de partenaires correspond au concept de message présenté précédemment dans les scénarios et machines état-transitions. 5. Les services Web des partenaires sont peints en bleu. Remarque: Les services Web vont créer de nouveaux objets ou provoquer un changement d'état d'objets existants du partenaire et par là, initialiser un traitement interne du partenaire. a) Flux de données correspondant à la consommation de la commande du détaillant qui se trouve dans l état Ouverte. b) Flux d invocation du service web du partenaire. c) Flux de données correspondant au changement d état de la commande du détaillant ; la commande se trouvera dans l état Envoyée en sortie du traitement interne. d) Flux de données correspondant à la création ou au changement d état d un objet c/o le partenaire. Description.doc 15/20
6.1 Collaborateur du détaillant - Saisie de commande Description.doc 16/20
6.2 Détaillant - Envoi de la commande au producteur Lorsque le collaborateur du détaillant crée une commande (fragment précédent), cette commande est dans l état Ouverte; toute commande dans l état Ouverte est reprise par le détaillant pour vérification et envoi au producteur. Pour marquer la fin du traitement, la commande est mise dans l état Envoyée. [ Lien vers les explications du code PL/SQL de réalisation de ce fragment d interaction ] 6.3 Producteur - Demande de transport Lorsque le SII du détaillant crée une commande chez le producteur par l intermédiaire du service Web (fragment précédent), cette commande est dans l état Ouverte; toute commande dans l état Ouverte est reprise par le producteur pour vérification et effectuer une demande de transport. Pour marquer la fin du traitement, la commande est mise dans l état Transport demandé. [ Lien vers les explications du code PL/SQL de réalisation de ce fragment d interaction ] Description.doc 17/20
6.4 Transporteur - Traitement de la demande de transport Lorsque le SII du producteur crée une demande de transport chez le transporteur par l intermédiaire du service Web ( fragment précédent), cette demande de transport est dans l état Ouverte; toute demande de transport dans l état Ouverte est reprise par le transporteur pour rechercher une disponibilité et envoyer une confirmation au producteur. Pour marquer la fin du traitement, la demande de transport est mise dans l état Programmée. [ Lien vers les explications du code PL/SQL de réalisation de ce fragment d interaction ] 6.5 Producteur - Conditionnement de la marchandise Lorsque le SII du transporteur confirme un transport chez le producteur par l intermédiaire du service Web (fragment précédent), la commande interne du producteur passe dans l état Transport confirmé; toute commande interne dans l état Transport confirmé est reprise par leproducteur pour aviser le détaillant de la livraison et conditionner la marchandise ; lorsque la marchandise est conditionnée, le producteur en informe le transporteur. Pour marquer la fin du traitement, la commande interne est mise dans l état Chargement conditionné. [ Lien vers les explications du code PL/SQL de réalisation de ce fragment d interaction ] Description.doc 18/20
6.6 Transporteur Chargement et transport de la marchandise Lorsque le SII du producteur informe le transporteur que le chargement est conditionné par l intermédiaire du service Web (fragment précédent), la demande de transport du transporteur passe dans l état Marchandise conditionnée; toute demande de transport dans l état Marchandise conditionnée est reprise par le transporteur pour charger la marchandise; lorsque la marchandise est chargée et que le camion est en route, le transporteur en informe le détaillant et le producteur. Pour marquer la fin du traitement, la demande de transport est mise dans l état En route. [ Lien vers les explications du code PL/SQL de réalisation de ce fragment d interaction ] Description.doc 19/20
6.7 Détaillant Réception de la marchandise Lorsque le SII du transporteur informe le détaillant que la marchandise est en route par l intermédiaire du service Web (fragment précédent), la commande du détaillant passe dans l état Chargement en route; toute commande dans l état Chargement en route est reprise par le détaillant pour attendre la marchandise; lorsque le camion arrive et que la marchandise est déchargée, le détaillant en informe le transporteur et le producteur. Pour marquer la fin du traitement, la demande de transport est mise dans l état En route. [ Lien vers les explications du code PL/SQL de réalisation de ce fragment d interaction ] Description.doc 20/20