Softwareontwikkeling draait om duidelijkheid

Orkestreren van bedrijfsprocessen met BPEL

De koppeling tussen gebruikersapplicaties en de achterliggende backoffice is gebaat bij de inzet van middleware. Business Application Services van Getronics PinkRoccade gebruikt voor dit proces de taal BPEL, en heeft hiervoor een aanpak ontwikkeld. Een interview met Jos Baan neemt u mee in deze verrassende oplossing, die met een duidelijk oog richting de toekomst is ontwikkeld.

Binnen de Nederlandse IT markt is Getronics PinkRoccade van oudsher een partij waar veel kennis en expertise in huis is van deze producten. Onder de vlag van Business Application Services (BAS) valt de groep Oracle Business Solutions, een groep van 60 FTE’s die zich buigt over IT-vraagstukken. Naast hardcore kennis over Oracle’s productlijn, is ook de op XML gebaseerde taal Business Process Execution Language (BPEL) onderdeel van hun kennispakket. Jos Baan acteert binnen BAS als Oracle architect en heeft een speciale BPEL aanpak ontwikkeld.

Modelleren

De case die als rode draad door dit interview loopt betreft een bedrijf binnen de retailbranche. Dit bedrijf kent een grote geografische spreiding met vestigingen over geheel Europa, en is nog steeds groeiende. Het aantal logistieke bewegingen is over het geheel genomen fors. Daar komt bij dat de producten - naast de standaard uitvoeringen - voor zeker de helft uit maatwerk bestaan. Oracle architect Jos Baan vertelt: “De retailer wil inzicht hebben in haar voorraadverplaatsingen.

Tevens is er de wens om de financiële informatie die op decentrale vestigingen ontstaat, centraal te ontsluiten. Dit komt neer op het koppelen van de winkelautomatisering aan de op Oracle gebaseerde backoffice. De basis voor deze koppeling wordt gevormd door een middleware laag op basis van BPEL. Hiervoor moeten alle processen worden beschreven, die zijn uitgevoerd met BPEL, om precies te zijn Oracle’s BPEL Process Manager. Dit is een op XML gebaseerde taal, specifiek ontwikkeld om bedrijfsprocessen te modelleren. BPEL is geen programmeertaal, maar een handvat waarmee verbinding wordt gemaakt tussen wat de business snapt en wat IT kan.”

Argumentatie BPEL

De keuze voor BPEL is binnen deze case op een aantal argumenten gebaseerd, die overigens in generieke vorm ook voor andere vraagstukken gelden. Allereerst speelt de eis dat de ERP omgeving onafhankelijk moet kunnen opereren van de winkelautomatisering en visa versa. Als ERP uitvalt, moeten de kassa’s doordraaien. Andersom geldt ook, mochten er locaties zijn die uitvallen, dan moet ERP gewoon beschikbaar zijn voor de overige winkellocaties.

Daarnaast moeten toekomstige uitbreidingen in functionaliteit van de applicaties snel en eenvoudig zijn door te voeren. Dit is mogelijk door de beschikbaarheid van webservices, die weer eenvoudiger zijn te ontwikkelen als met BPEL de processen goed zijn beschreven. Een derde argument is dat er inzicht en duidelijkheid moet zijn in alle transacties die vanaf de winkels naar de centrale systemen geïnitieerd worden. Tot slot wil men af van proprietary oplossingen, dus streven naar echt leverancier- en techniekonafhankelijk opereren. Ook hier geldt dat vooraf de processen goed in kaart moeten worden gebracht, een activiteit waar BPEL in excelleert.

BPEL aanpak

In de praktijk bleek een BPEL project een aantal beslismomenten te bevatten. Getronics PinkRoccade BAS heeft deze beslismomenten samengevat in een aanpak genaamd ‘De 7 BPEL best practices’. Deze aanpak beschrijft op 7 verschillende deelgebieden keuzen die gemaakt moeten worden voordat BPEL kan worden ingezet. De aanpak gaat uit van JD Edwards als backoffice, maar is tevens toepasbaar met andere oplossingen. De aanpak dwingt organisaties als het ware om stil te staan bij de elementaire keuzen die nodig zijn om een BPEL implementatie succesvol te maken. De keuze op 7 deelgebieden geeft tevens het ontwikkelpad van deze implementatie aan, van strategisch naar operationeel. Hierbij geeft de onderste laag inzicht in de meest operationele activiteiten die bij de bouw van een BPEL implementatie noodzakelijk zijn. In het volgende gedeelte worden de 7 deelgebieden afzonderlijk kort beschreven.

De figuur geeft een visueel beeld van de aanpak.

BPEL als middleware

Het eerste deelgebied zegt iets over de argumentatie om überhaupt met BPEL in zee te gaan. Jos Baan legt uit: “De retailer uit de case heeft voor haar middleware oplossing gekozen voor JD Edwards. Omdat dit product inmiddels enige tijd onderdeel is van Oracle, is de keuze voor Oracle’s BPEL invulling voor middleware een logische. BPEL en JD Edwards communiceren met elkaar op een bewezen wijze via het standaard SOAP protocol. JD Edwards beschikt over Integration Points waarmee de verwerking van transacties via webservices gegarandeerd op dezelfde manier verloopt als via de interface van het pakket. Bovendien maakt BPEL het gemakkelijk om businessprocessen te definiëren. Het is uiterst flexibel, visueel en er zijn talrijke standaard bouwstenen voor handen. Ten slotte groeien JD Edwards en BPEL steeds meer naar elkaar toe. Dat biedt veel gemak bij toekomstige nieuwe releases van beide pakketten.”

Ontkoppeling front-end en back-end

In dit tweede deelgebied wordt stil gestaan bij de fysieke ontkoppeling van de front-end van de backoffice. Deze scheiding is belangrijk voor de beschikbaarheid van zowel de front-end als de backoffice. Als één van twee uit de lucht is moet de rest kunnen blijven werken. Jos zegt hierover: “De tweede keuze gaat om FTP/File Adapter versus Queue. De JMS Queue is een logische keuze hiervoor. De retailer vond het niet acceptabel dat de front-end in de winkel niet zou werken als de backoffice door bijvoorbeeld een verstoring uit de lucht zou zijn. Daarom stelde men de eis dat de front-end en backoffice fysiek ontkoppeld moesten zijn.”

Menselijk handelen: BPEL4PEOPLE

In het derde deelgebied gaat het om het kiezen van de workflow adapter, waarmee handmatige interactie mogelijk wordt als onderdeel van de procesflow. Invoegen van menselijk handelen dus, op een dusdanige manier dat naadloos kan worden samengewerkt met geautomatiseerde processen. Een voorbeeld van een interactie is het handmatig goedkeuren van een bestelling.

Synchronisatie BPEL

Deelgebied vier heeft te maken met synchronisatie van het BPEL proces. Jos vertelt hierover: “Omdat in een aantal situaties de volgordelijkheid van afhandeling van berichten van belang is, moet dit worden afgedwongen. Het BPEL proces moet dus synchroon worden, en dat is niet hoe BPEL normaliter werkt, omdat het immers op een a-synchrone werkwijze is gestoeld. Denk aan een aantal bestellingen van deelproducten die nodig zijn om een eindproduct te maken. Als de volgorde hiervan wijzigt ontstaan problemen en vooral tijdsverlies in de productie. Het beheersen van voorraadverplaatsingen is hier de leidende functionele eis geweest. Deze keuzen komen vrijwel altijd voor, maar is zeker ook in bedrijven binnen de retailbranche noodzakelijk.”

Domeinen BPEL

Sommige BPEL processen zijn opnieuw te gebruiken. Soms kan dit in een volstrekt andere omgeving binnen het bedrijf zelf plaatsvinden. Wat helpt is het promoten van BPEL processen met zogenaamde domeinen. Dit kan op een aantal manieren, en vergt wederom een keuze, ofwel deelgebied 5. Jos zegt hierover: “In deze specifieke case hebben wij gekozen om de verschillende stages in het promotieproces te definiëren door middel van domeinen. Daardoor is een scheiding van de omgeving mogelijk en beheersbaar, en kunnen BPEL processen domeinoverschrijdend gepromoot worden.”

Softwareontwikkeling draait om duidelijkheid - Jos Baan

Houdbaarheid BPEL

Het volgende deelgebied vormt een spilfunctie in de aanpak. Dit komt omdat het hier gaat om de houdbaarheid van de BPEL. Jos benoemt dit als volgt: “Het opsplitsen van het logische proces naar meer technische processen is nodig geweest omdat de interface tussen BPEL en JD Edwards aan veranderingen onderhevig is. Wij hebben hier daarom drie stappen onderscheiden, genaamd: ‘INPUT-VERWERKING-OUTPUT’. Door deze interface als losse elementen te benoemen hoeft een organisatie niet alles te vervangen als bijvoorbeeld JD Edwards wordt vervangen door SAP. In deze case bestaat de interface uit drie stappen. De meeste ontwikkeltijd is gestopt in de middelste stap, omdat deze het langste mee zal gaan. De andere twee stappen zijn immers de raakvlakken tussen BPEL en JD Edwards, en zullen met andere interfaces sneller wijzigen.”

Versiebeheer BPEL

Bij het laatste deelgebied handelt het om gecombineerd versiebeheer op zowel de logische als de technische processen. Jos Baan nogmaals: “Dit vormt het meest operationele aspect. Bij middleware is het van belang om versiebeheer over de gehele keten heen uit te rollen. Tevens moet rekening worden gehouden met de wijzigingen van de BPEL processen zelf. Hiervoor moet een naamgevingconventie worden ontwikkeld waarmee zowel de functionele versies als de technische versies worden ondersteund en inzichtelijk kunnen worden gemaakt voor programmeurs. De keuze hiervoor is eigenlijk de meest cruciale keuze binnen de aanpak. Dit komt omdat deze zogenaamde logische aanpassingen gevolgen hebben voor de gehele keten.”

Toekomst BPEL

Het gebruik van BPEL zal alleen maar toenemen is de verwachting van Jos Baan.

Softwareontwikkeling draait om duidelijkheid - Jos Baan

Jos zegt hierover tot slot: “Omdat binnen IT projecten vaker in voor klanten begrijpelijke termen moet worden gecommuniceerd, wordt de rol van BPEL steeds crucialer. Het vormt een belangrijk gereedschap dat helpt in deze communicatie. Kijk je naar Oracle dan is dit ook de lijn die het bedrijf lijkt te gaan volgen. Software moet steeds meer met het thema hergebruik worden ontwikkeld. Oracle’s Fusion Applications laat deze lijn duidelijk zien. De ontwikkeling hiervan wordt ondersteund door een denkstroom genaamd Application Integration Architecture, kortweg AIA. De manier waarop wij met BPEL omgaan in de aanpak ‘De 7 BPEL best practices’, is gekoppeld aan een back-office met JD Edwards en vertoont duidelijke raakvlakken met AIA.” Hiermee loopt Getronics PinkRoccade BAS duidelijk voorop in het denken in AIA termen in Nederland, en heeft daarmee oog voor de toekomst.

Lees meer over Capgemini BAS B.V.

Ga terug naar We Love IT uitgave 5 - 2008

Advertentie