Migration Cockpit
In de SAP S/4HANA-omgeving is één van de meest voorkomende oplossingen voor master datamigratie en load – zowel voor nieuwe implementaties als conversies – de SAP HANA Migration Cockpit, ook wel Landscape Transformation Migration Cockpit of LTMC genoemd. LTMC vergemakkelijkt de migratie van gegevensimport via vooraf gedefinieerde sjablonen in een op bestanden gebaseerde benadering. De cockpit is gebaseerd op een systematische benadering van gegevenscontrole die de gegevenskwaliteit garandeert door middel van systeem gebaseerde gegevens duplicaten en pre-existentie controle. Werk je in een internationale omgeving? Dan wordt het migratieproces waarschijnlijk opgesplitst in verschillende golven, met gefaseerde implementaties per land. Laten we aannemen dat alle verschillende entiteiten in jouw internationale omgeving een gemeenschappelijk rekeningschema en verschillende nationale/lokale rekeningschema's delen.
Data-update driven object
De automatische duplicaat-/pre-existentie controle die door de migratie cockpit wordt uitgevoerd, kan het laden van de GB-rekening met stamgegevens op bedrijfscode niveau voorkomen als de set GB-rekeningen als reeds bestaand wordt geïdentificeerd. Om dit te omzeilen, kan de Migration Object Modeler Tool (LTMOM) van SAP worden gebruikt om standaard migratie objecten om te zetten in door gegevens updates gestuurde objecten. De tool biedt je een breed scala aan mogelijkheden. Voor dit blog focussen we ons op twee hoofdelementen:
- Een bestaand migratie object kopiëren
- Field mapping – actie voor data record overgang van ‘import’ naar ‘update’ type
Voordat je start zijn er twee belangrijke voorwaarden voor deze aanpak: 1) het migratieproject is al aangemaakt en 2) standaard migratie-objecten zijn al gedefinieerd binnen dit project.
Zo gaat het proces
- Maak een kopie van een bestaand object
De eerste stap is het maken van een kopie van een bestaand migratie object. De gekopieerde versie moet een object blijven dat specifiek bestemd is voor een op bestanden/tabellen gebaseerde migratie. Het nieuw gemaakte object is niet onderworpen aan een specifieke naamgevingsconventie en volgt in de meeste gevallen de logica van het migratieproject. Je kunt het nieuw gemaakte object zelfs in een ander migratieproject maken.
- Veldtoewijzing - wijzig de object instelling van de parameter “importeren” naar de parameter “bijwerken” in de volgende velden:
Nadat je de uitgebreide versie van het standaard object hebt gemaakt, heb je toegang tot de veldtoewijzing van de nieuw gemaakte versie en kun je nieuwe toewijzingsregels en actie records gaan toepassen. In dit scenario transformeren we ons GL Account (uitgebreide) object zodat het niet langer een enkel import doel vervult, maar ook een update doel. Als zodanig zullen we de parameterwaarde van het actief gegevensrecord van de 4 volgende elementen omwisselen van I-type (import) naar U-type (update):
- Rekeningschema << Algemene gegevens
- Beschrijvingen << Accountnamen
- Sleutelwoord << Account zoekwoorden
- Bedieningsgebied << Algemene gegevens
Bewaar en genereer het nieuwe/uitgebreide object
Resultaat
Als resultaat wordt er een nieuw object gemaakt; gericht op het bijwerken van systeemwaarden, niet op de import. Met dit nieuwe object kun je doorgaan met de op bestanden gebaseerde import zonder verdere dubbele controles. Wel een belangrijk aandachtspunt bij het overschrijven van gegevens: ook op deze manier blijft het risico bestaan dat stamgegevens, zoals GB-rekening stamgegevens op bedrijfsniveau voor andere bedrijfscodes, worden overschreven. Dit komt omdat de migratie sjabloon niet langer een pre-existentie controle uitvoert. Het kan de nieuwe waarden forceren voor alle entiteiten op algemene gegevens niveau, zoals GB-rekeninggroep. Houd hier rekening mee.
Conclusie
Migratie is een belangrijke fase van elk implementatie- of conversie project, waarbij vaak een specifieke planning nodig is. Moeten identieke objecten voor verschillende entiteiten op verschillende tijdstippen worden geladen? Overweeg dan standaard migratie objecten en systematische controle op duplicaten en pre-existentie. Zo voorkom je problemen met toekomstige belastingen.
Dit is ook waarom het des te belangrijk is om de LTMOM-tool en de mogelijkheden van object extensie voor update doeleinden goed te begrijpen. Het gebruik van LTMOM is niet beperkt tot het wijzigen van de actie voor gegevensregistratie. Het dekt ook verschillende andere behoeften, zoals het definiëren van specifieke mapping voor standaard- en aangepaste objecten. Houd er ook rekening mee dat het werken met data-update-gestuurde objecten van invloed kan zijn op de gegevens die al in het systeem zijn opgeslagen. Ben je van plan om die methode te gebruiken om extra rekeningen naar andere buitenlandse entiteiten te laden? Dan is het goed om te onthouden dat een deel van de GB-rekening gegevensset gewijzigd kan worden als het databestand niet perfect is uitgelijnd met het doelsysteem.