Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dotyczy: Azure Logic Apps (Standard)
Chociaż poprzedni etap Discovery dostarcza konkretnych informacji na temat projektu integracji, artefaktów, składników i zależności, nadal stoisz przed kluczowym wyzwaniem: przeobrażenie spisu w wykonywalny plan migracji. Przed rozpoczęciem procesu konwersji potrzebne są informacje o sposobie mapowania składników i artefaktów na odpowiedniki w Azure Logic Apps (Standard), które części wymagają przeprojektowania, oraz o zakresie nakładu pracy koniecznego do wykonania tych działań.
Na etapie planowania agent migracji Azure Logic Apps w Visual Studio Code używa katalogowanych artefaktów i generuje szczegółowy plan migracji dla każdej grupy przepływów logicznych. Plan migracji obejmuje architekturę docelową, definicje workflow, wymagane komponenty Azure, mapowania akcji, dyspozycje artefaktów, luki migracyjne oraz wzorce integracji. Dzięki tej wiedzy możesz przejść do etapu konwersji z większą przewidywalnością i jasnym planem niskiego ryzyka.
W tym artykule wyjaśniono, jak agent migracji Azure Logic Apps tworzy plan migracji na etapie planowania. Następnie możesz użyć tego planu migracji, aby zamapować artefakty źródłowe na Azure Logic Apps (Standard), zidentyfikować luki w przeprojektowaniu i oszacować nakład pracy przed rozpoczęciem procesu konwersji.
Akcje etapu planowania
Po zakończeniu działania Analyze Source Design w Azure Logic Apps, działanie Plan Logic App Design staje się dostępne. Po wybraniu tego działania @migration-planner GitHub agent funkcji Copilot generuje następujące informacje dla każdej grupy przepływów:
| Nazwa sekcji | Opis |
|---|---|
| Architektura | Widok projektanta, widok kodu i diagram architektury dla proponowanego rozwiązania. |
| Dodatkowe komponenty Azure | Jawne i niejawne konwersje składników Azure wymagane dla proponowanego projektu. |
| Mapowanie operacji | Odwzorowania jeden do jednego komponentów platformy źródłowej i ich odpowiedników w Azure Logic Apps (Standard). Przykład: — Port odbioru plików BizTalk jest mapowany na wyzwalacz systemu plików w przepływie pracy Standard. — Port wysyłania HTTP w usłudze BizTalk mapuje się na akcję HTTP w standardowym przepływie pracy. Aby uzyskać więcej informacji, zobacz Mapowanie operacji. |
| Dyspozycje artefaktów | Artefakty wymagające konwersji i ich docelowe miejsca przesyłania. |
| Luki w migracji | Funkcje lub składniki, które nie mają bezpośrednich odpowiedników w standardowych przepływach pracy oraz zalecane alternatywne rozwiązania. Na przykład niestandardowy składnik potoku BizTalk może wymagać .NET lokalnej funkcji w standardowym przepływie pracy. Aby uzyskać więcej informacji, zobacz Luki w migracji. |
| Wzorce integracji | Wykryte wzorce w przepływie integracji. |
| Podsumowanie | Ogólne omówienie proponowanego przepływu pracy. |
Poniższy przykład przedstawia przykładowy wygenerowany plan migracji:
Poniższe sekcje zawierają więcej informacji na temat określonych obszarów planu migracji:
Mapowanie operacji
W sekcji Mapowanie operacji opisano, jak poszczególne składniki źródłowe mapowane są na odpowiedniki w standardowym przepływie pracy, na przykład:
| Składnik źródłowy | Odpowiednik standardowego przepływu pracy | Typ operacji | Typ mapowania | Notatki |
|---|---|---|---|---|
| Port odbiorczy (FILE) | Wyzwalacz systemu plików o nazwie Po dodaniu lub zmodyfikowaniu pliku | Built-in | Środowisko uruchomieniowe natywne | Wybierz wersję built-in która działa w tym samym procesie co środowisko uruchomieniowe Azure Logic Apps. Wersja shared jest uruchamiana w wielodostępnym środowisku Azure. Aby uzyskać więcej informacji, zobacz: - Połączenie do lokalnych systemów plików z Azure Logic Apps - Wbudowany łącznik systemu plików - referencja |
| Wyślij port (HTTP) | Operacja HTTP | Built-in | Środowisko uruchomieniowe natywne | Aby uzyskać więcej informacji, zobacz Wywoływanie zewnętrznych punktów końcowych HTTP lub HTTPS w Azure Logic Apps. |
| Kształt orkiestracji (Przekształcenie) | Akcja operacji XML o nazwie Transform XML | Built-in | Środowisko uruchomieniowe natywne | Aby uzyskać więcej informacji, zobacz Transform XML w Azure Logic Apps. |
| Niestandardowy składnik pipeline'u | Funkcja Azure Functions -lub- Funkcja lokalna .NET |
Built-in | Na zamówienie | Wymaga migracji kodu. Aby uzyskać więcej informacji, zobacz: - Wywołaj funkcje Azure z poziomu Azure Logic Apps - Tworzenie kodu i uruchamianie .NET z Standardowych przepływów pracy w Azure Logic Apps |
Luki w migracji
Dla każdej zidentyfikowanych luk plan zawiera następujące informacje:
| Przedmiot | Opis |
|---|---|
| Opis luki | Co robi składnik źródłowy i dlaczego nie istnieje bezpośredni odpowiednik. |
| Zalecane rozwiązanie | Sugerowane obejście, takie jak użycie funkcji lokalnej .NET, funkcji Azure Functions lub łącznika niestandardowego. |
| Wpływ na nakład pracy | Jak różnica wpływa na szacowanie wysiłku migracyjnego. |
Przeglądanie i dostosowywanie planów
Po wygenerowaniu planu migracji przez agenta migracji dokładnie przejrzyj plan, aby zrozumieć plan i zalecenia. Przed przejściem do etapu konwersji wprowadź wszelkie aktualizacje niezbędne dla danego scenariusza. Dokładność planu znacznie wpływa na jakość wyniku konwersji.
Aby lepiej zrozumieć plan i określić, czy chcesz wprowadzać aktualizacje, należy wchodzić w interakcje z @migration-planner GitHub agent funkcji Copilot przy użyciu czatu Copilot w Visual Studio Code w celu wykonania następujących zadań:
- Zadaj pytania dotyczące określonych mapowań.
- Zażądaj alternatywnych metod rozwiązywania luk.
- Zażądaj modyfikacji planu przed przejściem do konwersji.
Po zatwierdzeniu i finalizacji planu, etap konwersji wykorzystuje te wyniki planowania do stworzenia uporządkowanego planu zadań konwersji z zależnościami i opcjonalnymi szacunkami wysiłku.
Treści powiązane
- Automatyzacja migracji z platform integracyjnych do Azure Logic Apps
- Quickstart: migrowanie projektu integracji przy użyciu agenta migracji Azure Logic Apps