Handleiding voor een succesvolle integratie tussenMicrosoft BizTalk Server en

Microsoft Dynamics AX

Whitepaper

Auteur:

Jasper Defesche

Versie 1.0

24 januari 2011

Reviewers

Mijn dank gaat uit naar de volgende reviewers van deze whitepaper:

Peter Vervoorn, AXon Olympus

Jonathan Gurevich, AXon Olympus

Marcel Fernee, Microsoft Nederland

Copyright

© 2011, AXon Olympus

Alle rechten voorbehouden.

Microsoft BizTalk Server en Microsoft Dynamics AX zijn handelsmerken of gedeponeerde

handelsmerken van Microsoft Corporation.

Niets uit deze uitgave mag worden verveelvoudigd, opgeslagen in een geautomatiseerd

gegevensbestand en/of openbaar gemaakt in enige vorm of op enige wijze, hetzij elektronisch,

mechanisch, door fotokopieën, opnamen of op enige andere manier zonder voorafgaande

schriftelijke toestemming van AXon Olympus.

3Inhoudsopgave

1. Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Bronnen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3. Woordenlijst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

5. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

6. Projectaanpak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

7. Architectuur en inrichting BizTalk / AX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

8. Implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

9. Slotwoord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Voor het ontsluiten van en het koppelen met

Microsoft Dynamics AX (AX) is Microsoft

BizTalk Server (BizTalk) de geëigende tool.

Hiermee kan een waaier aan integratie

uitdagingen worden opgelost.

Ondanks de uitgebreide (standaard) tooling

zowel binnen BizTalk en AX, blijft een aantal

valkuilen op verschillende gebieden over:

Projectmatig•

Architectuur•

Implementatie•

Aan de hand van een voorbeeld wordt

uitgelegd hoe een succesvolle integratie

tussen AX en BizTalk bewerkstelligd wordt.

Hierbij wordt niet gepoogd om de bestaande

whitepapers van Microsoft1 die in uitgebreide

technische stappen beschrijven hoe BizTalk

en AX in algemene zin zijn te koppelen, te

‘herschrijven’. Deze whitepaper is veel meer

praktisch van aard: gebaseerd op

concrete projecten geeft dit de lezer een veel

beter inzicht in de integratie aspecten tussen

BizTalk en AX. Hiermee worden dure valkuilen

vermeden.

Deze whitepaper benadert de probleemstel-

ling op alle drie niveaus in een project:

projectmanagement, architectuur en

implementatie.

Probleemstelling1.

1 Zie hoofdstuk 2

Bronnen2.

De volgende bronnen zijn geraadpleegd bij het samenstellen van deze whitepaper.

Nr Naam Locatie

1 Microsoft BizTalk Server and Microsoft

Dynamics AX: Integration Solutions for

the Extended Enterprise

http://download.microsoft.com/

download/3/4/0/340C228D-05F0-4D85-BDAE-

B72E63A046E5/MicrosoftDynamicsAX_BizTalk_

WhitePaper.doc

2 Introducing Microsoft BizTalk Server

2009

http://go.microsoft.com/?linkid=9658773

3 Dynamics AX: ERP-software voor

grote organisaties (voorheen AXapta)

http://www.microsoft.com/netherlands/dynamics/

product/AX_overzicht.aspx

4 Microsoft Dynamics AX 2009 AIF

BizTalk Adapter Configuration White

Paper

http://www.microsoft.com/downloads/details.

aspx?familyid=edc62433-5b21-4f74-b065-

b075ba6dc86d&displaylang=en

6 Microsoft Dynamics AX 2009 White

Paper: Application Integration Frame-

work (AIF)BizTalkAdapterConfigura-

tion for Data Exchange, Part II

http://www.microsoft.com/downloads/details.

aspx?FamilyID=c06033bb-ba3a-4237-9ab8-

d7b77c0439be&displaylang=en

7 Understanding BizTalk Server 2006

R2

http://download.microsoft.com/download/e/3/c/

e3c6b6d8-7fec-459e-9479-1cd320019244/

Introducing%20Microsoft%20BizTalk%20

Server%202006%20R2.pdf

5Woordenlijst3.

De onderstaande begrippen worden in deze whitepaper gebruikt.

Begrip Omschrijving

AIF Application Integration Framework

Het integratie platform van Dynamics AX dat wordt

gebruikt voor webservices, wachtrijen en BizTalk integratie

AIF wachtbak Locatie in AX waar alle asynchrone berichten worden

opgeslagen.

Asynchroon Het versturen van berichten naar AX waarbij door BizTalk

niet wordt gewacht op antwoord. Wanneer het antwoord

arriveert zal BizTalk deze koppelen met het juiste proces

om deze vervolgens verder te laten lopen.

Synchroon Het versturen van berichten naar AX waarbij BizTalk actief

wacht op antwoord.

BizTalk Group Verzameling van meerdere BizTalk servers die samenwer-

ken bij het afhandelen van berichten.

Service Functionaliteit die een applicatie beschikbaar stelt voor

andere applicaties.

Verrijking Het uitbreiden van berichten met extra gegevens.

Adapter Software verantwoordelijk voor fysieke communicatie

tussen BizTalk en aansluitende systemen

Batchbestand Bestand dat op vaste intervallen in bulk wordt

samengesteld.

XSD XMLSchemaDefinition:gestandaardiseerdespecificatie

diegebruiktkanwordenomberichtdefinitiesvastte

leggen.

Artifact Component dat onderdeel uit maakt van een BizTalk

deployment. Te denken valt aan een berichttransformatie

(mapping), een orchestration, een pipeline, etc.

Alvorens verder te gaan, is het belangrijk

om stil te staan bij de betekenis en rol van

Microsoft BizTalk Server respectievelijk

Microsoft Dynamics AX.

Microsoft BizTalk Server

Microsoft BizTalk Server is een serverproduct

voor Enterprise Application Integration dat

kan worden ingezet als Business Process

Management Server of Enterprise Service

Bus. Dit stelt bedrijven onder andere in

staat om te integreren, automatiseren en

bedrijfsprocessen te beheren. Door krachtige

tooling is het mogelijk om een breed scala

aan integratievraagstukken op een standaard

manier op te lossen.

Context4.

Bovenstaandefiguurtoonteenschematisch

overzicht van Microsoft BizTalk Server.

Ieder bericht dat in Microsoft BizTalk Server

binnen komt wordt allereerst ontvangen

door een Receive Adapter. Na het eventueel

transformeren van het bericht ontstaat

een (XML) bericht dat wordt opgeslagen

in de BizTalk database (MessageBox).

De MessageBox draagt zorg voor de routering

van inkomende berichten. Hiervoor wordt

het mechanisme van subscriptions gebruikt:

geïnteresseerde systemen abonneren zich

op berichten: dit kan dus een orchestration

zijn om een ingewikkelder business proces

te organiseren en begeleiden, maar ook een

uitgaande stroom naar een derde partij of

ander systeem. Bij het verlaten van Microsoft

BizTalk Server kan het bericht wederom

vertaald worden, alvorens het door de Send

Adapter aan de ontvanger wordt afgeleverd.

Een overzicht van standaard Microsoft BizTalk

Server functionaliteiten:

Ondersteuning van diverse protocollen en •

standaard aansluitingen op applicaties/

systemen

Berichttransformaties•

Business Rule Engine•

Business Process Management•

Business Activity Monitoring•

RFID•

Receive Port

Orchestration

XMLMessage

XMLMessage

XMLMessage

ReceiveAdapter

DataMapping

ReceivePipeline

DataMapping

SendAdapter

SendPipeline

Send Port

IncomingMessage

OutgoingMessage

Message Box

Subscriptions

Message Path

Bron: Understanding BizTalk Server

2006 R2, David Chappel,

augustus 2007

7

BizTalkisvollediggebouwdophet.NETframework,watdeflexibiliteitgeeftomuitbreidingen

te maken.

Microsoft Dynamics AX

Microsoft Dynamics AX is het ERP pakket van Microsoft gericht op relatief grote

bedrijven. Het biedt functionaliteit op het gebied van inkoop, verkoop, boekhouding,

voorraadbeheer, etc.

Aan de hand van een voorbeeld wordt uitgelegd hoe een succesvolle integratie tussen Microsoft

Dynamics AX en Microsoft BizTalk Server bewerkstelligd wordt.

Bron: http://www.microsoft.

com/belux/nl/dynamics/

images/screenshotimages/

RoleCenterScreenshots.jpg

Bedrijf FB1 is een bedrijf met meerdere

divisies waarbij AX over de gehele linie

wordt ingezet. Daarnaast bestaat er een

oud systeem OS1 waar op dit moment nog

mee wordt gewerkt. Dit systeem produceert

facturen voor klanten. Deze facturen moeten

worden ingelezen in AX. Zie onderstaande

schematische weergave.

Scenario5.

OS1DIV1

FB1

DIV2 DIV3

De facturen worden in batches •

aangeleverd bestaande uit platte tekst.

AX wordt ingezet als het hoofdsysteem •

voor de administratie van klantgegevens.

OS1 werkt divisie overstijgend. •

Relevante gegevens van nieuwe en •

gewijzigde klanten moeten worden

bekend gemaakt in OS1.

Deze vraag is heel breed en dus op velerlei

manieren te beantwoorden. Omdat er

bovendien verschillende aspecten zijn die

hierbij een rol spelen, is het handig om

deelvragentedefiniërenendezetegroeperen.

Met de volgende categorieën worden de

belangrijkste aspecten afgedekt:

Projectaanpak•

Architectuur en inrichting BizTalk / AX•

Implementatie•

Deze punten worden in volgende hoofdstukken

verder uitgewerkt.

Bij het verder uitwerken van het scenario worden de volgende uitgangspunten gehanteerd:

Hoe kunnen we OS1 met AX laten communiceren middels BizTalk?

Projectaanpak6.

FB1 heeft er voor gekozen om in een vroeg

stadium mensen van verschillende disciplines

bij elkaar te zetten in een werkgroep:

Materiedeskundige OS1•

Consultant implementatiepartner AX•

BizTalk specialist•

Materiedeskundige FB1 aan de AX zijde•

Projectleider•

De groep als geheel is verantwoordelijk voor

de uiteindelijke implementatie van de BizTalk

/ AX keten. Omdat kleine details een reeds

uitgedachte oplossing nutteloos kunnen

maken, is het belangrijk dat goed nagedacht

wordt over de volgende onderwerpen:

Werking van de keten

Inzicht in de werking van de keten is essentieel

voor een succesvolle implementatie:

Welke onderdelen binnen de keten worden

onderkend, hoe werken ze samen en waar

kunnen fouten optreden en hoe moet dan

geacteerd worden?

Met name bij complexere interfaces (bijv.

interfaces met meerdere in- en uitgaande

berichten naar verschillende systemen) is

het erg belangrijk om niet alleen te kijken

naar de zogenaamde happy flow. Ook de

uitzonderingssituaties moeten uitgewerkt

worden. Indien hier onvoldoende rekening

mee gehouden wordt, is de kans op een

onnodig hoge beheer inspanning en

bijbehorendekostensignificant.

De groep besluit om de interface te simuleren

in een workshop, om zo de verschillende

scenario’s vast te stellen.

Demonstreren

Hoewel tijdens de workshop al zo veel

mogelijk zaken in een vroeg stadium

onderkend worden, is het in sommige gevallen

onontbeerlijk om een demonstratie te geven.

Er zijn nu eenmaal zaken die pas beginnen te

leven zodra ze echt gezien/ervaren worden.

Mapping & matching

Mapping & matching is het proces om te

komen tot een volledige berichttransformatie

tussen OS1 en AX. Hierbij is het belangrijk om

vast te stellen hoe en waar de gegevens in

AX moeten worden opgeslagen. Dit is alles

bepalend voor het type en formaat van het

bericht dat naar AX gestuurd wordt. Indien

hier later veranderingen in aangebracht

worden, zal een deel van het integratiewerk

9opnieuw gedaan moeten worden. Dit kan een

grote impact hebben op de doorlooptijd van

het project.

De werkgroep besluit om de facturen uit

OS1 binnen AX als vrije-tekstfacturen2 op

te slaan. Dit besluit is mede gebaseerd op

het argument dat AX een standaard service

hiervoor heeft.

Belangrijke vragen die hier spelen zijn:

Welke gegevens zijn vanuit de business

gezien noodzakelijk in AX?

Hoe matchen de gegevens en structuur •

tussen de berichtformaten van OS1 en

AX?

Wat is de benodigde berichttransformatie?•

Hoe kan het beste omgaan worden met •

verrijking van berichten uit OS1?

Wat is de scope van het integratietraject?•

Welke interface aangelegenheden worden •

in BizTalk onder gebracht en welke in AX?

Foutafhandeling

Bij communicatie tussen systemen kunnen

allerhande fouten optreden. Om beheerders

van de systemen in staat te stellen adequaat

te reageren op deze fouten is een goede

foutafhandeling noodzakelijk.

Belangrijke vragen die gesteld moeten worden

met betrekking tot foutafhandeling zijn:

Welke fouten kunnen op voorhand worden •

onderkend?

Welke manieren van foutafhandeling zijn •

binnen de organisatie bekend of zijn het

meest geschikt?

Afgezien van deze vragen is het ook

belangrijk om te kijken naar een goed

foutafhandelingsmechanisme tussen BizTalk

en AX zodat op alle fouten correct geacteerd

wordt.

Technische eigenschappen

Zijn er technische eigenschappen die

impact hebben op het project in termen van

doorlooptijd en kosten?

Te denken valt aan berichtgroottes,

frequenties, non-functionele requirements

op het gebied van bijvoorbeeld beveiliging,

performance, etc. Naast deze onderdelen

is het eveneens belangrijk dat energie en

tijd worden gestoken in het vaststellen van

een BizTalk / AX architectuur. Zonder deze

architectuur kan een wildgroei aan BizTalk

en/of AX objecten ontstaan, hetgeen de

onderhoudbaarheid en toekomstvastheid

niet ten goede komt.

2 Een vrije-tekstfactuur is de AX term

voor een klantfactuur die niet is

gekoppeld aan een verkooporder en

stelt externe systemen in staat om

klantfacturen aan AX aan te bieden.

Architectuur en inrichting BizTalk / AX7.

In de Microsoft whitepapers3 wordt duidelijk

beschreven hoe de communicatie tussen

BizTalk en AX geregeld moet worden.

Deze whitepaper poogt zoals gezegd niet om

de bestaande whitepapers te herschrijven,

maar geeft wel een aantal belangrijke

aanvullingen op het gebied van:

Het AIF-model•

Omgang met meerdere bedrijfsrekeningen •

binnen AX

Omgang met meerdere BizTalk Groups•

Organisatie BizTalk artifacten•

3 Zie bronnen 4 en 5

AIF-model

Binnen AIF is een groot aantal instellingen

mogelijk. Dit biedt veel flexibiliteit, maar

het vergt een gedegen begrip van de AIF

termen en objecten met hun onderlinge

samenhang. Onderstaand figuur toont de

belangrijkste objecten binnen AIF waarmee

de communicatie naar AX geconfigureerd

kan worden:

AXBedrijfs-rekening

Lokaaleindpunt

Eindpunt Actie-beleid

1..* 1..* 1..* 1..*

FB1 heeft er voor gekozen om in een vroeg stadium mensen van verschillende disciplines bij

elkaar te zetten in een werkgroep:

Object Omschrijving Relatie met

AX De softwarecomponent AX. Bedrijfsrekening

Een AX instantie kan voor

meerdere divisies zijn opgezet.

Bedrijfsrekening Logische opdeling binnen een bedrijf.

Veelaleendivisieofapartefinanciële/

juridische eenheid.

Lokaal eindpunt

Hoewel een bedrijf meerdere

lokale eindpunten kan hebben

zal dit niet vaak toegepast

worden. Een lokaal eindpunt zal

dus meestal gelijk zijn aan het

bedrijf.

Lokaal eindpunt Bron van verzonden berichten en doel

van ontvangen berichten.

Eindpunt

Berichten kunnen vanaf

verschillende voor AX externe

plekken komen, maar naar

hetzelfde lokale eindpunt

moeten (lees: hetzelfde bedrijf).

Eindpunt Publieke ingang van AX. Hier kunnen

andere bedrijven en applicaties hun

berichtenafleverenenophalen.Erkan

gekozen worden voor meerdere

eindpunten: bijvoorbeeld één voor

interne systemen en één voor

leveranciers.

Actiebeleid

Per eindpunt kan ingesteld

worden welke typen berichten

gestuurd mogen worden.

Actiebeleid Het actiebeleid beschrijft welke

services beschikbaar zijn op een

eindpunt. Wanneer een service op een

eindpunt beschikbaar is gesteld, kan

bovendien (middels gegevensbeleid)

worden aangegeven welke velden uit

een bericht beschikbaar/zichtbaar zijn.

Ook wordt hier het verplicht of

optioneel zijn van velden geregeld.

11

De door BizTalk geïnitieerde actie ‘Lees

resultaat’ loopt continu: op een vastgesteld

tijdsinterval zal BizTalk aan AX (AIF) vragen

of er nog berichten aanwezig zijn met de

status ‘Gereed’ en richting ‘Uitgaand’.

Dit is beter bekend als een polling-based

adapter. Bij het stellen van deze vraag

wordt niet gekeken naar de oorsprong van

het bericht (m.a.w. het systeem dat ‘Stuur

bericht’ heeft geïnitieerd wordt genegeerd).

Het resultaat is dat BizTalk servers die

in verschillende groepen zitten maar

wel berichten naar dezelfde AX sturen,

antwoordberichten van elkaar kunnen

wegnemen. Wanneer dit gebeurt stagneert

een proces binnen de eerste BizTalk Group

omdat het wacht op antwoord. Tegelijkertijd

ontstaat op de tweede BizTalk Group een

foutmelding omdat er geen proces is dat zit

te wachten op dit antwoord.

Meerdere bedrijven

Bij FB1 bestaan meerdere divisies. Iedere

divisie is ingericht als bedrijfsrekening binnen

AX. Het is belangrijk dat de juiste facturen bij

het juiste bedrijf worden afgeleverd. Wanneer

in de integratielaag hier geen rekening mee

is gehouden, is het niet mogelijk om met

meerdere bedrijfsrekeningen om te gaan.

Meerdere BizTalk Groups

Vanuit het verleden heeft iedere divisie zijn

eigen, onafhankelijke opererende, BizTalk

Group (met eigen BizTalk en SQL servers).

Bij de asynchrone communicatie met AX

ontstaat hierbij een probleem. Om dit uit te

leggen is het noodzakelijk om te kijken hoe

BizTalk en AX samenwerken bij asynchrone

communicatie. Onderstaand figuur toont in

de basis deze samenwerking.

Stuur bericht

BizTalk AIF processing AIF Wachtbak

Lees bericht

Plaats bericht

Verwerkbericht

Lees resultaat

Geef resultaat

Een aantal mogelijkheden om dit op te lossen:

Installeer een separate BizTalk Group die alle communicatie met AX verzorgt. Nadeel: dit is •

een relatief duur alternatief aangezien dit extra licentiekosten met zich meebrengt.

Geef één bestaande BizTalk Group de verantwoordelijkheid om alle communicatie met AX •

te verzorgen. In deze variant moet een mechanisme worden gebruikt dat er voor zorgt dat

de juiste BizTalk Group de juiste antwoorden ontvangt. Indien dit niet gebeurt, blijft

bovenstaand probleem actueel.

Alle communicatie met AX synchroon uitvoeren. Dit vergt een uitgebreidere interface in •

termen van foutafhandeling en beheer, aangezien de beheermogelijkheden in AX beperkter

zijn. Dit komt omdat in de synchrone communicatie variant de AIF wachtbak wordt

overgeslagen. Hierdoor is er aan de AX zijde geen mogelijkheid om de berichten opnieuw

te verwerken. Bij asynchrone communicatie met AX is deze mogelijkheid er wel.

Dekeuzeissterkafhankelijkvandespecifiekesituatie.Eenone-size-fits-allkeuzeiserderhalve

niet.

Organisatie BizTalk onderdelen (artifacts)

Het berichtformaat voor de communicatie

tussen AX en BizTalk ligt vastgelegd in

schema’s (XSDs). De schema’s kunnen

uit AX worden gegenereerd. Om de

uitbreidbaarheid van de BizTalk oplossing

en de onafhankelijkheid tussen verschillende

berichtstromen te garanderen is het erg

belangrijk dat deze schema’s ieder in een

apart Visual Studio project worden geplaatst.

Zodoende kunnen meerdere berichtstromen

gebruik maken van hetzelfde schema

zonder dat fouten in BizTalk optreden.

Nog belangrijker is dat er geen onnodige

afhankelijkheden tussen processen en

schema’s ontstaan.

Om de BizTalk omgeving overzichtelijk

te houden en deployment naar andere

omgevingen te vergemakkelijken dient

gebruik gemaakt te worden van zogenaamde

Applications. Een Application is een

logische groepering van bij elkaar horende

artifacts. Met een eenduidige en uitgebreide

naamgeving van de Applications wordt in

één oogopslag duidelijk wat er binnen een

Application gebeurt, zonder dat alle artifacts

afzonderlijk bekeken hoeven te worden.

Na een keuze in aanpak en architectuur kan

tot implementatie worden overgegaan. Als

eerste wordt gestart met de keten. Door

de aanwezigheid van de diverse disciplines

kan de gehele keten worden gesimuleerd.

Hoewel hiermee niet alle onduidelijkheden

worden weggenomen, zorgt dit proces er

wel voor dat de belangrijkste interfaces

worden onderkend en een gedeeld gevoel

ontstaat over de werking van de keten. De

projectleider heeft de belangrijke taak om

het gehele proces te faciliteren waarbij hij of

zij de hoofd- en bijzaken goed moet kunnen

onderscheiden.

De volgende fases worden onderkend:

1. Scope van het project

2. Ketenanalyse

3. Oplossing/Realisatie

4. Overdracht

Implementatie8.

13Fase 1 Scope van het project

Omdat niet met alle keuzes uit het verleden

rekening gehouden kan worden, moet het

project duidelijk afgebakend worden. Het is

erg belangrijk dat dit goed in de gaten wordt

gehouden, zeker op het gebied van integratie.

Als uitgangspunt binnen FB1 wordt genomen

dat de klantenadministratie in AX bijgehouden

wordt, dat er geen klanten worden verwijderd

en dat OS1 niet aangepast wordt. Zodoende

blijft de scope werkbaar en controleerbaar.

Fase 2 Ketenanalyse

Bij het uitvoeren van de ketenanalyse wordt de

totale keten nagespeeld door de werkgroep.

Door hoofd- en bijzaken goed te scheiden

wordt bereikt dat dit proces niet verzandt

in details. Het is erg belangrijk om acties en

besluiten goed vast te leggen zodat hier later

op teruggevallen kan worden.

Binnen FB1 levert het naspelen van de keten

de volgende interfaces op:

Nieuwe en gewijzigde klanten moeten •

bekend worden in OS1.

Facturen moeten van OS1 naar AX•

Fase 3 Oplossing/Realisatie

Klanten naar OS1

Standaard heeft AX geen mogelijkheid om

wijzigingen van klanten te publiceren zodat

deze in andere systemen bekend kunnen

worden gemaakt. Door maatwerk binnen AX

is dit wel te realiseren. Te denken valt aan een

mechanisme dat wijzigingen in de klanttabel

publiceert in de AIF wachtrij, waarin deze

klaar staan voor BizTalk.

Een andere mogelijkheid is om BizTalk te

configureren om de laatste wijzigingen op

een vaste frequentie op te halen. Dit vergt

evenwel ook maatwerk binnen AX. Verder

behoren het op gezette tijden overzetten van

alle gegevens en het procedureel afhandelen

van klantmutaties tot de mogelijkheden. Alles

bepalend zijn de gegevenshoeveelheid en

wijzigingsfrequentie.

Omdat de wijzigingsfrequentie niet hoog is kiest

het team voor een batchgewijze verwerking: op

vaste tijdstippen worden de klantengegevens

naar de juiste divisie geëxporteerd.

Zieonderstaandfiguur:

AX BizTalk

Divisies

AX verstuurt dagelijks een lijst met leveranciers. Dit is in een eenduidig formaat dat gebruikt

wordt per leverancier. BizTalk regelt de vertaling van het bericht en de routering naar de juiste

divisie.

Facturen naar AX

De voorgestelde oplossing ziet er als volgt uit:

AXBizTalk

Divisies

De diverse divisies sturen hun bericht naar

BizTalk. Voor de verwerking richting AX wordt

gebruik gemaakt van een orchestration die

de vertaling uitvoert naar het AX formaat

en de juiste communicatie opzet met AX.

Tevens is hier de mogelijkheid om acties te

ondernemen wanneer fouten optreden of

wanneer het antwoord van AX niet binnen

de ingestelde duur wordt ontvangen door

BizTalk.

Tijdens de implementatie is gebleken dat het

klantnummer uit AX niet overeenkomt met het

klantnummer uit OS1. Dit kan bijvoorbeeld

komen door een nieuwe nummering of een

ongelijk formaat. Omdat het aanpassen

van OS1 niet opportuun is, zal er een

vertaling moeten plaatsvinden van het OS1

klantnummer naar het AX klantnummer. Er is

hiervoor een aantal alternatieven:

1. Het klantnummer dat bekend is in OS1 wordt opgenomen binnen AX als externe code, gebruik

makend van reeds bestaande mogelijkheden van AX.

2.Het OS1 klantnummer wordt als nieuw veld toegevoegd aan de AX klantentabel en de

bijbehorende onderdelen (formulieren, classes, etc.).

3. Binnen BizTalk wordt een vertaaltabel bijgehouden tussen klantnummers uit OS1 en AX.

4. Binnen BizTalk wordt het AX klantnummer afgeleid van het OS1 nummer volgens een vast

algoritme.

15Alternatief 1: Klantnummer = externe code

Bij deze optie wordt het OS1 klantnummer als externe code gekoppeld aan de klantgegevens

binnenAX.Zieonderstaandfiguur:

Door middel van configuratie op het eindpunt binnen AX wordt automatisch een vertaling

gemaakt van de externe code naar het interne nummer.

Zieonderstaandfiguur:

Voordelen:

Gebruik van standaard features binnen AX •

(geen maatwerk).

Geen vertaaltabel en functioneel •

onderhoud binnen BizTalk.

Wordt standaard ondersteund door AIF.•

Nadelen:

Bij het uitfaseren van OS1 moet de •

inrichting van AX worden aangepast.

Procedurele afstemming noodzakelijk over •

hoe het OS1 nummer in de Externe code

wordt opgeslagen. Bij bestaande klanten

kan dit nog opgelost worden binnen het

conversie traject maar voor nieuwe

klanten moeten afspraken gemaakt

worden.

Voordelen:

Makkelijker te gebruiken in AX. •

Geen vertaaltabel en functioneel •

onderhoud binnen BizTalk.

Nadelen:

Maatwerk binnen AX.•

Standaard geen ondersteuning voor het •

extra veld binnen AIF.

Bij uitfasering van OS1 moet AX •

aangepast worden. Dit is meer dan

inrichting alleen.

De factuurinterface van AX werkt alleen •

met AX klantnummers. BizTalk zal eerst

aan AX het klantnummer moeten

opvragen op basis van het OS1

klantnummer. Het versturen van een

factuur wordt binnen de interface derhalve

een tweetrapsraket.

Eveneens procedurele afspraken •

noodzakelijk bij het opvoeren van nieuwe

klanten.

Ook klanten in AX die niet in OS1 hoeven •

te komen hebben wel dit extra veld.

Alternatief 2: Klantnummer = extra veld

Dit alternatief behelst het aanmaken van een extra veld op de klantentabel waarin het OS1

klantnummerwordtopgenomen.Zieonderstaandfiguurvooreenimpressie:

17Alternatief 3: Vertaaltabel BizTalk

Binnen deze optie is een vertaaltabel aanwezig die BizTalk raadpleegt zodra facturen uit OS1

naar AX worden gestuurd. Ieder OS1 klantnummer wordt omgezet naar het bijbehorende AX

klantnummer. Schematisch ziet dit er als volgt uit:

Voordelen:

Geen aanpassing noodzakelijk binnen AX.•

Standaard AIF services kunnen worden •

gebruikt

Uitfaseren OS1 kan geïsoleerd gebeuren. •

Er zijn geen raakvlakken met AX.

Nadelen:

Vereist een adequate en capabele BizTalk •

(Functioneel) Beheer organisatie: het

onderhoud van de vertaaltabel vergt meer

werk en ook is de kans op fouten in de

interface groter (als gevolg van het niet

kunnen vinden van het bijbehorende AX

klantnummer).

De interface voor het aanmaken van •

klanten in OS1 wordt uitgebreider en

daardoor foutgevoeliger: niet alleen moet

de nieuwe klant worden opgevoerd in

OS1, ook moet er een vertaalregel worden

vastgelegd tussen het AX en het OS1

klantnummer. De kans is groot dat deze

vertaalregel pas opgeslagen kan worden

nadat de klant is aangemaakt binnen OS1.

in

uit

Klantnummer-Vertaaltabel

[Klantnummer OS1]

[Klantnummer AX]

Voordelen:

Nergens in de keten zijn vertaaltabellen •

aanwezig.

Nadelen:

Geen volledige vrijheid om het AX •

klantnummer in te richten: het

klantnummer moet met zekerheid af te

leiden zijn uit gegevens binnen OS1.

Invloed van OS1 blijft aanwezig, ook na •

een eventuele uitfasering.

Heeft duidelijke impact op eventuele •

conversie van gegevens naar AX.

Een nieuwe formattering in klantnummers •

binnen AX(bijv. als de range van

klantnummers opraakt) kan niet zonder

meer worden uitgevoerd. In het ergste

geval moet de interface aangepast

worden.

Alternatief 4: Afleiden AX klantnummer

BijhetafleidenvanhetAXklantnummergebruiktBizTalkeenvoorafontworpenalgoritmeomhet

AX klantnummer te bepalen. De aangewezen manier om dit binnen BizTalk te realiseren is een

transformatie(mapping).InonderstaandfiguurwordthetklantnummeruitOS1samengevoegd

met de tekstfragmenten ‘KL’ (deze komt voor het OS1 klantnummer) en ‘0’ (komt achter het

OS1 klantnummer).

19Om tot een keuze te komen, kijkt het team

naar de complexiteit en afhankelijkheid.

Immers, hoe minder complex een oplossing is

en hoe meer deze de onafhankelijkheid tussen

OS1 en AX waarborgt, des te beter het alter-

natief. Met deze gedachte in het achterhoofd

kiest het team voor optie 1. Dit alternatief is

veruit het beste omdat zo veel mogelijk stan-

daard features worden gebruikt.

Fase 4 Overdracht en nazorg

Na het realiseren en het functionele acceptatie

testen van de gehele oplossing dient er een

overdracht naar de beheersorganisatie plaats

te vinden. Het begrip van zowel de functionele

als technische werking van de oplossing zal

belegd moeten zijn in de organisatie.

Vanuit een technisch beheer perspectief moet

duidelijk zijn welke technische fouten kunnen

optreden en wat de te nemen acties zijn.

Functioneel geldt dit ook, maar hier zal veel

meer kennis aanwezig moeten zijn over de

werking van de gehele keten. Als deze zaken

goed gedocumenteerd zijn, dan kan bij een

wijziging van een onderdeel direct een

eventuele impact elders in de keten worden

onderkend.

Tijdens het project zullen fouten en situaties

optreden die ook zullen voorkomen wanneer

het geheel aan de beheerorganisatie is

overgedragen. Het is daarom belangrijk om

deze kennis vast te leggen vanuit het project

en dit mee te nemen als onderdeel van de

oplevering.

Tot slot zal een nazorg fase er voor moeten

zorgen dat eventuele vragen en problemen zo

snel mogelijk worden geadresseerd.

Door de gefundeerde beslissingen en de

uitgevoerde projectactiviteiten worden risico’s

sterk beperkt en zullen projecten aanzienlijk

succesvoller zijn.

Slotwoord9.

Om interne en externe systemen met AX te

laten communiceren is BizTalk het geëigende

product. Alle vertalingen tussen inkomende en

uitgaande berichten en communicatiewijzes

(protocollen) worden ondersteund. Hiermee

wordt de reikwijdte van AX enorm vergroot.

Met de inzet van BizTalk ontstaat een centrale

plek waar al het berichtenverkeer wordt

georganiseerd, gemonitord en gecontroleerd.

Dit voorkomt (veelvuldig) maatwerk in

aan-sluitende systemen, waaronder AX.

De aanbevelingen in deze whitepaper zijn

gebaseerd op de ervaring opgedaan tijdens

diverse projecten. Door deze aanbevelingen te

volgen zullen integratieprojecten tussen

BizTalk en AX sneller en minder risicovol

verlopen.

AXon Olympus B.V.

Industrieweg 1A-4

4104 AP Culemborg

The Netherlands

T. 0800-AXONOLYMPUS

www.AXonolympus.nl

Met meer dan 9 jaar gespecialiseerde Microsoft BizTalk Server expertise in huis, leveren

wij onze klanten ongeëvenaarde ICT integratie en BPM oplossingen. Met ons team

van gecertificeerde BizTalk Server experts en onze ervaring met het koppelen van een

grote verscheidenheid van systemen en databases zoals Baan, SAP, Oracle, KofAX en

Microsoft producten als Dynamics AX, Dynamics Nav en Dynamics CRM zijn wij in staat

onze expertise succesvol in te zetten voor uw dringende BizTalk Server wensen.