Integratie en koppelen van AFAS Profit en andere applicaties
Gegevens van de ene IT applicatie in de andere overnemen: eitje toch? Gewoon een CSV export bij de een maken en dan bij de andere importeren. En als het niet helemaal past, dan de CSV met Excel wat bewerken, opslaan en dan pas importeren.
Tja, was het leven van integratie en koppelen in alle situaties maar zo eenvoudig, maar met de ervaring van enige honderden integratie- en koppelingsoplossingen achter de kiezen moet ik toch echt bekennen dat het professioneel koppelen van applicaties meer omvat dan een CSV export en import.
Wat maakt koppelen van applicaties dan zo lastig?
Over de uitdagingen die je bij koppelen tegenkomt kan ik een hele serie van blogs over volschrijven, maar omdat ik me nu beperk tot 1 blog (“in der Beschränkung zeigt sich erst der Meister”, naar J.W. von Goethe, 1802), geef ik eenvoudige voorbeelden die jou een indruk moeten geven van de complexiteit van IT integratie.
Ik heb de voorbeelden verdeeld over 3 basiskenmerken:
- Basisformaat van een gegeven
- Inhoud van gegeven
- Codering van een gegeven
Basisformaat van een gegeven
Laat ik eens starten met een eenvoudig gegevenselement: de naam van een organisatie, bijvoorbeeld “P.A. Jansens Staalconstructies BV”. U kunt zich goed voorstellen dat een organisatie zo’n naam heeft. Dan pak ik de praktijkcase met 2 IT toepassingen: de naam wordt in de eerste toepassing ingevoerd en daar is een veld van 60 posities voor beschikbaar. De naam moet worden overgenomen naar een andere toepassing (bijvoorbeeld een applicatie die de factuur afdrukt) en in die applicatie is voor deze naam ook 60 posities beschikbaar, verdeeld over 2 regels van 30 posities.
Niets moeilijks aan, toch?
Gewoon “P.A. Jansens Staalconstructies BV” splitsen in 2x 30, want dat is ook 60 posities?
Nu moet ik je eigenlijk aan het denken zetten en ik ga je helpen door een tekenteller lineaal bij de naam zetten.
—-+—-1—-+—-2—-+—-3—-+—-4—-+—-5—-+—-6
P.A. Jansens Staalconstructies BV
Zie je het probleem ontstaan? Ik splits de naam in 2x 30 posities:
—-+—-1—-+—-2—-+—-3—-+—-4—-+—-5—-+—-6
P.A. Jansens Staalconstructies
BV
Dat is niet fraai: de letters BV op een losse regel met bovendien een spatie ervoor, waardoor die 2 letters lelijk inspringen. Nu moet er al wat logica (lees programmerwerk) aan te pas komen, ik moet terug gaan rekenen wanneer er een spatie voor positie 30 voorkomt en de naam op die plek splitsen. Dan krijg ik als acceptabel eindresultaat:
—-+—-1—-+—-2—-+—-3—-+—-4—-+—-5—-+—-6
P.A. Jansens
Staalconstructies BV
Kortom: een simpele naamveld koppelen vergt logica, programmeerinspanning.
Inhoud van een gegeven
Een tweede voorbeeld: een datum. Ook zo’n lekkere jongen.
Het eerste systeem heeft een datumveld gevuld met de waarde “01032017”. De eerste uitdaging: is dit nu 1 maart 2017 of 3 januari 2017? Ongetwijfeld herkent u het probleem van de Amerikanen: die kunnen geen “normale” datum schrijven. Alleen nauwkeurige inspectie en definitie van het bronsysteem kan hier uitsluitsel over geven: Amerikaanse notatie of niet?
Voor het voorbeeld ga ik er hier vanuit dat we vastgesteld hebben dat het geen Amerikaanse datumnotatie is, het is dus 1 maart 2017.
Nu moeten we de datum alleen nog overzetten naar het tweede systeem. Stel dat daar de datums in het formaat “JJJJ-MM-DD” verwacht worden, dus bijvoorbeeld “2017-03-01”, dan weer moet de programmeur eraan te pas komen om tekstbewerkingen toe te voegen aan de koppeing van het veld. En voor het gemak ga ik er maar even vanuit dat het bronsysteem alleen correcte en realistische datums uitspuugt, dus niet iets van “29022017” of “01052917”. Ik verzeker je: wij gaan daar bij het maken van een geautomatiseerde koppeling niet vanuit.
En de praktijk geeft ons daarin gelijk
Kortom: een datumveld koppelen vergt analyse, controle inspectie en programmeerinspanning.
Codering van een gegeven
Weer een eenvoudig voorbeeld: bij persoonsgegevens is vastgelegd of het een man of een vrouw betreft.
Ik kan een aantal regels opschrijven met de voorbeelden van codering die we hiervoor aangetreffen: m/v, m/f, M/V, male/female, Man/Vrouw, 0/1, De heer/Mevrouw, Dhr./Mvr., Dhr/Mvr, Dhr/Mevr, etc. Oftewel: er wordt van alles gebruikt voor coderingen.
In het beste geval is de codering in het bronsysteem een gecontroleerde invoer, zodat de ingevoerde waarde structureel gecodeerd is, maar geloof me, er zijn ook diverse systemen waar het veld voor de aanhef vrije invoer is en het aan de creativiteit van de invoerder wordt overgelaten wat die daar dan invult.
Even uitgaande van het feit dat het ontvangende systeem een structurele codering vereist, bijvoorbeeld 0/1 (voor Man/Vrouw), dan moeten we mapping programmeren, bijvoorbeeld: de tekst “Man” moet in de koppeling omgezet worden naar “0”, “Vrouw” naar “1”. Ik noem dit ritssluitingssoftware.
Een synchrone of asynchrone ritssluiting?
Het wordt nog interessanter als het aanleverende systeem verschillende varianten heeft voor man (of vrouw), want dan moeten we teruggrijpen op een asynchrone ritssluiting: het is dan de serie van: “Man” of “man” of “De heer” of “Dhr” moet geconverteerd worden naar “0”.
Je begrijpt: ook hier is nauwkeurige analyse van de brongegevens essentieel.
Kortom: een codeveld koppelen vergt analyse, ritssluitingssoftware en programmeerinspanning.
En dat is alles?
Nee hoor, koppelingen maken kan nog veel interessanter worden: combineren van velden, standaard waardes voor niet gevulde velden, berekende nieuwe waardes afhankelijk van de waardes van andere velden, stringente validatie van aangeleverde gegevens (indachtig het paradigma All input is evil).
Specificatie en analyse van de beschikbare gegevens is essentieel om interpretatieverschillen te voorkomen.
En dan mogen we niet voorbij gaan aan de executie, controle, logging: hoe vaak moet de koppeling werken? Ieder uur? Eenmaal per dag of week? Op afroep? Hoe ligt het resultaat vast? Waar vind ik een verslag van de bewerkingen in de koppeling? Waar treden fouten op? Hoe kan ik een testbestand ter controle maken? Kan ik de gegevens uit een bijlage van een email halen? Of het resultaat weer als bijlage aan een email toevoegen? Een Excel file als output leveren? enz. enz.
Kortom: een geautomatiseerde koppeling tussen verschillende IT toepassingen is serieus werk.
Kijk daarom eens bij de ervaring die wij op dit gebied hebben en de toolkit die wij voor integratie en koppelen hebben gemaakt, onze ConneXtor oplossing. Daarin zijn alle de bovenstaande bewerkingen en nog veel meer, als configureerbare bouwstenen beschikbaar. Geen programmeren, maar analyseren en configureren.
Vragen over koppelingen met AFAS Profit?
Benieuwd hoe wij je helpen met een koppeling tussen AFAS Profit en jouw software systemen?
Dit blog is voor het eerst gepubliceerd in november 2022 en nog steeds actueel. Want integraties, soorten velden en codering van gegevens, dat is iets wat gewoon hetzelfde blijft.
