Masterdata site references

Four steps to Teams success

MasterdataSites können aufeinander referenzieren.
Somit wäre es z.B. denkbar, dass man von einer Product Masterdatasite per Hyperlink auf die obergeordnete Enterprise bzw. Site Masterdatasite springen kann.
Das folgende Bild verdeutlicht diese Referenzierung:

Es wird deutlich, dass alle Enterprise Masterdata sites auf alle enthaltenen Site Masterdata sites referenzieren:

Dies wird durch den Pfeil (hier rot) verdeutlicht.
Es gelten insgesamt folgenden Regeln:

  • Jedes Enterprise zeigt auf seine Sites
  • Jede Site zeigt auf ihr Enterprise
  • Sites zeigen nicht auf enthaltene Orders, Lines oder Products (unnötige Komplexität)
  • Jede Order zeigt sowohl auf Site als auch auf Enterprise und auf enthaltene Products
  • Jede Line zeigt sowohl auf Site als auch auf Enterprise und auf enthaltene Products
  • Jedes Product zeigt sowohl auf seine Order, seine Line, seine Site und sein Enterprise

Diese Regeln sind als Business Logik in der GroupsAPI implementiert

Änderungen von Stammdaten / an AreaLocations

Es kommt häufig vor, dass sich Stammdaten ändern oder neue AreaLocations hinzukommen. Diese Änderungen haben auch einen Einfluss auf die bereits existierenden Masterdatasites. Diese halten schließlich Referenzen, die auch Namen und Informationen anderer Masterdatasites beinhalten.
Aus diesem Grunde müssen Änderungen an Stammdaten oder das Löschen/Neu Anlegen von AreaLocations zwangsläufig auch an andere Masterdatasites weiter gegeben werden.
Es gibt hierbei fünf Funktionen, die in zwei verschiedenen Fällen aufgerufen werden müssen:

  • RefreshEnterpriseMasterdataSiteAsync
  • RefreshSiteMasterdataSiteAsync
  • RefreshOrderMasterdataSiteAsync
  • RefreshLineMasterdataSiteAsync
  • RefreshProductMasterdataSiteAsync

Ändern sich die Stammdaten an einem Enterprise (Name geändert, AreaLocation hinzugefügt/gelöscht) wird RefreshEnterpriseMasterdataSiteAsync aufgerufen (von der EnterprisesAPI).
Analog gilt das für alle fünf Level.

Beim Ändern eines Enterprise müssen alle „Kinder“ des Enterprises ebenfalls geändert werden, denn sie alle beinhalten den Namen des Enterprise in Ihrer SharePoint SiteDescription und auch verweise auf die bereits existierenden Enterprise Masterdata sites.
Natürlich gilt das nur, wenn es für das entsprechende Enterprise oder eines der Kinder überhaupt eine Site gibt.

Das gleiche gilt jetzt analog für alle Level darunter.
Beim Ändern einer Site, müssen alle „Kinder“ der Site „erneuert“ werden. Allerdings auch der einzige Parent „Enterprise“, denn auch er enthält Referenzen auf seine Kinder.

Für Enterprises sammelt man die Ids also folgerndermaßen:

            allIdsRelatedToThisEnterprise.Add(enterprise.EnterpriseId);
            allIdsRelatedToThisEnterprise.AddRange(enterprise.SiteIds);
            allIdsRelatedToThisEnterprise.AddRange(lineIdsOfThisEnterprise);
            allIdsRelatedToThisEnterprise.AddRange(orderIdsOfThisEnterprise);
            allIdsRelatedToThisEnterprise.AddRange(productIdsOfThisEnterprise);

            var abstractMasterdataSites = await _masterdataSiteRepository.GetByMasterdataIdsAsync(allIdsRelatedToThisEnterprise);
            int cnt = 0;
            var allAreas = await _areaRepository.GetAllAsync();
            foreach (var abstractMasterdataSite in abstractMasterdataSites)
            {
                var updatedMasterdataSite = await _masterdataSiteFactory.RecreateMasterdataSite(abstractMasterdataSite, allAreas, abstractMasterdataSites);
                await _masterdataSiteRepository.EditAsync(updatedMasterdataSite, updatedMasterdataSite.Id);
                await SendMessage(updatedMasterdataSite, fileResetNecessary);
                cnt++;
            }

Für Sites hingegen so:

        allIdsRelatedToThisSite.Add(site.EnterpriseId);
        allIdsRelatedToThisSite.Add(site.SiteId);
        allIdsRelatedToThisSite.AddRange(lineIdsOfThisSite);
        allIdsRelatedToThisSite.AddRange(orderIdsOfThisSite);
        allIdsRelatedToThisSite.AddRange(productIdsOfThisSite);

        var abstractMasterdataSites = await _masterdataSiteRepository.GetByMasterdataIdsAsync(productIdsOfThisSite);
        abstractMasterdataSites.AddRange(abstractMasterdataSitesNeededAdditonally);

        var allAreas = await _areaRepository.GetAllAsync();
        int cnt = 0;
        foreach (var abstractMasterdataSite in abstractMasterdataSites)
        {
            if (idsOfMasterdataSitesThatShouldNotBeIterated.Contains(abstractMasterdataSite.Id)) continue;

            var updatedMasterdataSite = await _masterdataSiteFactory.RecreateMasterdataSite(abstractMasterdataSite, allAreas, abstractMasterdataSites);
            cn

Die beiden Ausschnitte unterscheiden sich in einem wichtigen Punkt.
Es gibt hier die Variable „idsOfMasterdataSitesThatShouldNotBeIterated“.
Das sind Masterdatasites, die nicht gerefresht werden müssen, jedoch trotzdem zum Update benötigt werden.
Das ist folgendermaßen zu erklären:

Ändert man eine Site, so müssen alle MasterdataSites ihrer Products, Lines, Orders, die Site selbst und deren Enterprise gerefresht werden.
Die entsprechende EnterpriseSite benötigt aber für ihren Refresh auch noch alle anderen SiteMasterdataSites. Diese müssen selbst nicht gerefresht werden, denn sie sind schließlich von der Änderung des Sitenames nicht direkt betroffen.
Sie müssen aber trotzdem als Parameter an die Refreh-Funktion der Enterprise-Site mit übergeben werden.

Es entsteht folgendes Bild:

Die Pfeile der jeweiligen Farben zeigen genau welche MasterdataSites gerefresht werden müssen, falls ein bestimmtes Level sich ändert.
Beim Enterprise müssen sind alle Kinder betroffen.
Bei einer Site alle Kinder und das Enterprise
Bei einer Line/Order ebenfalls alle Kinder, jedoch auch die Parent-Site und Enterprise
Bei einem Product die Parent Line/Order/Site und Enterprise.

Das ist einfach zu verstehen.
Es gibt jedoch auch noch die Pfeile mit den „dicken“ Enden, die zeigen, welche Masterdatasites für den Refresh bestimmter Parents benötigt werden.
Der grüne Pfeil z.B. beginnt bei einem Site-Refresh. In einem solchen Fall muss die Funktion “ RecreateMasterdataSite “ auf alle Kinder der Site + das Enterprise aufgerufen werden.
Als Parameter für diese Funktion werden jedoch auch jene Masterdata sites benötigt, die die Kinder des Enterprises sind (grüner Pfeil mit dickem Ende, der ganz oben zu sehen ist)
Auf die Site auf der linken Seite muss also nicht RecreateMasterdataSite aufgerufen werden, denn sie „kennt“ das geänderte Element gar nicht.
Sie werden aber trotzdem benötigt, um RecreateMasterdataSite auf das Enterprise aufzurufen.
Daher gibt es die Liste mit idsOfMasterdataSitesThatShouldNotBeIterated.

Derselbe Fall tritt auch noch einmal auf Product-Level auf, denn der Refresh eines Products erfordert auch den Refresh der enthaltenden Order/Line. Um diese zu Refreshen sind aber auch alle Ihre Product-Masterdatasites wieder notwendig. Diese werden also als Parameter für RecreateMasterdataSite der Order/Lines benötigt, es muss aber nicht RecreateMasterdataSite auf sie direkt aufgerufen werden.

Für eine große Übersicht empfielt sich auch die Pdf „SharePoint metadata and masterdata consistency area locations masterdata sites.pdf“

©  2024 GroupHive