Modellering van het in kaart brengen van workflows
In Anveo EDI Connect gebruikt u normaal gesproken meerdere mappings om een EDI-proces te modelleren. In het volgende zullen we kijken naar zeer eenvoudige voorbeelden en een andere, meer complexe. De module is zeer flexibel en u kunt het proces in kaart brengen zoals u dat wilt, maar de volgende voorbeelden zijn onze aanbevolen manier om het proces te modelleren.
Laten we, voordat we te veel in detail treden, eerst een paar begrippen verduidelijken. Een mapping in Anveo EDI Connect kan worden uitgevoerd. Dan is er nog het concept van een databasetransactie. Eenvoudig gezegd, een databasetransactie verzamelt alle wijzigingen in de database tijdens een transactie. Aan het einde van de transactie kunnen de gegevens ofwel permanent worden opgeslagen, wat een databaseverbintenis wordt genoemd. Of de wijzigingen kunnen worden gereset, dat wil zeggen dat alle wijzigingen die tijdens de transactie zijn aangebracht, ongedaan worden gemaakt en niet worden opgeslagen. Elke uitvoering van een mapping wordt gedaan in een aparte databasetransactie. Als er een fout optreedt tijdens de uitvoering van de mapping, wordt de transactie teruggerold. Anders is de transactie aangegaan. (Dit geldt voor de meeste mappings. In Anveo EDI Connect zijn er tabel triggers die een willekeurige code kunnen uitvoeren. Als die code een COMMIT-commando bevat, kan de module de wijzigingen niet terugdraaien. Dit kan leiden tot ongewenst gedrag).
Inkomende XML-verkooporder
In dit voorbeeld gebruiken we drie mappings om een XML-bestand te importeren. Dit is het aanbevolen minimum. In de eerste stap brengen we de externe datastructuur in kaart om de tabellen te bufferen. Het idee is om de gegevens te importeren, ook al kunnen niet alle gegevens worden verwerkt. Dit stelt de eindgebruiker in staat om fouten in de EDI-transactie te corrigeren, zonder kennis van het externe dataformaat. Dit is natuurlijk alleen mogelijk als er gegevensfouten zijn, niet als de bestandsstructuur niet kan worden geparseerd.
De volgende stap is het controleren van de gegevens. Hier kunt u eventuele logische controles op de bedrijfsgegevens toevoegen. We raden aan om dit in een aparte stap voor de verwerking te doen om meerdere foutmeldingen te verzamelen en de eindgebruiker een volledig foutprotocol te geven. Als u gegevens uit de systeemtabel moet opzoeken en deze wilt doorzetten, doen we dat in een vierde stap tussen de externe en de controlemap.
De laatste stap is de creatie van het Microsoft Dynamics NAV 2009R2 Classic-document. Dit doen we in een aparte stap, om de tafelsloten op de systeemtafels zo kort mogelijk te houden.
Uitgaande EDIFACT Factuur
Bij uitgaande documenten heeft u meestal enkele waarden, die niet direct in de Microsoft Dynamics NAV 2009R2 Classic-brontabel zijn opgeslagen. Om de eindgebruiker de mogelijkheid te geven om deze data te zien en om de externe data format mapping te vereenvoudigen, raden wij aan om de data eerst naar een buffertabel te schrijven. In deze stap kunt u waarden opzoeken en berekeningen maken.
De export mapping neemt gewoon de gebufferde data en schrijft deze in het doelformaat.
EDI-proces met bevestiging
Het proces hoeft niet lineair te zijn. Als u bevestigingen moet versturen of als u gegevens wilt groeperen, kunt u altijd meerdere mappings uit één mapping oproepen. U kunt ook gebruik maken van voorwaarden en voorwaardelijke vertakkingen, om verschillende mappings uit te voeren op basis van de gegevens.
Hoe de Workflow in te stellen
We gaan later op de details in. Als u vooruit wilt springen, gebruiken we twee technieken om de karteringsworkflow te structureren. De zakelijke transacties en de nabewerking.