2011.TH16780.Robial.benoit

CONSERVATOIRE NATIONAL DES ARTS ET METIERS CENTRE DENSEIGNEMENT DE LYON

MEMOIRE

Prsent en vue d'obtenir le DIPLOME d'INGENIEUR CNAM SPECIALITE INFORMATIQUE

OPTION: SYSTEME D'INFORMATION (ISI)

par

ROBIAL Benot

Ff

Mise en place d'interfaces inter-applicatives dans le cadre d'un projet d'implmentation du progiciel de gestion intgr SAP ECC

Soutenu le 13 janvier 2011

JURY PRESIDENT: Christophe PICOULEAU MEMBRES: Bertrand DAVID, Claude GENIER, Jean-Yves BENEDEYT, Laurent MAYJONADE

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1

Robial Benot - Mise en place d'interfaces dans le cadre d'un projet d'implmentation du PGI SAP ECC

Mmoire CNAM, Session 2010 - 2011 Page 1

Remerciements

Je tiens avant tout remercier:

Monsieur Laurent MAYJONADE, responsable des intergiciels de la socit Givaudan, pour m'avoir fait confiance ds l'issue de mon cursus scolaire classique, pour m'avoir form, conseill et permis de rejoindre le projet d'implmentation SAP ds son lancement officiel au mois de septembre 2006.

Monsieur Jean-Yves BENEYDET, chef de l'quipe technique du projet Outlook, pour m'avoir choisi dans son quipe, soutenu et fait confiance tout au long de mon travail ses cts. Sous sa responsabilit, ma participation aux travaux tant en quipe qu'en autonomie sur des sujets aux contraintes techniques - et parfois humaines - complexes m'a permis d'acqurir de manire acclre des connaissances aujourd'hui cls pour mon avenir professionnel.

Ma famille, mes amis, pour leur soutien continu et leur comprhension quant mon

manque de disponibilit durant les priodes les plus intenses de mon cursus au conservatoire national des arts et des mtiers.

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



Rsum

Les applications qui constituent les systmes informatiques d'aujourd'hui sont le plus en plus complexes et interconnectes. Dans ce contexte, en formant un lment clef d'une solution informatique, un progiciel de gestion intgr est un systme dont dpendent la majorit des autres composants. Ainsi remplacer cet lment engendre souvent une multitude de projets complexes, tant dans leurs aspects informatiques que humains.

Edit par la socit allemande SAP AG, le progiciel de gestion intgr SAP ECC est de nos jours trs prsent dans les entreprises industrielles. Au cours des vingt derniers annes, de nombreuses socits on fait le choix de migrer leur infrastructure informatique vers ce systme et se sont retrouves tre confrontes aux mmes problmatiques d'intgration. Durant cette priode, des techniques standardises par SAP sont apparues et une famille d'outils d'intgration spcialiss appels intergiciels ont fortement volu.

En s'appuyant sur divers cas rencontrs au cours d'un projet d'implmentation du systme SAP ECC, ce mmoire illustre et dtaille les techniques d'interfaage permettant de procder l'intgration du progiciel dans un cosystme informatique.

Mots clefs: SAP ECC, progiciel de gestion intgr, interfaces, intgration, intergiciel, ALE, IDoc, WebMethods, DataStage.

Abstract

Nowadays, software and informatics systems are becoming more and more complex and interconnected. In this context, an enterprise resource planning system is a component into which most of the other software pieces depend. Consequently, changing this component is always involving multiple complex projects, both in their computing and human considerations.

Built by a German corporation named SAP AG, the SAP ECC enterprise resource planning system is today largely used by the industrial companies. Over the last twenty years, many companies have chosen to migrate their IT infrastructure to this platform and all had to face to the same type of integration problems. During this period, SAP standardized solutions for interfacing systems have emerged and a group of specialized integration tools named as middleware became more and more mature.

Relying on various cases encountered during an implementation project of SAP ECC, this thesis documentation illustrates and describes the technical solutions to proceed with the integration of a new enterprise resource planning software in a computing ecosystem.

Keywords: SAP ECC, Enterprise Resource Planning, interfaces, integration, middleware, ALE, IDoc, WebMethods, DataStage.

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



Sommaire

Introduction.................................................................................................................................................... 7

1 La socit Givaudan............................................................................................................................. 9 1.1 Prsentation ................................................................................................................................. 9 1.2 Prsence dans le monde ........................................................................................................... 10 1.3 Historique ................................................................................................................................... 10

2 Le projet Outlook ................................................................................................................................ 13 2.1 Objectifs ..................................................................................................................................... 13 2.2 Organisation............................................................................................................................... 14 2.3 Planning ..................................................................................................................................... 16 2.4 Cycle de vie des dveloppements ............................................................................................. 17 2.5 Mon rle ..................................................................................................................................... 19

3 Le progiciel SAP ECC......................................................................................................................... 21 3.1 Prsentation ............................................................................................................................... 21 3.2 Modules...................................................................................................................................... 21 3.3 Aspects technologiques ............................................................................................................. 23

3.3.1 Architecture...............................................................................................................................................................23 3.3.2 Programmation .........................................................................................................................................................24 3.3.3 Transactions .............................................................................................................................................................24

4 Outils et standards d'intgration ...................................................................................................... 25 4.1 Les diffrents types d'interfaces................................................................................................. 25

4.1.1 Les interfaces synchrones ......................................................................................................................................25 4.1.2 Les interfaces asynchrones pseudo temps-rel ...................................................................................................25 4.1.3 Les interfaces batch .................................................................................................................................................26 4.1.4 Les interfaces B2B ...................................................................................................................................................27 4.1.5 Tableau rcapitulatif.................................................................................................................................................28

4.2 Les intergiciels ........................................................................................................................... 28 4.2.1 L'EAI WebMethods ...................................................................................................................................................28 4.2.2 L'ETL DataStage .......................................................................................................................................................29

4.3 Le modle de publication et de souscription.............................................................................. 30 4.4 Intgration avec SAP ................................................................................................................. 31

4.4.1 Les communications synchrones...........................................................................................................................31 4.4.2 Les communications asynchrones temps-rel .....................................................................................................32 4.4.3 Les communications batch .....................................................................................................................................37

4.5 Spcifications ............................................................................................................................. 38 4.5.1 Rgles d'extraction et d'importation.......................................................................................................................38 4.5.2 Traitements ordonnancs........................................................................................................................................40

4.6 Organisation projet..................................................................................................................... 40 4.6.1 Le paysage applicatif ...............................................................................................................................................40 4.6.2 L'outil de gestion de la qualit ................................................................................................................................41 4.6.3 La gestion des transports........................................................................................................................................42

5 Cas 1: Intgration des clients et de leur hirarchie avec l'application CDM................................ 45 5.1 Analyse fonctionnelle des besoins............................................................................................. 46 5.2 Architecture de la solution.......................................................................................................... 48 5.3 L'interface de transfert des clients ............................................................................................. 48

5.3.1 Structure du BDM CustomerMaster ..................................................................................................................49 5.3.2 Conception SAP........................................................................................................................................................50 5.3.3 Conception WebMethods ........................................................................................................................................58 5.3.4 Conception CDM.......................................................................................................................................................60

5.4 L'interface de transfert des hirarchies...................................................................................... 61 5.4.1 Structure du BDM CDMReplicator ....................................................................................................................62 5.4.2 Conception SAP........................................................................................................................................................63 5.4.3 Conception WebMethods ........................................................................................................................................69

5.5 Migration des donnes............................................................................................................... 70 5.5.1 Migration initiale .......................................................................................................................................................70 5.5.2 Migration pour chaque site......................................................................................................................................71

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



5.6 Exploitation ................................................................................................................................. 72 5.6.1 Exemple de flux.........................................................................................................................................................72 5.6.2 Stabilisation...............................................................................................................................................................73 5.6.3 Statistiques................................................................................................................................................................73 5.6.4 Avenir .........................................................................................................................................................................74

6 Cas 2: Gestion d'un cas de synchronisation complexe avec l'application CMS ......................... 75 6.1 Architecture ................................................................................................................................ 76 6.2 Contraintes de synchronisation.................................................................................................. 78 6.3 Solutions..................................................................................................................................... 80

6.3.1 Version des ordres de fabrication...........................................................................................................................80 6.3.2 Squencement du traitement des messages entrants dans SAP ........................................................................80

6.4 Conception ................................................................................................................................. 83 6.4.1 Ecran de slection ....................................................................................................................................................84 6.4.2 Algorithme .................................................................................................................................................................85

6.5 Exploitation ................................................................................................................................. 86 6.5.1 Stabilisation...............................................................................................................................................................86 6.5.2 Exemple .....................................................................................................................................................................87

7 Cas 3: Intgration des donnes de planification avec l'application ORTEMS ............................. 91 7.1 Architecture ................................................................................................................................ 92 7.2 Conception ................................................................................................................................. 94

7.2.1 Flux de SAP ECC vers ORTEMS..............................................................................................................................94 7.2.2 Flux de ORTEMS vers SAP ECC..............................................................................................................................97

7.3 Exploitation ................................................................................................................................. 98

8 Conception d'outils d'administration et de surveillance ................................................................ 99 8.1 Analyse des pointeurs de modification....................................................................................... 99 8.2 Mise l'cart des iDocs invalides ............................................................................................ 100 8.3 Gestion des programmes ordonnancs ................................................................................... 101

8.3.1 Cockpit de dclenchement du traitement des pointeurs de modification ........................................................102 8.3.2 Cockpit de dclenchement des programmes de traitement et de transfert des iDocs....................................103

8.4 Connexions SAP ECC - EAI WebMethods .............................................................................. 106 8.4.1 Dsactivation des transferts d'iDocs en sortie de SAP ECC..............................................................................106 8.4.2 Dsactivation des transferts de messages entre l'EAI WebMethods et le progiciel SAP ECC .......................108

8.5 Outil de gestion des transports intergiciels .............................................................................. 108

Conclusion ................................................................................................................................................. 111

Glossaire..................................................................................................................................................... 113

Transactions SAP ...................................................................................................................................... 115

Annexes...................................................................................................................................................... 117 Annexe A: Histoire de Givaudan au travers des fusions-acquisitions................................................... 117 Annexe B: Structure organisationnelle du projet Outlook ..................................................................... 118 Annexe C: Fiche TrackDev pour le transport des dveloppements intergiciels ................................... 119 Annexe D: Rapport TrackDev transport buffers , liste des transports en attente ............................ 120

Bibliographie.............................................................................................................................................. 121

Liste des illustrations et tableaux............................................................................................................ 123

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



Introduction

Influencs par des changements de rgulation frquents et des contraintes concurrentielles toujours plus fortes, les processus mtiers des entreprises industrielles d'aujourd'hui sont de plus en plus complexes. En consquence, parce qu'ils forment la base du systme d'information de la majorit des entreprises, les progiciels de gestion intgrs sont continuellement adapts pour rpondre aux nouvelles contraintes des organisations mtier. Ainsi, le choix de changer de progiciel ouvre toujours des projets complexes et stratgiques pour les entreprises car ils sont l'occasion de procder une revue complte de la manire de travailler.

Dans le contexte d'aujourd'hui o les applications et les systmes informatiques sont de plus en plus interconnects, un tel projet revient de plus remplacer la pice maitresse d'un cosystme par une autre. Les interfaces d'change de donnes doivent donc tre adaptes au nouveau systme, ouvrant ainsi en cascade une multitude de sous-projets d'adaptation d'applications construites avec des technologies diverses.

Travaillant dans le service informatique de la socit Givaudan Suisse S.A. depuis l'anne 2004, j'ai rejoint le projet d'implmentation du progiciel de gestion intgr SAP ECC ds son dmarrage en septembre 2006. Mon rle fut alors de prendre en charge la responsabilit du suivi et de la ralisation des aspects techniques des interfaces entre le nouveau systme et les applications tierces. Ce mmoire synthtise l'exprience et les comptences acquises durant quatre annes de travail consacres temps complet la mise en place des communications lectroniques entre le progiciel SAP ECC et son cosystme applicatif au sein de Givaudan.

Dans un premier temps, la socit Givaudan, le projet Outlook et le progiciel de gestion intgr SAP ECC seront prsents. Les choix des principaux outils et des standards d'intgration sont ensuite dtaills et les technologies seront une une expliques. Puis, trois cas d'intgration aux contraintes diffrentes et reprsentatives du travail ralis sur le projet d'implmentation seront tudis. Enfin, le mmoire se termine par la description de divers outils d'administration et de surveillance qui furent conus afin de faciliter la gestion des interfaces du nouveau systme.

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



1 La socit Givaudan 1.1 Prsentation

Givaudan est une entreprise industrielle dont le mtier est de concevoir et produire des armes et des parfums au bnfice d'entreprises internationales, rgionales et locales. Les clients utilisent les solutions ainsi conues pour fabriquer des produits alimentaires, des boissons, des parfums servant l'laboration de produits d'hygine et d'entretien ou encore la confection dans le domaine de la parfumerie de luxe. Ainsi, Givaudan est un fournisseur des entreprises vendant leurs fabrications aux consommateurs finaux.

Les principaux secteurs de march sur lesquels la socit opre sont les suivants:

Segment des armes

Les boissons: boissons non alcoolises gazeuses et non gazeuses, jus de fruits, boissons alcoolises et boissons prparation instantane.

Les produits de confiserie: ptisseries, friandises, chewing-gums et chocolats. Les produits laitiers: glaces, produits laitiers et prparation instantane. Les produits sals: plats cuisins, en-cas, soupes, sauces, viandes et volailles.

Avec 2 135 millions de francs Suisse de chiffre d'affaire en 2009, la division des armes reprsente 54% des ventes de Givaudan. A travers ce segment, les secteurs des boissons et des produits sals reprsentent chacun 35% des ventes. Les secteurs des produits laitiers et de la confiserie forment quant eux respectivement 18% et 12% du chiffre d'affaire de la division.

Segment des parfums:

Les produits de parfumerie fine: eau de Cologne, parfums pour bases aqueuses ou alcoolises et autres produits pour le corps, le bain et la maison.

Les produits fonctionnels: produits pour les textiles et le mnage, dsodorisants, soins des cheveux et de la peau, hygine personnelle.

Les ingrdients de parfumerie: production et commercialisation tant d'ingrdients pour l'industrie que des bases pour les produits textiles et les soins personnels.

La division des parfums compte un volume de 1 824 millions de francs Suisse de chiffre d'affaire produit sur l'anne 2009. Les ventes du segment sont largement domines par le secteur des produits fonctionnels qui reprsente 67% du volume contre respectivement 13% et 20% pour les ingrdients de parfumerie et la parfumerie fine.

Avec une part de marche estime 25%, Givaudan est le leader mondial de l'industrie des armes et des parfums. Les principaux concurrents de la socit sont IFF, Firmenich et Symrise.

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



1.2 Prsence dans le monde

A travers 82 sites dont 33 usines de production, Givaudan emploi plus de 8500 personnes. Le sige de la socit est situ Vernier, prs de Genve en Suisse.

Comme l'illustre la carte ci-dessous, la socit Givaudan est prsente sur les six continents majeurs: l'Europe, l'Amrique du nord, l'Amrique Latine, l'Asie, l'Afrique et l'Ocanie.

Illustration 1: localisation des sites Givaudan travers le monde. Image: givaudan.com

L'Amrique du nord, l'Europe de l'ouest et le Japon forment des marchs matures qui reprsentent 62% des ventes du groupe contre 38% pour les marchs en voie de dveloppement constitus de l'Amrique Latine, l'Europe de l'est, l'Afrique et l'Asie.

1.3 Historique

La socit Givaudan a t fonde en 1895 par Lon et Xavier Givaudan. Conscient de l'importance d'tablir une prsence travers le monde, Givaudan ralisa une premire acquisition en 1924 en achetant l'entreprise Burton T. Bush localise dans le New Jersey aux tats unis. En 1948 c'est la socit Esrolko S.A. base Zurich qui fut achete, ouvrant pour la premire fois Givaudan le march des Armes. Dans les annes 1960, le changement des habitudes de vie avec notamment la dmocratisation des vies professionnelles pour les femmes stimula grandement le secteur des armes. Les foyers

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



passrent de moins en moins de temps cuisiner et augmentrent par consquent leur consommation de plats prpars. Givaudan fut rachet en tant que filiale par le groupe Hoffmann La Roche en 1963. Une anne plus tard Hoffmann La Roche acquis l'entreprise Roure, jusqu'alors concurrente de Givaudan. Les deux filiales continurent de travailler indpendamment, allant mme jusque chacune ouvrir une cole de parfumerie qui plus tard furent fusionnes Paris. Givaudan tendit ensuite sa prsence vers de nouveaux marchs importants tels ceux de l'Asie et de l'Amrique Latine. En 1980 Givaudan acquit Riedel Arom, une entreprise Allemande spcialise dans les armes, puis la compagnie acheta Fritzsche, Dodge et Olcott une socit amricaine rpute dans le domaine des armes et des parfums dont l'origine date du 18me sicle. Cette mme anne, Givaudan et Roure fusionnrent pour former la compagnie Givaudan-Roure. L'entreprise ainsi constitue fut agrandie en 1997 par l'acquisition de la socit amricaine Tastemaker, faisant ainsi de Givaudan la plus grande compagnie du monde spcialise dans l'industrie des armes. Le 8 Juin 2000 Givaudan-Roure se spara du groupe Hoffmann La Roche et conserva uniquement le nom de Givaudan. La socit fut alors intgre la bourse Suisse sous le code GIVN. Le rachat de FIS, la division armes de Nestl fut entrin en 2002. Puis vint en 2003 celui d'IBF, le leader dans le domaine des armes pour les fromages. Givaudan annona le 22 novembre 2006 l'acquisition au groupe ICI d'un concurrent majeur nomm Quest International. Cet achat fut approuv le 2 mars 2007 par les diffrentes autorits de rgulation des marchs financiers. Forte de cette histoire faite de multiples fusions et acquisitions, Givaudan est aujourd'hui le leader mondial de l'industrie des armes et des parfums. La compagnie forme par ailleurs un tiers des parfumeurs et aromaticiens de l'industrie.

Illustration 2: l'histoire de Givaudan au travers des fusions-acquisitions. Document rpliqu en annexe. Image: givaudan.com

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



2 Le projet Outlook 2.1 Objectifs

Le projet Outlook est n d'un effort partag entre l'organisation informatique et les responsables mtier de Givaudan. Les raisons principales taient de pouvoir subvenir aux demandes croissantes de la chane logistique, des fournisseurs et clients, ainsi que de trouver une solution l'obsolescence de BPCS, le progiciel de gestion intgr - PGI - jusqu'alors utilis. Ds lors, les responsables des divisions armes et parfums ainsi que les divers managers des structures du dpartement informatique se sont regroups pour procder une valuation des diverses alternatives au PGI en place. A l'issue de cette tude, le progiciel SAP ECC fut dtermin comme le plus mme de rpondre aux besoins de l'entreprise.

En implmentant le PGI SAP ECC ainsi que divers autres composants de son cosystme informatique, le projet Outlook a pour but de mener un important travail de transformation des processus mtier. Cette mise en place est de plus l'occasion d'harmoniser les systmes et les donnes d'une entreprise dont l'histoire est faite de multiples rachats, parmi lesquels celui de Quest International dont l'annonce fut faite seulement trois mois aprs le dmarrage officiel de la phase d'analyse du projet.

Alors que le progiciel BPCS disposait d'une installation ddie pour chaque site Givaudan, la nouvelle solution se doit de fonctionner sur une unique instance afin d'assurer une meilleure intgration entre les sites et services internes l'organisation. Par ailleurs, l'acquisition de Quest International a amen un nouveau challenge l'quipe du projet Outlook: intgrer des sites inconnus, disposant pour chacun de processus et systmes trs diffrents.

Bien que la mise en place de SAP ECC soit le principal objectif du projet Outlook, il est noter que l'cosystme SAP implmenter comporte aussi les composants BI, GTS et SSM. BI, pour Business Information est un systme d'informatique dcisionnelle permettant de raliser des rapports pour les analyses mtier. Global Trade Services - GTS - est un nouveau produit SAP dont l'objectif est de grer des processus du commerce international, tel que la communication lectronique avec les douanes et la gestion de divers rglements Europens. Enfin SAP Solution Manager - SSM - est un outil central de support permettant d'implmenter, grer, administrer, superviser et maintenir les systmes et solutions SAP. Interfacs avec SAP ECC au travers de mcanismes standards qu'il a juste t ncessaire d'activer, ces trois composants ne seront pas abords au cours de ce mmoire.

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



2.2 Organisation

Selon les diffrentes phases, le nombre de personnes mobilises sur le projet oscille entre 100 et 250. Ces ressources sont pour la moiti issues du personnel Givaudan, incluant majoritairement le site de Genve mais aussi des personnes venant des autres sites Europens, Amricains ou Asiatiques. La seconde moiti reprsente des consultants partenaires dans la progression du projet. Ainsi, la socit Accenture fournit un nombre important de ressources clefs l'organisation et l'entreprise portugaise ROFF met quant elle disposition prs de 40 personnes pour former les quipes de dveloppement et la structure de support aux utilisateurs. Le fort caractre international et multiculturel induit par la diversit des membres du projet et des implmentations locales de Givaudan requiert l'ensemble de l'organisation Outlook de travailler et produire des documents uniquement en langue anglaise.

Sponsoris par Gilles Andrier, le directeur gnral de Givaudan, l'volution du projet est contrle par un comit de pilotage form de quatre hauts responsables mtier sigeant aussi au conseil d'administration de l'entreprise. Les structures de gestion et de validation interne comportent quant elles le chef du projet et divers autres responsables mtiers l'chelle globale de Givaudan. Pour chaque domaine, des quipes ddies appeles streams ont pour charge de procder l'analyse des besoins, la configuration du systme, l'criture des spcifications fonctionnelles ainsi qu'a la ralisation des premiers tests. Le dcoupage fonctionnel de ces quipes suit le modle des entreprises industrielles. Comportant pour chacun entre 5 et 10 personnes, les streams sont lists ci-dessous:

Finance (FIN): gestion des flux montaires, livres de comptes, centres de cots et autres mcanismes ncessaires aux contrles financiers.

Order to cash (OTC): gestion des processus en relation avec les clients: commandes, livraisons, facturations, conditions de prix...

Manufacturing (MFG): gestion des processus de fabrication mis en uvre dans les usines Givaudan.

Plant maintenance (MPM): gestion des processus lis la maintenance des usines, btiments et autres installations de la socit.

Distribution (DIS): gestion des stocks, mouvements de stock et du conditionnement (emballage).

Procure to pay (PTP): gestion des processus d'approvisionnement couvrant les matires premires mais aussi les fournitures en outillage et les ressources humaines externes.

Quality (QUA): gestion des processus de contrle qualit. Compliance (COM): gestion des processus de conformit aux diffrentes

rglementations sanitaires des produits fabriqus par les usines.

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



La responsabilit de l'ensemble des quipes fonctionnelles et la coordination des travaux transverses sont assurs par l'quipe Solution Delivery Management (SDM). La structure Enterprise Architecture & Planning (EAP) gre quant elle la gouvernance des donnes maitres (objets clients, produits, formules...) et la prise des dcisions avec les organisations extrieures au projet concernant les orientations long terme.

La structure Technical Delivery Management (TDM) est quant elle le regroupement sous la mme responsabilit de trois quipes: dveloppement, administration SAP et architecture technique. Hormis les ressources propres au centre de dveloppement externalis, TDM reprsente 15 personnes qui travaillent temps plein.

Enfin, des quipes de dploiement temporaires sont mises en place suivant la progression du projet afin de procder localement la formation des utilisateurs, la gestion des besoins spcifiques locaux et la coordination sur site des activits d'implmentation. La structure de ces dernires est calque sur le dcoupage fonctionnel des streams de l'quipe centrale. Aussi appele Kernel Team , l'quipe centrale est base en Suisse Petit-Lancy dans des locaux lous spcialement pour l'organisation projet. Les quipes de dploiement sont quant elles situs localement sur les sites dployer.

Illustration 3: Organisation du projet. Document rpliqu en annexe. Source: Communication Projet Outlook

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



2.3 Planning

Inities en 2005, les phases de planning et de prparation prliminaire du projet furent termines au milieu de l'anne 2006 et le dclenchement de la ralisation prit place au mois de septembre de cette mme anne. C'est alors que l'quipe projet fut constitue et runie dans des nouveaux locaux lous pour l'occasion afin de commencer les travaux par la conception des processus curs. En formant le noyau du nouveau systme, les processus curs reprsentent la solution standardise par Givaudan. Des alternatives ces processus peuvent tre conues sur demande des sites, nanmoins ces exceptions reprsentent un cot important qui justifie un accord de la part du comit de validation du projet.

La conception du noyau prit fin au milieu de l'anne 2007. Ds lors, la phase d'implmentation des sites pilotes commena. Le premier site pilote qui fut slectionn est l'usine de Givaudan situe en France, Argenteuil prs de Paris. Ce choix tait motiv par le besoin de valider les processus cur sur un site excutant la plupart des scnarios mtier et ayant un volume de production limit. En cas de problme majeur empchant de livrer les clients, il fut alors prvu de transfrer la production au site de Vernier, en Suisse. Suite cette premire phase de localisation, la mise en production eu lieu au mois de mai 2008. Malgr quelques invitables problmes initiaux, l'usine d'Argenteuil fonctionna rapidement sur un systme stabilis. L'implmentation des sites de Givaudan Suisse et Allemagne mobilisa ds lors les effectifs du projet Outlook. Les importants volumes produits par ces usines empchaient alors tout scnario de repli en cas d'incident. Ces mises en production eurent lieu au mois de novembre 2008 et la stabilisation se prolongea jusqu'au mois de fvrier 2009, clturant ainsi la phase d'implmentation des sites pilotes du projet.

L'anne 2009 fut consacre premirement l'implmentation des sites de l'Angleterre et des Pays-Bas provenant de l'acquisition de Quest International, puis l'volution du systme pour rpondre aux besoins des sites productifs qui avaient accept de retarder la livraison dans le systme SAP de certaines fonctionnalits dont ils disposaient auparavant sur BPCS. Le dmarrage des sites acquis eu lieu au mois d'octobre 2009 et leur stabilisation fut termine au dbut du mois de novembre de cette mme anne. Le succs de ces deux premires implmentations de la phase de dploiement permit Givaudan de capitaliser de la confiance dans la capacit de l'quipe Outlook dployer sa solution efficacement sur des sites jusqu'alors peu connus.

Au mois de mars 2010, les sites amricains de la division des parfums furent leur tour migrs vers le nouveau systme. Avec le Mexique, le Brsil, l'Argentine et la Colombie, c'est l'intgralit des sites de l'Amrique Latine qui furent implments au cours des mois de juillet et aout 2010. Enfin, la mise en production de l'usine de Sant-Celoni en Espagne en novembre 2010 conclut une anne importante de travail et succs sur le projet Outlook.

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



L'anne 2011 sera aussi riche en challenges. Au mois de mars les six sites amricains de la division des armes devraient tre intgralement dploys sur le nouveau systme au cours d'une mme tape. C'est aussi au cours de cette anne que commenceront les travaux d'analyse pour l'implmentation des sites de l'Asie et du Pacifique. Les diffrences de culture, de langage et d'alphabet devraient confrer ces derniers dploiements une importante complexit. La migration des sites Africains de l'Egypte et d'Afrique du sud n'est pour lors pas encore prcisment planifie. Ces dmarrages devraient prendre place au plus tt fin d'anne 2011 ou courant 2012 avec les derniers sites Asiatiques.

L'issue du projet est estime au courant de l'anne 2012. Nanmoins, l'implmentation de la version 7.0 de SAP ECC pourrait y ajouter une dernire tape dont la dure serait estime une anne. L'illustration ci-dessous reprsente un niveau de dtail gnral le planning du projet Outlook.

Illustration 4: Planning du projet. Source: Communication Projet Outlook

2.4 Cycle de vie des dveloppements

Qu'il s'agisse de nouveaux processus curs, d'volutions ou de spcificits locales, les besoins sont exprims aux quipes fonctionnels directement par les utilisateurs clefs des quipes mtier. Les utilisateurs clefs sont des personnes avec lesquelles le service informatique a nou un contact particulier. Prsents dans l'organisation mtier de chacun des sites, ils excutent un premier niveau de support aux utilisateurs, centralisent la gestion des problmes lis au nouveau systme, forment leurs collgues et excutent des tests dans les divers environnements SAP.

Une fois les besoins exprims, les quipes fonctionnelles et les utilisateurs clefs formulent dans un document spcialis une demande de changement. D'un niveau d'abstraction lev, ce document comporte une analyse d'impact permettant au comit de validation du projet d'accepter ou de rejeter la requte. Lorsqu'ils sont accepts, les changements sont assigns une version dterminant la date de livraison dans le systme de production.

C'est alors que les analystes des quipes fonctionnelles dbutent un travail d'analyse mtier dtaill avec les utilisateurs clefs et s'appuient sur les spcialistes de l'quipe technique afin de procder une tude des possibilits d'implmentation. A l'issue de cette tape, l'analyste produit une documentation fonctionnelle qui est ensuite soumise l'quipe technique. L'illustration ci-aprs reprsente le cycle de vie de production d'une spcification fonctionnelle.

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



Illustration 5: Cycle de vie de production d'une documentation fonctionnelle.

Aprs rception des spcifications fonctionnelles, un contrle qualit est effectu par un spcialiste du domaine concern: programmes SAP, interfaces, flux de travail - workflows - ou encore formulaires imprims. Une fois les ventuels ajustements raliss, la documentation est transmise l'quipe de dveloppement.

Lorsque les dveloppements sont termins, les analystes procdent une phase de test et rclament des corrections ou ajustements directement aux dveloppeurs. Le dlivrable est ensuite transport sur les autres environnements SAP du paysage applicatif afin que les utilisateurs clefs puissent procder aux tests. La date de livraison en production est dtermine en fonction de la version laquelle les changements sont assigns.

De par la complexit du domaine, le dveloppement des interfaces poursuit un cycle de vie plus complexe. A la rception des spcifications fonctionnelles, le spcialiste de l'quipe technique initie un travail de coordination entre les dveloppeurs du systme SAP, les dveloppeurs externes ou internes au projet spcialiss dans les intergiciels prsents chez Givaudan, et les experts des applications tierces avec lesquelles la communication lectronique est mettre en place. Contrairement aux autres dveloppements, le suivi raliser dans le cadre des interfaces est complet. Ainsi, ce travail requiert de participer aux tests unitaires, aux analyses de performances, au dploiement de la solution sur les autres environnements du paysage applicatif... Cette diffrence avec les autres types de livrables est rendue obligatoire par la complexit du domaine. En effet la mise en place d'interfaces requiert des comptences diverses sur des systmes htrognes et aussi une prise de conscience des aspects scuritaires tant il serait possible qu'une dfaillance ait un impact majeur sur la disponibilit des systmes interfacs.

Le schma ci-aprs reprsente le cycle de vie des dveloppements sur le projet Outlook en fonction du domaine technique concern.

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



Illustration 6: Cycle de vie des dveloppements sur le projet Outlook.

2.5 Mon rle

Mon rle sur le programme Outlook a t de prendre en autonomie la responsabilit de tous les aspects techniques des interfaces avec le nouveau systme dans le rle de spcialiste des interfaces tel que prcdemment dcrit. Mon domaine d'expertise couvre ainsi SAP, les intergiciels d'intgration et certaines applications tierces que j'ai eues l'occasion d'tudier ou pour lesquelles aucun expert n'tait en mesure de m'aider.

Au cours de la premire phase du projet j'ai ralis une tude as-is sur les communications entre BPCS et les systmes tiers existants. Ce travail m'a permis de prendre conscience du futur paysage applicatif de la solution et de connaitre une partie des contraintes auxquelles nous allions avoir faire face. Ds lors, je me suis engag dans la dfinition de nouveaux standards de dveloppement sur le bus d'intgration et sur la configuration de la couche ALE de SAP. Durant la premire anne du projet, ces documents ont rgulirement t mis jour en raison de ma comprhension progressive du nouveau systme. En parallle cette activit, j'ai par ailleurs ralis de nombreux prototypes afin de vrifier l'efficacit de certains concepts.

Une fois l'tude prliminaire termine nous sommes entrs dans la phase de conception en commenant par la dfinition du cur du nouveau systme, c'est dire les fonctionnalits amenes tre communes tous les sites. C'est alors qu'un travail plus intensif dbut. Les quipes fonctionnelles taient en charge d'crire les spcifications des interfaces et me dlivraient ensuite ces documents afin de procder leur validation. Aprs plusieurs cycles de retouches et une recherche de synergies avec d'autres interfaces existantes, je transmettais les spcifications

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



aux quipes de dveloppement charges d'crire le code ncessaire sur SAP ainsi que sur les intergiciels d'intgration. Les adaptations sur les systmes tiers taient quant elles ralises par des experts internes Givaudan avec qui je communiquais frquemment. Une fois les dveloppements termins je vrifiais le bon respect des standards et validais le fonctionnement des interfaces l'aide de quelques tests unitaires avant de livrer le rsultat aux quipes fonctionnelles.

Lorsque la dfinition du noyau de la solution fut termine et valide via une phase globale de tests, une nouvelle tape de spcification et de dveloppement immdiatement dbut afin d'adapter le systme aux spcificits du premier pays que nous avons eu implmenter: la France. En parallle cette phase de dveloppement, l'quipe de migration de donnes a commenc tester ces processus de chargement. Comme nombre de ces processus s'effectuaient au moyen des interfaces, j'ai pris en charge une partie de cette activit. Grce cette tche j'ai pu franchir un nouveau palier dans ma comprhension du systme car cela fut l'opportunit d'analyser le comportement de SAP lors de conditions de charge extrmes. Fort de ces expriences, nous avons pu ajuster la configuration et le dveloppement des interfaces afin de s'assurer que leur fonctionnement en conditions intenses ne puisse pas rompre la disponibilit du systme, ni affecter les utilisateurs.

Une fois les dveloppements spcifiques la France termins et aprs de multiples sries de tests pour valider notre prparation, nous avons mis en production notre solution. Aprs une invitable phase de stabilisation une nouvelle re s'est ouverte: nous sommes passs en mode projet-productif . Ds lors de nombreuses tches d'investigation m'ont t confies afin de comprendre les problmes, proposer des solutions et parfois les spcifier avant de pouvoir procder rapidement leur dveloppement.

Mon travail sur la construction des interfaces ne fut pas interrompu durant cette priode, le prochain objectif tant l'implmentation combine des sites Suisses et Allemands, bien plus critiques pour les activits de Givaudan sur le march Europen. Les dveloppements et les processus de migration taient devenus critiques car nous devions alors nous assurer de ne pas perturber les utilisateurs ou apporter des rgressions. Etant donn le turn-over vident des consultants et donc la fuite de connaissances invitable dans ce type de projet, mes connaissances transverses acquises au fil des diffrentes tapes ont t mises profit pour valider les modifications et oprations techniques demandes sur l'environnement de production.

En raison des contraintes de confidentialit sur les processus critiques de Givaudan mais aussi dans le but de conserver l'intrt la lecture de ce mmoire, l'ensemble des interfaces produites au cours du projet - plus de 60 - ne sera pas abord. Seuls trois des cas les plus reprsentatifs des contraintes d'intgration seront dtaills dans les chapitres ci-aprs.

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



3 Le progiciel SAP ECC 3.1 Prsentation

SAP ECC est un progiciel de gestion intgr dit par la socit SAP AG dont le sige se trouve Walldorf, en Allemagne. SAP est l'acronyme de Systems, Applications and Products in data processing , tandis que ECC signifie Enterprise Central Component . La socit SAP AG est le plus grand concepteur de logiciel en Europe. Employant prs de 52 000 personnes, l'entreprise se positionne la quatrime place des plus grands diteurs informatique du monde, situ juste derrire Microsoft, IBM et Oracle. La part de march estime son produit phare SAP ECC est aujourd'hui de 60%, justifiant ainsi la confiance accorde par ses clients et plus particulirement ceux du secteur industriel.

La premire version du produit est ne en 1973 sous le nom de SAP R/1. Fonctionnant l'poque sur des machines de type mainframe, le systme tait spcialis dans la gestion des traitements financiers. Cette version servit de base pour le dveloppement d'une multitude de nouveaux modules mtier. SAP R/2, la seconde version majeure du produit fut quant elle propose en version stabilise partir de 1981. En 1992 SAP mit disposition R/3, un systme abandonnant pour la premire fois l'architecture mainframe au profit du client-serveur. Cette version connue un succs majeur et de multiples volutions avant d'tre remplace au mois d'aout 2005 par un nouveau systme sous le nom SAP ECC 5.0. En juin 2006, le systme volua nouveau avec la mise disposition de SAP ECC 6.0, la version encore la plus actuelle aujourd'hui. C'est cette dernire qui fut installe chez Givaudan. ECC 7.0, la prochaine version du clbre progiciel de gestion intgr est aujourd'hui toujours secrte, SAP AG communicant trs peu ce sujet. Elle ne devrait pas tre mise disposition avant le courant de l'anne 2012.

3.2 Modules

Le PGI SAP ECC 6.0 est constitu d'une multitude de modules fonctionnels. Ces derniers sont rpartis en trois familles dont les principaux sont lists ci dessous.

Modules logistiques

Material Management (MM): gestion des produits, processus lis aux achats, factures et aux mouvements de stocks.

Production Planning (PP): gestion de la production, planification, calcul des besoins, gestion des capacits et calcul des cots de revient.

Sales and Distribution (SD): administration des ventes, gestion des appels d'offre, des offres et contrats, commandes clients, conditions de prix, facturation, expdition, livraisons et gestion des remises.

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



Project System (PS): module transverse. Structuration des projets, suivi et cots, planning et calendrier.

Quality Management (QM): gestion de la qualit, planification, plans d'inspection, contrles, certificats et gestion des rclamations.

Plant Maintenance (PM): gestion de la maintenance, description du rfrentiel, maintenance prventive et curative, demandes d'intervention, traitement des ordres, historiques, confirmations d'achvement, cots et re-valorisation des articles.

Customer Services (CS): gestion des services clients - extension au module PM. Product Life-Cycle Management (PLM): gestion des cycles de vie des produits, gestion

de l'environnement, des risques et des donnes lies l'hygine. Warehouse Management (WM): gestion globale des entrepts. Handling Unit Management (HUM): gestion des units de manutention.

Parmi ces derniers, les modules logistiques implments sur l'installation SAP ECC de Givaudan sont MM, PP, SD, QM, PM, WM et HUM.

Modules de gestion comptable

Financial (FI): criture des ventes et achats, gestion des placements et de la trsorerie, comptabilit gnrale, client, fournisseur, budgtaire, bancaire et immobilisations.

Controlling (CO): contrle de gestion, comptabilit des natures comptables, gestion des activits, ratios statistiques, comptabilit analytique, ordres et projets de frais.

Controlling Product Costing (CO-PC): calcul des cots de revient par produit, calcul analytique des supports de cots.

Controlling Profitability Analysis (CO-PA): compte de rsultat et analyse par segment. Treasury (TR): gestion des flux de trsorerie et des paiements. Investiments Management (IM): gestion des investissements financiers

Les modules de gestion comptable utiliss sur le systme mis en place par le projet Outlook sont les modules FI, CO, CO-PC, CO-PA et TR.

Modules de gestion des ressources humaines

Personnel Administration (PA): gestion des employs, de la rmunration, primes d'intressement, suivi du temps de travail, suivi des frais de dplacement.

Personnel Development (PD): gestion des comptences, suivi des carrires, planification des rservations, gestion des sminaires.

Personnel Development (PB): gestion du recrutement. Employee & Manager Self Service (ESS & MSS): accs intranet pour employs et

managers.

Les modules de gestion des ressources humaines ne sont pas utiliss sur l'installation Outlook de SAP ECC. Nanmoins Givaudan dispose d'une installation spare du progiciel, communment

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



appel SAP HR (Human Ressources) sur laquelle certains de ces modules sont actifs. Cette installation est entirement gre et hberg par un partenaire externe spcialis afin d'viter les risques vidents de confidentialit. L'accs ce systme par les employs de Givaudan ne faisant pas partie de l'organisation des ressources humaines pourrait en effet leur permettre de consulter des informations sensibles.

3.3 Aspects technologiques

3.3.1 Architecture

Les utilisateurs accdent aux systmes SAP travers le SAP GUI, une application installe sur leurs ordinateurs. SAP GUI est semblable un navigateur web, le logiciel envoie des requtes au systme SAP, puis rceptionne des donnes similaires des pages pour procder l'affichage des rsultats. Lors de l'initialisation de la communication avec SAP, un mcanisme nomm portier (Gateway) dirige l'utilisateur vers un serveur d'applications SAP qui sera charg de procder ses requtes. Ce dernier communique ensuite avec le systme de gestion de bases de donnes (SGBD) afin de consulter ou crire des donnes dans la base de donnes en fonction des actions de l'utilisateur. Une architecture de systme SAP courante consiste disposer de plusieurs serveurs d'applications SAP afin de pouvoir rpondre un nombre important de requtes et d'utilisateurs. Dans ce scnario, la coordination entre les serveurs est assure par un serveur d'applications particulier qui sera configur de manire se comporter en instance centrale. Unique l'installation, l'instance centrale recevra travers un serveur de messages des demandes de blocages et de dblocages des donnes afin de procder la coordination ncessaire pour grer les contraintes de concurrence entre les accs. L'illustration suivante reprsente de manire simplifie un systme SAP disposant d'une telle architecture.

Illustration 7: Exemple d'architecture d'un systme SAP.

Au travers d'un mcanisme d'abstraction expliqu dans le chapitre suivant, plusieurs types de SGBD peuvent tre choisis pour une installation SAP. Oracle est le SGBD le plus communment slectionn.

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



3.3.2 Programmation

La plupart des programmes SAP sont dvelopps dans le langage ABAP. Acronyme de Advanced Business Application Programming , ABAP est un driv du langage COBOL qui permet de dvelopper tant de manire procdurale qu'en orient-objet. Bien que lors de sa conception le langage avait pour objectif de pouvoir tre utilis par n'importe quel utilisateur, il s'est avr avec l'exprience que seuls les programmeurs expriments pouvaient raliser des programmes et des rapports.

Tel Java avec sa machine virtuelle (JVM), ABAP est un langage interprt. Les requtes la base de donnes sous jacente sont par ailleurs crites dans un langage SQL spcifique appel ABAP SQL. Un tel procd a pour avantage de conserver une abstraction totale entre les dveloppements raliss sur la plateforme SAP et le type de SGBD slectionn. Nanmoins, cette abstraction rduit la puissance du langage SQL et ne permet pas de raliser de puissantes optimisations dans les accs aux donnes.

Les dveloppements de nouveaux programmes, tables, interfaces ou autres ont pour particularit de ncessiter de procder au nommage chaque objet en commenant par la lettre Z. Cette obligation propre SAP s'avre trs utile pour distinguer les dveloppements personnaliss crs par les entreprises des dveloppements standards raliss par SAP AG.

Exemples: RBDMIDOC est un objet standard (programme SAP) ZGL_SALES_PRG n'est pas un objet standard

3.3.3 Transactions

La navigation dans le progiciel SAP se fait au moyen de transactions. Les transactions sont des codes alphanumriques qui une fois entrs l'intrieur du champ de saisie situ en haut gauche de la fentre SAP, permettent d'accder des programmes. Nombre de programmes techniques ne disposent pas de transaction ddie, ils peuvent dans ce cas tre accds travers SE38, la transaction permettant d'excuter les programmes.

Tels les dveloppements, les codes des transactions personnalises doivent dbuter par la lettre Z.

Illustration 8: Zone de saisie des transactions.

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



4 Outils et standards d'intgration Les standards et outils d'intgration utiliser furent dtermins au cours de la premire

phase du projet. Certains de ces choix ont t repris des technologies et usages dj en place chez Givaudan, puis adapts une utilisation dans le nouveau contexte.

4.1 Les diffrents types d'interfaces

4.1.1 Les interfaces synchrones

Les interfaces de type synchrone permettent de faire communiquer directement des applications entre elles. L'metteur initie une communication avec le rcepteur en envoyant des ventuels paramtres, puis ce dernier rpond immdiatement au travers de la mme liaison rseau. Si l'application rceptrice est indisponible, alors la communication est perdue.

Illustration 9: Communication synchrone.

Bien que permettant d'obtenir une rponse immdiate, il fut dcid de limiter ce type d'interfaces aux uniques cas o les utilisateurs attendent une rponse immdiate, sans pouvoir accepter un mcanisme asynchrone rapide de type requte-rponse s'excutant en moins de une minute. Les raisons ayant motiv ce choix sont les suivantes:

L'indisponibilit de l'application rceptrice engendre la perte de la communication. Dveloppements, gestion des erreurs et traage des changes complexes. Pour des raisons de scurit et de stabilit, il fut dcid de limiter les accs direct SAP

par des applications tierces. L'utilisation d'intergiciels est prfre.

La seule implmentation technique accepte pour la mise en place d'interfaces synchrones est l'usage de services web. Les services web (communment appels web-services) permettent au travers d'un protocole standardis de s'assurer de la prennit des dveloppements en s'affranchissant des contraintes lies aux diffrences technologiques entre les applications.

4.1.2 Les interfaces asynchrones pseudo temps-rel

L'intrt principal des interfaces asynchrones pseudo temps-rel est de permettre des changes rapides entre les applications tout en s'affranchissant des contraintes de performance et de disponibilit. Dans ce scnario, l'application qui initie la communication n'attend pas une rponse immdiate de la part du rcepteur. Les implmentations de ce type d'interfaces sont ralises au travers d'une plate forme spcialise de la famille des intergiciels appele EAI, acronyme de Enterprise Application Integration . Tel qu'illustr sur le schma ci-aprs, les EAI sont reoivent des messages de la part des

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



applications souhaitant mettre des informations, puis les diffusent aux rcepteurs. En cas d'indisponibilit du rcepteur ou de performances dgrades, alors les messages sont conservs dans des files d'attente puis remis au destinataire ds que possible.

Illustration 10: Communication asynchrone au travers d'un intergiciel EAI.

Les EAI sont capables de faire communiquer entre elles des applications fonctionnant sur des technologies trs diffrentes. Situ en intermdiaire de chaque change, l'EAI constitue par ailleurs un point idal pour superviser et administrer le fonctionnement des interfaces. La dure de latence minimum accepte est de 30 secondes pour un change monodirectionnel, ce qui se trouve tre satisfaisant dans la plupart des cas d'intgration.

La mise en place de communications au travers d'un EAI constitue la solution prconise pour la conception des interfaces du projet Outlook. Nanmoins, les EAI sont optimiss pour l'excution rapide d'changes de donnes de faible volume et sont donc entirement inadapts pour raliser des transferts massifs. De tels processus risqueraient de rompre la disponibilit de l'intergiciel. La plate forme EAI utilise chez Givaudan est WebMethods, un produit dit par la socit Allemande Software AG. Ce dernier est dcrit plus loin dans ce chapitre.

4.1.3 Les interfaces batch

A l'inverse des interfaces asynchrones pseudo temps-rel, les interfaces batch sont optimises pour raliser des changes massifs de donnes, lorsque le temps de latence accept est suprieur 15 minutes. Les implmentations de ces interfaces sont ralises au travers d'une famille d'intergiciels spcifiques appele ETL, acronyme de Extract, Transform & Load . Tel qu'illustr ci-dessous, les multiples tches d'une interface de type batch sont contrles par un ordonnanceur.

Illustration 11: Communication batch au travers d'un intergiciel ETL.

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



Dans cet exemple, la premire tape de l'ordonnanceur est de dclencher un processus de prparation des donnes extraire sur l'application mettrice. Cette tape n'est pas toujours ncessaire car il arrive en effet que l'ETL accde directement aux tables de donnes de l'application. L'ordonnanceur dclenche ensuite sur l'ETL le programme d'excution de l'interface. Ce dernier lit les donnes, les transforme si besoin, puis les transmet l'application rceptrice. Enfin en cas de besoin, l'ordonnanceur peut dclencher des traitements sur le systme rcepteur afin d'excuter des tches d'intgration post-transfert.

Lors de la dfinition des standards technologiques du projet Outlook, il fut dcid d'utiliser les interfaces batch uniquement lorsque les conditions suivantes sont runies:

Dclenchement sur contrainte horaire ou la fin d'un autre traitement contrl par l'ordonnanceur. Pas de dclenchement sur action utilisateur.

Transferts de donnes volumineux sans calcul de delta: l'ensemble des donnes est envoy sans rduire uniquement aux informations modifies dans le systme depuis le dernier transfert.

Latence suprieure 15 minutes.

L'intergiciel ETL utilis chez Givaudan est DataStage. Ce produit dit par IBM est dcrit plus loin dans cette section. L'ordonnanceur des tches est ControlM, dit par la socit amricaine BMC Software.

4.1.4 Les interfaces B2B

Les interfaces B2B, acronyme de Business to Business ont pour objectif de raliser des changes entre une application interne la socit et le systme informatique d'un partenaire externe, tel qu'un client, un fournisseur, une banque ou un transporteur. Le principe est similaire une interface de type asynchrone temps-rel auquel l'application mettrice ou rceptrice est remplace par une plateforme spcialise dans les changes B2B. L'intergiciel EAI se trouve ainsi connect au systme B2B tel qu'illustr sur le schma ci-dessous.

Illustration 12: Communication B2B d'un point de vue metteur.

Les changes avec le systme externe peuvent tre raliss en utilisant divers protocoles et formats. La solution prfre par Givaudan pour l'implmentation de ces interfaces est d'utiliser le format XML au travers du protocole HTTPS. Nanmoins les contraintes d'intgration des partenaires externes requirent souvent de la flexibilit sur les rgles de construction technique. La plateforme B2B utilise chez Givaudan est intgre l'intergiciel WebMethods.

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



4.1.5 Tableau rcapitulatif

Le tableau suivant dresse le rcapitulatif des types d'interfaces et du cadre d'utilisation dans lequel chacun doit tre utilis.

Type d'interface Latence Volume par message

Cas d'utilisation

Synchrone 0 seconde (immdiat) < 1 Mga octet

Uniquement lorsqu'asynchrone temps-rel ne peut pas tre utilis pour des contraintes de latences.

Asynchrone temps-rel

30 secondes minimum < 1 Mga octet

Tous les cas pour lesquels la latence et le volume sont conformes.

Batch 15 minutes minimum Tous volumes

Echanges massifs d'informations non limit aux seules donnes changes.

B2B Idem asynchrone temps-rel, 30

secondes minimum < 1 Mga octet

Tous les changes avec des partenaires externes.

Tableau I: Rcapitulatif des types d'interfaces.

4.2 Les intergiciels

4.2.1 L'EAI WebMethods

WebMethods est une plateforme d'intgration EAI et B2B conue en 1996, puis rachete en 2007 par la socit Allemande Software AG. Le produit est constitu de deux principaux composants:

Un serveur de messages, aussi nomm message broker ou bus d'intgration. Il s'agit du cur du concept EAI.

Un ou plusieurs serveurs d'intgration chargs d'excuter les dveloppements et de communiquer avec les applications au travers de diffrents types de connecteurs.

Le schma ci-dessous illustre en dtail l'architecture d'une interface faisant communiquer une application fonctionnant sur un systme Oracle avec le systme SAP ECC au travers de l'EAI WebMethods en utilisant un message de format nomm Commande .

Illustration 13: Architecture d'une interface sur l'EAI WebMethods.

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



L'htrognit des connecteurs constitue la force des EAI. Grce eux il est possible de faire communiquer facilement entre elles des applications techniquement trs diffrentes. Parmi les connecteurs les plus rependus, le connecteur JDBC permet de s'interfacer avec la majorit des systmes de gestion de bases de donnes. Il existe aussi videmment un connecteur pour se connecter aux applications SAP, ou encore des connecteurs pour construire des fichiers plats ou au format XML, raliser des changes FTP, appeler des web services... Par ailleurs, dans le cas de systmes trs spcifiques ne pouvant tre interfacs avec l'un des types de connecteurs existant, il est possible de raliser soi-mme un nouveau connecteur dans la mesure o l'on dispose d'une API - Application Programming Interface - ou de suffisamment d'informations techniques sur l'application concerne pour raliser ce dveloppement. Les fonctionnalits B2B sont depuis quelques annes incluses dans l'EAI WebMethods au travers des connecteurs web et XML, puis d'un outil de monitoring spcialis nomm Trading Network.

En constituant un lieu de passage obligatoire pour la communication entre les systmes, le composant broker de l'EAI WebMethods est un point unique de panne gnrale. En effet, en cas d'indisponibilit de ce dernier toutes les applications du systme d'information se trouveraient isoles. Son usage et sa disponibilit doivent donc tre attentivement matriss.

Les messages changs sur l'intergiciel ont un format entirement dfini au cours du dveloppement des interfaces. Il est recommand de les concevoir de manire la plus gnrique possible afin de garantir les possibilits de rutilisation, tel qu'elles seront dcrites dans une prochaine section ddie au modle de publication et de souscription. Dans l'industrie informatique, les formats des messages changs sur les EAI sont communment appels documents canoniques . Chez Givaudan ces mmes documents sont appels des BDM, acronyme de Business Data Model signifiant Modle de donnes mtier . Les spcifications des rgles d'extraction et d'importation - les rgles de mapping avec les applications - sont ralises au travers d'un document standardis au format Microsoft Excel qui sera prsent plus loin.

4.2.2 L'ETL DataStage

DataStage est un intergiciel ETL qui est la proprit d'IBM depuis 2005 suite au rachat de la socit Ascential Software. Il est inclu dans la clbre famille de produits WebSphere.

Spcialis dans les traitements de type batch, DataStage dispose l'instar des EAI d'une multitude de connecteurs afin de pouvoir se connecter diffrents types d'applications. Le dclenchement des interfaces peut se faire en se connectant l'outil de dveloppement et d'excution ou au travers d'un ordonnanceur externe; une solution plus adapte pour les processus d'intgration contenant galement des tches externes l'ETL.

Dans le but de simplifier la communication avec les quipes fonctionnelles, il fut dcid au cours du projet Outlook de documenter les spcifications des rgles d'extraction et d'importation - les mapping - des interfaces DataStage de la mme manire que pour les changes de type EAI. Ainsi, les formats des donnes changes sont aussi spcifis dans des documents appels BDM.

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



4.3 Le modle de publication et de souscription

Le modle de publication et de souscription est une stratgie d'intgration provenant du monde des EAI. Sur le projet Outlook, l'utilisation de cette stratgie est tant que possible tendue la conception des interfaces sur l'ETL DataStage. Le but du concept est de raliser des dveloppements en demi-flux au travers de formats d'change gnriques afin de promouvoir l'indpendance, la rutilisabilit et la prennit des dveloppements.

Dans le modle, on dit qu'une application publie des donnes lorsqu'elle transmet de l'information l'intergiciel, les systmes auxquels ce dernier envoie des donnes sont quant eux dits souscripteurs. La publication et la souscription s'articule au niveau du format des messages et en aucun cas en fonction de l'identit de l'application qui publie les informations. Ainsi pour chaque type de message - chaque BDM - il est possible de disposer de plusieurs metteurs et rcepteurs. L'illustration ci-dessous reprsente un exemple d'application du modle articul autour du BDM client .

Illustration 14: Exemple d'application du modle de publication et souscription.

Dans ce scnario, les applications A et C publient l'intergiciel des informations au format du BDM client. B, C et D souscrivent ce BDM avec la particularit pour l'application D de filtrer les informations reues de telle manire ne recevoir uniquement que les clients ayant la caractristique d'tre issus de France. Ce filtre est implment dans les dveloppements raliss sur l'intergiciel, il ncessite au BDM client de disposer de la zone pays . Ainsi, lorsque A ou B publient un message de type BDM client, ce dernier est reu par les applications B et C, puis D dans le cas o le client est Franais.

Chaque publication ou souscription par une application d'un format de message est ralise dans l'intergiciel sur un espace de dveloppement entirement indpendant. Ainsi, les ventuels problmes seront automatiquement isols. Par ailleurs avec un tel modle, remplacer une application du systme informatique par une autre est relativement ais car il s'agit uniquement de redvelopper les communications entre le nouveau systme et l'intergiciel. La plupart des nouvelles interfaces d'un systme d'information sont premirement dveloppes dans un scnario o il existe uniquement un metteur et un rcepteur. Avec le temps et les volutions du SI, de nouvelles applications viennent ensuite s'articuler autour de ces mmes

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



formats de messages. Afin de garantir les facilits de rutilisation, il est recommand de concevoir des BDM de format gnrique incluant le maximum de zones sur l'objet mtier concern. L'exprience dmontre que le cot de la surcharge des BDM en information non utiles la premire utilisation est limit, voir inexistant. En revanche lorsque le temps sera venu de rutiliser ces BDM, la prsence des champs additionnels vitera des dveloppements et des phases de tests parfois risques et coteuses. Ainsi, travailler efficacement avec le modle de publication et de souscription ncessite de se projeter dans l'avenir et de prvoir les futurs usages lors de la dfinition de nouveaux formats.

De par leur composant central qu'est le courtier de messages (broker), l'application de ce modle dans le cadre d'un EAI est vidente. Pour reproduire ce concept avec un ETL il est ncessaire de rendre indpendantes les extractions (publications) et chargements (souscriptions) en enregistrant toujours les donnes de manire temporaire au milieu de l'excution des flux d'intgration. La solution utilise sur le projet Outlook est d'enregistrer les donnes dans des fichiers plats. Une fois crs, ces derniers sont ensuite utiliss pour alimenter une multitude de souscripteurs.

4.4 Intgration avec SAP

Les systmes SAP disposent de plusieurs solutions techniques pour la mise en place des interfaces. Ce chapitre prsente les solutions qui furent adoptes au cours du projet Outlook pour chaque type d'interface mettre en place. Les communications B2B ne sont pas dcrites ci-aprs car d'un point de vue SAP elles s'articulent exactement de la mme manire que les interfaces de type asynchrone temps-rel.

4.4.1 Les communications synchrones

Tel qu'indiqu prcdemment, le standard qui fut adopt pour les communications synchrones est l'usage de services web. La technique de dveloppement des services web avec SAP repose sur la conception de modules de fonctions. Les modules de fonctions sont des morceaux de code dvelopps en ABAP excutant des traitements sur SAP. Ils peuvent disposer de plusieurs paramtres en entre et en sortie.

Les appels externes SAP sont habituellement raliss sur des modules de fonctions travers le protocole propritaire RFC, acronyme de Remote Function Call . Pour procder la mise disposition d'une fonction en tant que service web, il est ncessaire d'excuter un outil de configuration pas pas disponible dans les services de dveloppement SAP. Une fois termin, le module de fonction se trouve tre accessible au travers du protocole SOAP - Simple Object Access Protocol - en tant que service web. Les transactions SAP WSCONFIG et WSADMIN permettent ensuite de tlcharger l'indispensable fichier WSDL - Web Service Description Language - fournir aux dveloppeurs du systme excutant l'appel afin qu'ils puissent excuter sur leurs technologies les mcanismes de cration de code automatique pour les services web.

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



Le dveloppement sur SAP d'appels des services web poursuit le procd inverse. Les dveloppeurs du systme externe fournissent un fichier WSDL qui une fois charg sur SAP travers la transaction WSADMIN cre automatiquement un module de fonction comportant les paramtres d'entre et de sortie spcifis dans le fichier de description. Pour excuter un appel du service, il suffit ensuite aux dveloppeurs SAP d'excuter le module de fonction avec les paramtres requis. Ce dernier fournira automatiquement en retour les donnes de rponse produites par le systme externe, dans le cas o il est disponible. L'illustration ci-dessous reprsente les appels synchrones entrants et sortants au travers des modules de fonctions ainsi que des protocoles de communication RFC et services web (SOAP).

Illustration 15: Communications synchrones avec SAP, Services web VS protocole RFC.

4.4.2 Les communications asynchrones temps-rel

SAP permet de raliser des communications de type asynchrone temps-rel travers une suite d'outils regroups sous l'acronyme ALE pour Application Link Enabling . Les lments de base pour la mise en place de ces interfaces sont les iDocs. Les paragraphes ci-aprs dcrivent les iDocs ainsi que les principaux outils permettant de les administrer.

4.4.2.1 Les iDocs

Les iDocs, acronyme de intermediate document sont tels les BDM des formats de donnes destins raliser des changes. Ils sont caractriss par trois principaux critres:

iDoc type: un type d'iDoc fait rfrence une structure de donnes compose de segments.

Extension: pour chaque iDoc, disposer d'une extension est optionnel. Les extensions permettent d'tendre les structures de donnes des types d'iDoc avec des segments additionnels.

Message type: chaque iDoc doit obligatoirement disposer d'un type de message. Il fait rfrence aux types de donnes contenues dans le message et parfois aussi leur contexte.

Les types d'iDoc sont constitus de segments hirarchiss en fonction de la structure des donnes contenir. Tel un enregistrement d'une table, les segments comportent une liste de zones contenant au maximum une valeur pour chacune. Lors de la dfinition des types d'iDoc, les segments peuvent tre intgrs comme tant itratifs afin de leur permettre de transfrer des

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



informations multi-values, tel que les lignes d'une commande. L'illustration ci-dessous reprsente la structure d'un iDoc. Les segments E1EDK01 et E1EDKA1 sont disposs la racine de l'iDoc ZINVOIC02A (extension de l'iDoc standard INVOIC02). Le premier segment comporte cinq sous segments, alors que le second n'en contient qu'un seul.

Illustration 16: Transaction WE32, structure d'un iDoc.

Que cela soit pour les interfaces entrantes ou pour les flux sortants, la communication entre l'EAI WebMethods et SAP repose sur des changes d'iDocs. Pour une interface sortante, l'iDoc est construit par SAP, puis envoy WebMethods. Une fois le message reu ce dernier applique des rgles de mapping pour concevoir un BDM qu'il publie ensuite sur le broker. Les messages entrants appliquent le cycle inverse: une application publie un BDM sur WebMethods qui est ensuite souscrit par le connecteur SAP, ce dernier excute des rgles de mapping pour fabriquer un iDoc qui sera immdiatement transmis SAP.

La transaction WE05 permet de visualiser les iDocs et leur tat dans SAP. Chaque tat est caractris par un numro qui est diffrent selon que l'interface soit entrante ou sortante. Les principaux tats sont lists ci-dessous:

iDoc entrants: 64: en attente de traitement; 62: en cours de traitement; 53 termin avec succs; 51: termin avec erreur; 75: iDoc en file d'attente (lorsque le traitement en file est activ).

iDocs sortants: 30: iDoc en attente de transfert; 03: iDoc transfr la couche communication; 41: confirmation de rception par le systme externe (EAI WebMethods).

Par dfaut, le connecteur SAP de WebMethods ne gre pas la mise jour des statuts. En consquence, aprs leur transfert les iDocs transmis en sortie de SAP restent dans l'tat 03: iDoc transfr la couche communication . Pour pallier le manque de visibilit sur la bonne rception des messages par l'EAI, nous avons dvelopp sur le connecteur SAP de WebMethods un mcanisme de confirmation de rception. Ainsi au bout de cinq minutes, les iDocs reus par l'EAI sont dornavant automatiquement disposs dans l'tat 41: confirmation de rception .

dum

as-0

0574

702,

ver

sion

1 - 8

Mar

201

1



4.4.2.2 Configuration ALE

La configuration ALE permet de renseigner dans le systme SAP les paramtres ncessaires aux transferts et traitements des iDocs. Cette tche repose sur la dfinition des profils de partenaires - partner profiles - et du modle de distribution - distribution model.

Les profils sont configurs au travers de la transaction WE20. Pour chaque type de message en sortie de SAP, il est ncessaire de renseigner les informations suivantes:

Nom du type l'iDoc et nom de l'extension (si applicable). Transfert immdiat activer ou non. Si le transfert immdiat est actif, alors sa cration

l'iDoc sera automatiquement transmis la couche communication. Dans le cas inverse, le message restera en attente dans SAP et sera transfr uniquement l'excution d'un programme de transfert.

Taille de paquet: valeur numrique indiquant le nombre maximum d'iDocs pouvant tre transmis au cours d'une mme communication rseau. Applicable uniquement si le transfert immdiat est dsactiv.

Port de rception: information technique identifiant la connexion avec le systme externe.

Les messages en entre de SAP requirent quant eux d'avoir les informations suivantes renseignes dans leur profil:

Code du processus: identifiant ABAP permettant de retrouver le programme utiliser pour traiter le message.

Excution immdiate activer ou non. Si activ, alors la rception l'iDoc sera automatiquement trait. Dans le cas inverse il patientera l'excution d'un programme de dclenchement des traitements.

Activer les options de traitement et de transfert immdiat permet de rduire la dure de synchronisation des systmes (la latence). Nanmoins l'impact d'une telle configuration sur les performances du progiciel SAP ncessite d'tre pris en considration.

Accessible par la transaction BD64, le modle de distribution permet quant lui d'assigner des types de messages aux profils de partenaires. Son usage est ncessaire que pour certaine

Documents

2011.TH16780.Robial.benoit