Hé, wat moeten we vanavond doen? Hetzelfde als wat we elke avond doen ... probeer alle gegevens ter wereld te migreren!

Ooit maakten we een migratieproces voor een database zonder velden om wijzigingen te verifiëren of te beheren. We moesten dus een andere optie overwegen en iemand noemde het gebruik van HashBytes. A-ha!

HashBytes is een functie waarmee u een coderingscode kunt genereren voor alle informatie die wordt overgedragen in de parameter string, en waar u kunt beslissen welk algoritme u in het proces wilt gebruiken.

Hoe is de syntaxis van deze functie?

Deze functie ontvangt twee parameters:

  • De eerste parameter is de naam van het te coderen algoritme. Er zijn 7 algoritmen voor hen (MD2, MD4, MDS, SHA, SHA1, SHA2_256, SHA2_512)
  • De tweede parameter is de tekenreeks die we willen coderen. We kunnen meerdere waarden samenvoegen. Het enige dat nodig is, is dat de verzonden parameter een tekenreeks is.

Wanneer ik deze parameters verzend, retourneert de functie een varbinary (maximaal 8000 bytes).

Voorbeeld:

OK, dus we weten wat deze functie kan doen, maar hoe kunnen we deze gebruiken in ons migratieproces? De oplossing was om de hoofdproblemen in vier items te scheiden en elk afzonderlijk aan te vallen.

  1. Hoe kunnen we identificeren wanneer een record is gemaakt of gewijzigd?
  2. In het migratie- / integratieproces moeten we alle velden van de gegevensbron valideren, omdat het niet altijd nodig is om alle informatie naar het doelsysteem te verplaatsen.
  3. Hoe kunnen we de string bouwen om de hash met Hashbytes te genereren en er een automatisch proces van te maken?
  4. Hoe kunnen we de gecodeerde informatie gebruiken in ons proces?

Om de eerste vraag op te lossen, hebben we twee nieuwe velden gemaakt om de wijzigingen in onze kruistabel te valideren en te beheren. We deden dit zodat we controle konden hebben als we een nieuw record moesten maken of het bestaande record in het doelsysteem moesten bijwerken.

De nieuwe velden zijn PO_HashBytes_ORI, waar u de gecodeerde code opslaat wanneer het migratieproces wordt uitgevoerd of wanneer het record nieuw / gewijzigd is. Super goed! We kunnen nu onze gegevens identificeren, maar dit is slechts een klein deel van ons grotere probleem.

Voor het tweede item was de oplossing om alle velden te valideren die we moeten verplaatsen in het migratie- / integratieproces dat in de records was gewijzigd. Nadat dit was gebeurd, konden we een nieuwe tabel maken met de naam van de velden van elke entiteit die we nodig hadden om van het bronsysteem naar het doelsysteem te gaan.

C: \ Users \ JOSE ~ 1.ROD \ AppData \ Local \ Temp \ SNAGHTMLadb07e2.PNG

Vervolgens vullen we deze tabel met alle velden die we in het proces moeten gebruiken. Om dit te doen, maken we een SQL Dynamic om alle invoegzinnen te maken die nodig zijn om alle benodigde rijen in te voegen.

C: \ Users \ JOSE ~ 1.ROD \ AppData \ Local \ Temp \ SNAGHTMLae72524.PNG

We hebben nu de benodigde validatie- / controlevelden in ons proces. Vervolgens moeten we tekenreeksen bouwen om de HashBytes-functie uit te voeren.

We moeten deze string met uitstekende prestaties bouwen, dus dit kan automatisch gebeuren omdat de volgende keer dat iemand het proces moet wijzigen, deze deze kan gebruiken in plaats van het moeilijkere proces van het handmatig bouwen van deze strings. Om het bovenstaande proces soepel te laten verlopen, hebben we een functie in onze database gemaakt. Hieronder ziet u een voorbeeld van de functie die we hebben gemaakt (PO_get_hash_fields):

Deze functie heeft een parameter (@p_table_name) waar deze de naam van de tabel ontvangt die nodig is om de string op te bouwen die we in de andere functie (HashBytes) gebruiken. Met de naam van de tabel (@p_table_name) krijgen we alle benodigde velden om de string op te bouwen (PO_structure_to_update) en de conversie te maken wanneer het veldtype verschilt van char, varchar, nvarchar.

Het resultaat van deze functie is de nieuwe string met alle velden aaneengeschakeld en klaar om de conversie in gecodeerde code uit te voeren.

We komen in de buurt. Nu moeten we alle processen gebruiken om nieuwe of bijgewerkte records te identificeren. Maar hoe kunnen we alle voorgaande stappen gebruiken om ons proces te voltooien om te bepalen of een record nieuw of bijgewerkt is? De oplossing was om een ​​opgeslagen procedure te maken die de functies gebruikt om de hash te genereren en het veld bij te werken om te controleren of het record nieuw of bijgewerkt is.

Deze opgeslagen procedure heeft 4 invoerparameters die nodig zijn om alle dynamische SQL uit te voeren die bepalen of het record nieuw of gewijzigd is.

Deze parameters zijn:

  1. @p_table_name_ori: deze parameter wordt gebruikt om de naam van de tabel te plaatsen die we nodig hebben om alle velden te krijgen om de hash te genereren.
  2. @p_table_name_PO_Des: deze parameter wordt gebruikt om de naam te vinden van de tabel waarnaar wordt verwezen waar we de informatie hebben over alle opgeslagen records, verplaatst van het bronsysteem naar het doelsysteem. Nu moeten we de hash voor elk record genereren en bijwerken in de kruistabel.
  3. @p_table_type: deze parameter geeft aan welke tabel we moeten verwerken (bijvoorbeeld Account, Contact en / of andere entiteiten).
  4. @p_process_type: deze parameter wordt gebruikt om het validatieproces te identificeren of het record nieuw of bijgewerkt is. Als het proces wordt bijgewerkt, moeten we de informatie in het veld PO_HashBytes_DES van de gegenereerde hash plaatsen. Wanneer het record nieuw is, moeten we de informatie in het veld PO_HashBytes_ORI van de gegenereerde hash plaatsen.

De opgeslagen procedure genereert een dynamische SQL om een ​​tabel bij te werken met de gecodeerde code die is gegenereerd met behulp van de HashBytes en alle vereiste velden in het migratie- / integratieproces voor elke record.

Uitstekend! We hebben ons nieuwe geverifieerde / controleveld voor ons migratie / integratieproces. Nu kunnen we de HashByte-functie in de migratie / integratiepakketten gebruiken door de hash voor elk record te genereren met behulp van de nieuwe opgeslagen procedure. We kunnen ook vaststellen of een record nieuw of gewijzigd is door het oorspronkelijke veld te vergelijken met het nieuwe veld met behulp van de gecodeerde code via de HashBytes. Nu kunnen we databases migreren die geen besturingsvelden hebben. Wauw!

Veel succes met migreren!

Avatar voor Joe D365

Joe D365

Joe D365 is een Microsoft Dynamics 365 superheld die op pure Dynamics adrenaline draait. Als het gezicht van PowerObjects, is de missie van Joe D365 om innovatieve manieren te onthullen om Dynamics 365 te gebruiken en de toepassing naar meer bedrijven en organisaties over de hele wereld te brengen.