Tworzenie poprawek w celu uproszczenia aktualizacji rozwiązań
Jeśli dodasz encję do rozwiązania i wyeksportujesz rozwiązanie, encja oraz powiązane z nią zasoby, które zostaną wyeksportowane w tym rozwiązaniu. Do tych zasobów należą atrybuty, formularze, liczba wyświetleń, relacje i wizualizacje oraz wszystkie inne zasoby, które są spakowane razem z encją. Wyeksportowanie wszystkich obiektów może oznaczać, że obiekty we wdrożeniu docelowym mogą zostać przypadkowo zmodyfikowane lub mogą zostać przeniesione niezamierzone zależności.
Aby rozwiązać ten problem, można utworzyć i opublikować poprawki rozwiązań, które będą zawierać podrzędne składniki encji. Nie trzeba publikować całej encji i wszystkich jej zasobów. Oryginalne rozwiązanie i jedna lub kilka powiązanych poprawek mogą być zestawiane (łączone) w późniejszym czasie, tworząc zaktualizowaną wersję rozwiązania, które może zastąpić oryginalne rozwiązanie w docelowej organizacji Microsoft Dataverse.
Aktualizacje
Poprawki można stosować do rozwiązań zarządzanych lub niezarządzanych i zawierać tylko zmiany odnoszące się do encji i powiązanych zasobów. Poprawki nie zawierają żadnych niestandardowych składników systemu lub relacji, od których są zależne, ponieważ te składniki już istnieją w organizacji docelowej. W pewnym momencie cyklu projektowania można sporządzić nową wersję rozwiązania zawierającą w sobie poprawki w celu zastąpienia wersji oryginalnej, której te poprawki dotyczyły.
Poprawki są przechowywane w bazie danych Dataverse jako rekordy encji Solution. Atrybut ParentSolutionId, który nie ma wartości null oznacza, że rozwiązanie jest poprawką. Poprawki mogą być tworzone i zarządzane za pośrednictwem zestawu SDK do .NET lub lub internetowego interfejsu API; są one przydatne do tworzenia automatyzacji, na przykład skryptu instalacji produktu. Jednak aplikacja sieciowa Dataverse zapewnia różne formularze sieciowe, które umożliwiają interaktywne tworzenie i zarządzanie poprawkami.
Poprawki można tworzyć tylko na podstawie rozwiązania nadrzędnego przy użyciu funkcji CloneAsPatchRequest lub CloneAsPatch Action.
Element nadrzędny poprawki nie może sam być poprawką.
Poprawki mogą mieć tylko jedno rozwiązanie nadrzędne.
Poprawka powoduje utworzenie zależności (na poziomie rozwiązania) w rozwiązaniu nadrzędnym.
Poprawkę można zainstalować tylko wtedy, gdy jest obecne rozwiązanie nadrzędne.
Nie można zainstalować poprawki, chyba że unikatowa nazwa i główny/pomocniczy numer wersji rozwiązania nadrzędnego, w formacie zidentyfikowanym przez
ParentSolutionId, nie pasują do wersji rozwiązania nadrzędnego zainstalowanego w organizacji docelowej.Wersja poprawki musi mieć taki sam numer główny i pomocniczy, ale wyższy numer kompilacji i numer wydania niż numer wersji rozwiązania nadrzędnego. Nazwa wyświetlana musi być różna.
Jeśli rozwiązanie posiada poprawki, kolejne poprawki muszą posiadać wyższy numer wersji niż inne istniejące poprawki dla tego rozwiązania.
Poprawki obsługują te same operacje, co w przypadku rozwiązań, takich jak aktualizacja kumulacyjna, ale nie obsługują usuwania. Przy użyciu poprawki nie można usuwać składników z rozwiązania. Aby usunąć składniki z rozwiązania, należy dokonać uaktualnienia.
Poprawki wyeksportowane jako zarządzane muszą zostać zaimportowane na zarządzane rozwiązania nadrzędne. Reguła polega na tym, że ochrona przed poprawkami (zarządzanymi lub nie) musi być dopasowana do rozwiązania nadrzędnego.
Nie należy używać niezarządzanych poprawek w celach produkcyjnych.
Poprawki są obsługiwane tylko w organizacjach Dataverse w wersji 8.0 lub nowszej.
Narzędzia SolutionPackager i PackageDeployer z tej wersji obsługują poprawki rozwiązań. Aby zapoznać się z opcjami wiersza polecenia związanymi z poprawkami, zapoznaj się z sekcją pomocy online dot. tego narzędzia.
Utwórz poprawkę
Utwórz poprawkę z rozwiązania niezarządzanego w organizacji, korzystając z wiadomości CloneAsPatchRequest lub CloneAsPatch Action, lub korzystając z aplikacji sieciowej. Po utworzeniu poprawki, oryginalne rozwiązanie zostaje zablokowane i nie można go zmienić ani eksportować, dopóki istnieją zależne poprawki w organizacji, które identyfikują rozwiązanie jako rozwiązanie nadrzędne. Wersja poprawki jest podobna do wersji rozwiązania oraz jest określona w następującym formacie: major.minor.build.release. Podczas tworzenia poprawki nie można wprowadzać zmian w istniejących wersjach głównych i podrzędnych.
Importowanie i eksportowanie poprawki
Do eksportowania i importowania poprawek można użyć zestawu SDK do .NET lub internetowego interfejsu API, aplikacji internetowych lub narzędzia Package Deployer. Odpowiedni zestaw SDK dla klas żądań .NET to ImportSolutionRequest i ExportSolutionRequest. Odpowiednimi akcjami dla interfejsu API sieci Web są ImportSolution Action i ExportSolution Action.
Przykłady poprawek
Poniższa tabela zawiera szczegółowe informacje na temat przykładu wprowadzania poprawki. Należy zauważyć, że w tym przykładzie rozwiązanie i poprawki są importowane w kolejności liczbowej i są kumulatywne, co jest zgodne z ogólnym importowaniem rozwiązań.
| Nazwa poprawki | Opis |
|---|---|
| RozwiązanieA w wersji 1.0 (niezarządzane) | Zawiera encjęA z 6 polami. |
| RozwiązanieA w wersji 1.0.1.0 (niezarządzane) | Zawiera obiekt encjaA z 6 polami (3 zaktualizowane) i dodaje encjęB z 10 polami. |
| RozwiązanieA w wersji 1.0.2.0 (niezarządzane) | Zawiera encjęC z 10 polami. |
Proces importowania przebiega następująco.
Deweloper lub konfigurator najpierw importuje rozwiązanie podstawowe (RozwiązanieA 1.0) do organizacji. Wynik to encjaA z 6 polami w organizacji.
Następnie zaimportowana jest poprawka 1.0.1.0 do RozwiązaniaA. Organizacja zawiera teraz obiekt encjaA z 6 polami (3 zaktualizowane), plus encjęB zawierającą 10 pól.
I wreszcie zaimportowana jest poprawka 1.0.2.0 do RozwiązaniaA. Organizacja zawiera teraz obiekt encjaA z 6 polami (3 zaktualizowane), plus encjęB zawierającą 10 pól oraz encjęC z 10 polami.
Oto kolejny przykład
Przyjrzyjmy się kolejnemu przykładowi poprawek, które przedstawiono w poniższej tabeli.
| Nazwa poprawki | Opis |
|---|---|
| RozwiązanieA, wersja 1.0 (niezarządzane, rozwiązanie podstawowe) | Zawiera encję Account, w której długość pola numer konta jest korygowana z 20 na 30 znaków. |
| RozwiązanieB, wersja 2.0 (niezarządzane, inny dostawca) | Zawiera encję Account, w której długość pola numer konta jest korygowana na 50 znaków. |
| RozwiązanieA w wersji 1.0.1.0 (niezarządzane, poprawka) | Zawiera aktualizację encji Account, w której długość pola numer konta jest korygowana do 35 znaków. |
Proces importowania przebiega następująco:
Deweloper lub konfigurator najpierw importuje rozwiązanie podstawowe (RozwiązanieA 1.0) do organizacji. Powstaje wtedy encja
Account, której pole numeru konta wynosi 30 znaków.RozwiązanieB zostało zaimportowane. W organizacji znajduje się teraz encja
Account, której pole numeru konta wynosi 50 znaków.Poprawka do RozwiązaniaA 1.0.1.0 jest zaimportowana. W organizacji nadal znajduje się encja
Account, której pole numeru konta wynosi 50 znaków, tak jak przewiduje to RozwiązanieB.RozwiązanieB jest zdeinstalowane. W organizacji teraz znajduje się encja
Account, której pole numeru konta wynosi 35 znaków, tak jak przewiduje to poprawka RozwiązaniaA 1.0.1.0.
Usuwanie poprawki
Poprawkę lub rozwiązanie podstawowe (nadrzędne) można usunąć przy użyciu DeleteRequest lub, w przypadku sieciowego interfejsu API, należy użyć metody HTTP DELETE. Proces usuwania jest inny w przypadku rozwiązania zarządzanego i niezarządzanego, w którym istnieje jedna lub kilka poprawek w organizacji.
W przypadku rozwiązania niezarządzanego przed odinstalowaniem rozwiązania podstawowego należy odinstalować najpierw wszystkie poprawki do rozwiązania podstawowego w odwrotnej kolejności ich pierwotnego wdrażania.
W przypadku rozwiązania zarządzanego należy po prostu odinstalować rozwiązanie podstawowe. System Dataverse automatycznie odinstalowuje poprawki w odwrotnej kolejności ich instalowania przed deinstalacją rozwiązania podstawowego. Użytkownik może również odinstalować pojedynczą poprawkę.
Aktualizuj rozwiązanie
Zaktualizowanie rozwiązania polega na dodaniu (scaleniu) wszystkich poprawek tego rozwiązania w nowej wersji rozwiązania. Następnie to rozwiązanie zostanie odblokowane i będzie można ponownie je modyfikować (tylko dla rozwiązania niezarządzanego) lub wyeksportować. W przypadku rozwiązania zarządzanego dalsze modyfikacje rozwiązania nie są dozwolone z wyjątkiem utworzenia poprawek z nowo zaktualizowanych rozwiązań. W celu połączenia poprawek w ramach rozwiązania niezarządzanego, należy użyć funkcji CloneAsSolutionRequest lub CloneAsSolution Action. Klonowanie rozwiązania powoduje utworzenie nowej wersji rozwiązania niezarządzanego, wraz ze wszystkimi jego poprawkami, z wyższym numerem wersji w formacie główny.podrzędny, takim samym unikatowym identyfikatorem i wyświetlaną nazwą.
W przypadku rozwiązania zarządzanego wygląda to nieco inaczej. Użytkownik najpierw klonuje rozwiązanie niezarządzane (A), dołączając wszystkie jego poprawki, a następnie eksportuje je jako rozwiązanie zarządzane (B). W organizacji docelowej zawierającej zarządzaną wersję rozwiązania (A) i jego poprawki, należy zaimportować rozwiązanie zarządzane (B), a następnie uruchomić DeleteAndPromoteRequest lub akcję DeleteAndPromote, aby zastąpić rozwiązanie zarządzane (A) oraz jego poprawki za pomocą zaktualizowanego rozwiązania zarządzanego (B) o wyższym numerze wersji.