Metody migracji dla usługi BizTalk Server do usługi Azure Logic Apps
Ten przewodnik obejmuje strategie migracji i zasoby wraz z zagadnieniami dotyczącymi planowania i najlepszymi rozwiązaniami, które ułatwiają dostarczanie udanych rozwiązań migracji.
Uwaga
Aby zapoznać się z omówieniem migracji i przewodnikiem po wybieraniu usług na platformie Azure na potrzeby migracji, zapoznaj się z następującą dokumentacją:
Opcje strategii
W poniższych sekcjach opisano różne strategie migracji wraz z ich korzyściami i wadami:
Wielki Wybuch
"Duży wybuch" lub "bezpośrednia zmiana" to podejście, które wymaga dużej ilości planowania i nie jest zalecane dla organizacji, które nie są nieznane w usłudze Azure Logic Apps lub które mają duże systemy lub rozwiązania do migracji. Gdy organizacja implementuje nowy stos technologii, nowe uczenie zwykle jest często wynikiem. Inwestując zbyt wcześnie lub za dużo, nie będziesz mieć możliwości skorzystania z wyciągniętych lekcji i dostosowania bez ryzyka znacznej przeróbki.
Takie podejście może również potrwać dłużej, aby czerpać lub naliczać wartość. Jeśli niektóre działania migracji zostały już ukończone, ale nie zostały jeszcze opublikowane w środowisku produkcyjnym z powodu innych oczekujących lub w toku pracy, zmigrowane artefakty nie generują wartości dla organizacji.
Zalecamy rozważenie tej metody tylko wtedy, gdy masz obciążenia BizTalk o małej, niskiej złożoności, ekspertów z dziedziny (MŚP), którzy znają środowisko BizTalk, oraz bezpośrednie mapowania między funkcjami BizTalk, których obecnie używasz i usługą Azure Logic Apps. Doświadczenie w usłudze Azure Logic Apps znacznie zmniejsza ryzyko przy użyciu tego podejścia.
Iteracyjne lub oparte na falach (zalecane)
Takie podejście umożliwia organizacji przyrostowe osiągnięcie wartości, ale wcześniej niż w przeciwnym razie. Zespół projektu może dowiedzieć się o stosie technologii na wczesnym etapie, korzystając z retrospektyw. Możesz na przykład wdrożyć istniejący interfejs BizTalk lub projekt w środowisku produkcyjnym, a następnie dowiedzieć się więcej o potrzebach rozwiązania, które obejmują zarządzanie, skalowalność, operacje i monitorowanie. Po uzyskaniu tej wiedzy możesz zaplanować przebiegi, aby zoptymalizować istniejące możliwości lub wprowadzić nowe wzorce, które można później użyć w przyszłości.
Niezależnie od podejścia, jeśli planujesz przejście do usługi Azure Logic Apps lub Platformy Azure, zdecydowanie rozważ refaktoryzowanie rozwiązań bizTalk Server do rozwiązań bezserwerowych lub natywnych dla chmury przed zlikwidowaniem infrastruktury serwera. Ten wybór jest doskonałą strategią, jeśli organizacja chce całkowicie przekształcić firmę w chmurę.
Usługi BizTalk Server i Azure Logic Apps mają różne architektury. Aby jeszcze bardziej zmodernizować swoje rozwiązania, możesz użyć usług Azure Integration Services, aby rozszerzyć możliwości usługi Azure Logic Apps, które zaspokajają podstawowe potrzeby związane z integracją klientów.
W przypadku wyższego zwrotu z inwestycji (ROI) zalecamy, aby każda migracja BizTalk korzystała z podstawowych natywnych funkcji w usłudze Azure Logic Apps (Standard), jak to tylko możliwe i rozszerzone z innymi usługami Azure Integration Services zgodnie z potrzebami. Ta kombinacja umożliwia wykonanie dodatkowych scenariuszy, na przykład:
- Natywne funkcje hybrydowe w chmurze z usługą Azure Logic Apps (Standardowa) z wdrożeniem hybrydowym
- Funkcje stanowego lub bezstanowego przepływu pracy w usłudze Azure Logic Apps (Standardowa)
- Natywna, wbudowana (w aplikacji) integracja komputera mainframe i średniej ramki z łącznikami w usłudze Azure Logic Apps (Standardowa)
- Obsługa komunikatów pub-sub przy użyciu usługi Azure Service Bus
- Zaawansowane możliwości protokołu SOAP w usłudze Azure API Management
Dostarczanie projektu migracji BizTalk
Aby ukończyć taki projekt, zalecamy stosowanie iteracyjnego lub opartego na falach podejścia i korzystanie z procesu Scrum. Chociaż Scrum nie obejmuje koncepcji Sprint Zero (Sprint 0) na potrzeby działań przed sprintem, zalecamy skupienie się na pierwszym przebiegu na wyrównaniu zespołu i odkryciu technicznym. Po przebiegu 0 postępuj zgodnie z wykonywaniem wielu przebiegów migracji i skoncentruj się na wydawaniu funkcji w kierunku minimalnej opłacalności produktu (MVP).
Przebieg 0
Podczas tego przebiegu zalecamy wykonanie odnajdywania środowisk programu BizTalk Server z planowaniem fal. Zrozumienie zakresu i głębokości projektu ma kluczowe znaczenie dla sukcesu. Poniższa lista zawiera określone obszary do rozwiązania podczas przebiegu 0:
| Obszar | opis |
|---|---|
| Odnajdowanie | Przechwyć dane dotyczące wszystkich interfejsów i aplikacji, aby poznać liczbę interfejsów i aplikacji, które należy migrować. Należy również przypisać złożoność do każdego interfejsu lub procesu. Podczas tego procesu katalogowania zbierz następujące informacje, aby określić priorytety pracy: - Adaptery używane — Używane funkcje programu BizTalk Server, takie jak monitorowanie aktywności biznesowej, aparat reguł biznesowych, EDI itd. — Kod niestandardowy, taki jak wyrażenia, mapy i składniki potoku — Przepływność komunikatów - Rozmiary komunikatów -Zależności — Zależności aplikacji i systemu |
| Projekt architektury | Utwórz architekturę wysokiego poziomu do użycia jako centralny punkt migracji. Ten projekt obejmuje elementy, które odpowiadają ogólnym potrzebom funkcjonalnym i niefunkcjonalnym. |
| Minimalna definicja produktu opłacalnego (MVP) | Zdefiniuj pierwsze cechy fali. Innymi słowy, procesy, które wymagają obsługi po zakończeniu pierwszej fali. |
| Początkowa lista prac migracji | Zdefiniuj pierwsze funkcje fali i ich elementy robocze przy użyciu opracowania technicznego. |
Narzędzia odnajdywania
Aby ułatwić odnajdywanie migracji, możesz użyć narzędzia wiersza polecenia Azure Integration Migrator, nazywanego również narzędziem BizTalk Migration, które jest projektem open source firmy Microsoft. To narzędzie korzysta z podejścia etapowego, aby ułatwić odkrywanie przydatnych szczegółowych informacji i strategii migracji rozwiązań do chmury. Zalecamy używanie narzędzia migracji tylko do odnajdywania i generowania raportów. Warto również rozważyć użycie innych produktów do odnajdywania od partnerów, którzy udostępniają rozwiązania w tej przestrzeni.
Aby wygenerować spis za pomocą elementów programu BizTalk Server, możesz użyć narzędzia BizTalk Documenter, który został opracowany przez mark Brimble. To narzędzie współpracuje z programem BizTalk Server 2020, mimo że jest obsługiwane tylko program BizTalk Server 2016.
Projekt architektury
Chociaż usługa Azure Logic Apps zapewnia możliwości, które umożliwiają ponowne użycie zasobów programu BizTalk Server, musisz mieć nowoczesny projekt architektury, aby korzystać z zalet bardziej nowoczesnych funkcji. Z perspektywy funkcjonalnej należy jak najwięcej używać logiki biznesowej. Z perspektywy modernizacji produktu użyj usług Azure Integration Services tak samo, jak to możliwe. W przypadku zagadnień dotyczących jakości i krzyżowych zalecamy korzystanie z platformy Azure Well-Architected Framework.
W ramach tej struktury migracje usługi BizTalk to obciążenia o znaczeniu krytycznym. Ten termin opisuje kolekcje zasobów aplikacji, które wymagają wysokiej dostępności na platformie, co oznacza, że muszą być zawsze dostępne, operacyjne i odporne na awarie.
Aby ukończyć projekt architektury migracji usługi BizTalk, postępuj zgodnie z metodologią projektowania obciążeń o znaczeniu krytycznym na platformie Azure. Aby uzyskać wstępną architekturę i topologię, zapoznaj się z architekturą referencyjną opisaną w temacie Podstawowa integracja przedsiębiorstwa na platformie Azure w Centrum architektury platformy Azure.
Aby skonfigurować początkowe środowisko, użyj akceleratora strefy docelowej usług Azure Integration Services, który jest przeznaczony do tworzenia i wdrażania platformy integracji przy użyciu typowego projektu strefy docelowej przedsiębiorstwa.
Minimalna definicja projektu opłacalnego (MVP)
MVP to wersja produktu, która ma wystarczającą liczbę funkcji do użycia przez klienta. Ta wersja pokazuje możliwości i potencjał produktu w celu zebrania opinii klientów i kontynuowania pracy. W przypadku migracji bizTalk definicja MVP odzwierciedla iterację, fale lub grupy przebiegów, które należy poczynić w kierunku działania funkcji i spełniać początkowe obciążenia integracji.
Zalecamy, aby definicja MVP zawierała następujące wyniki biznesowe, które są wyrażone jako Epiki w terminologii scrum:
Wyniki biznesowe (epiki)
- Jaki jest podstawowy cel, który chcesz osiągnąć?
- Jakie możliwości lub funkcje należy rozwiązać dla tego MVP?
- Jakie są przepływy procesów biznesowych? To pytanie zapewnia możliwość optymalizacji istniejących procesów obsługiwanych przez program BizTalk Server.
- Jakie są decyzje biznesowe, na przykład wyniki biznesowe wpływające na MVP lub jakie są dostępność zasobów?
Zalecamy, aby twój MVP zawierał następujące procesy w zakresie, które są wyrażone jako funkcje w terminologii Scrum:
Procesy w zakresie (funkcje)
| Funkcja | opis |
|---|---|
| Funkcje systemu wysokiego poziomu | Te informacje można wyodrębnić przy użyciu narzędzi odnajdywania i wyrazić opisy pod względem funkcji. |
| Aktorzy lub osoby | Użyj tych informacji, aby określić osoby, których dotyczy obsługiwane scenariusze MVP. |
| Aranżacje | Te informacje można wyodrębnić przy użyciu narzędzi do odnajdywania. |
| Jednostki danych i komunikaty | Te elementy umożliwiają poznanie, czy można uwzględnić dalsze ulepszenia w danych wymienianych przez środowisko programu BizTalk Server. |
| Mapowania danych | Dzisiejszy świat opiera się na formacie JSON. Jednak program BizTalk Server używa kodu XML. Jest to świetna okazja, aby zdecydować, czy format danych i potrzeby konwersji są potrzebne dla nowej platformy. |
| Reguły biznesowe | Te reguły skoncentrowane na danych otwierają możliwość ponownego przemyślenia ich podejścia lub ponownego użycia przez zastosowanie funkcji usługi Azure Logic Apps. |
| Zagadnienia dotyczące prywatności danych | Musisz ustawić najwyższy priorytet prywatności. Jeśli klient nie wybierze hybrydowego modelu wdrażania w usłudze Azure Logic Apps (Standardowa), musisz rozwiązać ten obszar w każdej fali ze względu na potencjalne zmiany środowiska wdrażania. |
| Zagadnienia prawne | Ten aspekt jest bardziej istotny, jeśli klienci nie mają obciążeń opartych na chmurze. |
| Domyślne zabezpieczenia | Należy zaprojektować każdą funkcję z uwzględnieniem zabezpieczeń. |
| Proponowane funkcje współistnienia | Gdy dostarczasz każdą falę, masz pewien stopień współistnienia. Należy dostosować tę architekturę hybrydową do istniejących wskaźników poziomu usług (SLI) i celów poziomu usług (SLO). |
| Zagadnienia niefunkcjonalne | Procesy biznesowe mogą mieć różne wymagania niefunkcjonalne. Nie wszystko musi się zdarzyć w czasie rzeczywistym. Z drugiej strony, nie wszystko jest procesem wsadowym. |
| Metryki biznesowe | Opcjonalna możliwość pokazania postępu prac związanych z migracją. |
Warto również zidentyfikować i wyświetlić listę różnych zmiennych poza zakresem, które kształtuje zakres pracy MVP, na przykład:
- Dostępność zasobów
- Ryzyka
- Dokumentacja
- Czas wprowadzenia na rynek
Początkowa zaległości
Początkowa zaległość to zestaw scenariuszy użytkownika, który należy pogrupować w pozycję Funkcje w celu utworzenia procesów w zakresie dla MVP. Innymi słowy, MVP jest reprezentowany przez elementy Scrum znane jako Epiki, Funkcje i Historie użytkowników. W idealnym przypadku każda aplikacja Epic obejmuje grupę aplikacji BizTalk lub projektów BizTalk. Możesz użyć prostej reguły, która kojarzy jedną aplikację BizTalk lub projekt BizTalk z funkcją.
Załóżmy na przykład, że masz projekt BizTalk Server z orkiestracją o nazwie "LoanRequests", którego klienci używają do żądania pożyczek bankowych. W związku z tym masz następującą proponowaną funkcję i historię użytkownika:
Funkcja: przetwarzanie pożyczek
Historia użytkownika: "Jako klient chcę przesłać wniosek o pożyczkę, aby bank mógł dodać fundusze na moje bezpieczne konto".
Ten scenariusz użytkownika, który może obecnie istnieć jako implementacja w programie BizTalk Server, ma następujące zadania do zaimplementowania przy użyciu usług Azure Logic Apps i Azure Integration Services:
- Zbierz artefakty wielokrotnego użytku usługi BizTalk.
- Tworzenie przepływu pracy żądania pożyczki przy użyciu usługi Azure Logic Apps.
- Konfigurowanie asynchronicznych komunikatów przy użyciu usługi Azure Service Bus lub IBM MQ.
- Mapuj dane JSON na dane XML przy użyciu przepływu pracy usługi Azure Logic Apps.
- Dostosuj usługi Azure Integration Services zgodnie z wymaganiami dotyczącymi wzorców obsługi komunikatów.
Na poniższym diagramie przedstawiono sugerowane czasy trwania epików, funkcji, scenariuszy użytkownika i zadań, które są podzielone na scenariusze użytkownika. Mimo że decyzje dotyczące implementacji mają wpływ na te czasy trwania, zakładają, że używasz istniejących artefaktów BizTalk w usłudze Azure Logic Apps. Utwórz standardowe przepływy pracy przy użyciu wstępnie utworzonych szablonów przepływów pracy, jak najwięcej.
Fale migracji (przebiegi)
Po zakończeniu przebiegu 0 przez zespół należy mieć jasny widok MVP do skompilowania. Fala jest zestawem przebiegów. Początkowa zaległości powinna zawierać elementy robocze, które są zgodne z następnym diagramem, jak najwięcej:
Podczas fali zespół wykonuje działania związane z migracją, testowaniem i wydawaniem do środowiska produkcyjnego. Przyjrzyjmy się bliżej tym, co dzieje się w każdej fali.
Migrate
Podczas każdej fali migracja koncentruje się na uzgodnionych scenariuszach użytkowników. W pierwszej fali twój zespół koncentruje się na początkowej liście prac. Decyzje technologiczne muszą używać informacji w mapowaniu funkcji programu BizTalk Server opisanych przez matchup funkcji — dlaczego warto przeprowadzić migrację z programu BizTalk Server do usługi Azure Logic Apps?
Na poniższym diagramie przedstawiono zdarzenia, które powinny wystąpić podczas fal migracji:
| Krok | opis |
|---|---|
| 1 | Odnajdź istniejące aplikacje i interfejsy BizTalk. Mimo że zostało wprowadzone w przebiegu 0, to działanie powinno nastąpić po rozpoczęciu każdej fali. Klienci mogą nadal wprowadzać zmiany w środowisku BizTalk. Zasoby: - BizTalk Migration Tool - BizTalk Documenter, narzędzie |
| 2 | Skonfiguruj początkowe środowisko migracji. Możesz użyć akceleratora strefy docelowej usług Azure Integration Services, który jest strukturą wdrażania chmury do tworzenia i wdrażania platformy integracji, która ma typowy projekt strefy docelowej przedsiębiorstwa. Jako właściciel obciążenia możesz pewnie osiągnąć docelowy stan techniczny, korzystając z podanych wskazówek dotyczących architektury i zasobów migracji BizTalk. Aby zapoznać się z przykładową architekturą, zobacz Przykładowe środowisko migracji. |
| 3 | Tworzenie i testowanie standardowych przepływów pracy aplikacji logiki uruchamianych w usłudze Azure Logic Apps z jedną dzierżawą przy użyciu witryny Azure Portal lub programu Visual Studio Code z rozszerzeniem azure Logic Apps (Standard). Za pomocą programu Visual Studio Code można lokalnie opracowywać, testować i przechowywać projekt aplikacji logiki przy użyciu dowolnego systemu kontroli źródła. Aby uzyskać więcej informacji, zobacz następującą dokumentację: - Tworzenie przykładowego przepływu pracy aplikacji logiki w warstwie Standardowa przy użyciu witryny Azure Portal - Tworzenie przykładowego przepływu pracy aplikacji logiki w warstwie Standardowa przy użyciu programu Visual Studio Code Aby zapoznać się z diagramem przedstawiającym przykładową aplikację logiki i połączenia, zobacz Przykładowe środowisko migracji. |
| 100 | Aby uzyskać pełne korzyści z łatwego i spójnego wdrażania przepływów pracy aplikacji logiki w warstwie Standardowa w różnych środowiskach i platformach, należy również zautomatyzować proces kompilowania i wdrażania. Rozszerzenie Azure Logic Apps (Standard) dla programu Visual Studio Code udostępnia narzędzia umożliwiające tworzenie i konserwowanie zautomatyzowanych procesów kompilacji i wdrażania przy użyciu usługi Azure DevOps. Aby uzyskać więcej informacji, zobacz Automatyzowanie kompilacji i wdrażania dla standardowych przepływów pracy aplikacji logiki za pomocą usługi Azure DevOps. |
| 5 | Aby wdrożyć aplikacje logiki o krytycznym znaczeniu w warstwie Standardowa, które są zawsze dostępne i dynamiczne, nawet podczas aktualizacji lub konserwacji, włącz wdrożenie bez przestojów przez utworzenie i użycie miejsc wdrożenia. Brak przestoju oznacza, że podczas wdrażania nowych wersji aplikacji użytkownicy końcowi nie powinni mieć przerw w działaniu ani przestoju. Aby uzyskać więcej informacji, zobacz Konfigurowanie miejsc wdrożenia w celu włączenia wdrożenia bez przestojów w usłudze Azure Logic Apps. |
Na poniższym diagramie przedstawiono przykładowe początkowe środowisko migracji z aplikacją logiki w warstwie Standardowa, która organizuje przepływy pracy komunikujące się z interfejsami API, usługami, rozwiązaniami hybrydowymi i zasobami lokalnymi:
Test
Każda fala ma własne działania testowe, które są osadzone w każdym scenariuszu użytkownika. Jeśli chcesz użyć testowania shift-left, upewnij się, że wykonasz następujące zadania:
Automatyzowanie testów.
Usługa Azure Logic Apps (Standardowa) obejmuje możliwość przeprowadzania testów automatycznych. Poniższa lista zawiera więcej informacji i zasobów, które są bezpłatnie dostępne w witrynie GitHub:
Testowanie automatyczne za pomocą usługi Azure Logic Apps (Standardowa) od zespołu usługi Azure Logic Apps
W przypadku usługi Azure Logic Apps (w warstwie Standardowa) testowanie automatyczne nie jest już trudne ze względu na podstawową architekturę opartą na środowisku uruchomieniowym usługi Azure Functions i może działać w dowolnym miejscu, w którym można uruchomić usługę Azure Functions. Testy można pisać dla przepływów pracy uruchamianych lokalnie lub w potoku ciągłej integracji/ciągłego wdrażania. Aby uzyskać więcej informacji, zobacz przykładowy projekt dla struktury testowej usługi Azure Logic Apps.
Ta struktura testowa obejmuje następujące możliwości:
- Pisanie testów automatycznych na potrzeby kompleksowej funkcjonalności w usłudze Azure Logic Apps.
- Wykonaj szczegółową walidację na poziomach uruchamiania i akcji przepływu pracy.
- Zaewidencjonuj testy w repozytorium Git i uruchom je lokalnie lub w potokach ciągłej integracji/ciągłego wdrażania.
- Pozorowanie możliwości testowania dla akcji HTTP i łączników platformy Azure.
- Skonfiguruj testy, aby używać różnych wartości ustawień z środowiska produkcyjnego.
Podręcznik integracji: Standardowe testowanie usługi Logic Apps od Michaela Stephensona, MVP firmy Microsoft
Platforma testowania podręcznika integracji bazuje na platformie testowej dostarczonej przez firmę Microsoft i obsługuje dodatkowe scenariusze:
- Nawiąż połączenie z przepływem pracy w standardowej aplikacji logiki.
- Pobierz adres URL wywołania zwrotnego, aby można było wyzwolić przepływ pracy z testu.
- Sprawdź wyniki przebiegu przepływu pracy.
- Sprawdź dane wejściowe i wyjściowe operacji z historii uruchamiania przepływu pracy.
- Podłącz do zautomatyzowanych struktur testowania, których mogą używać deweloperzy aplikacji logiki.
- Podłącz aplikację SpecFlow, aby obsługiwać programowanie oparte na zachowaniu (BDD) dla aplikacji logiki.
Niezależnie od tego, które podejścia do automatyzacji lub zasobów są używane, możesz mieć powtarzalne, spójne i zautomatyzowane testy integracji.
Konfigurowanie pozornych testów odpowiedzi przy użyciu wyników statycznych.
Niezależnie od tego, czy skonfigurowaliśmy testy automatyczne, możesz użyć funkcji statycznych wyników w usłudze Azure Logic Apps, aby tymczasowo ustawić pozorne odpowiedzi na poziomie akcji. Ta funkcja umożliwia emulowanie zachowania określonego systemu, który chcesz wywołać. Następnie można przeprowadzić wstępne testowanie w izolacji i zmniejszyć ilość danych tworzonych w systemach biznesowych.
Uruchamiaj testy obok siebie.
W idealnym przypadku masz już podstawowe testy integracji dla środowiska programu BizTalk Server i ustanowione testy automatyczne dla usługi Azure Logic Apps. Następnie można uruchamiać testy obok siebie w sposób, który ułatwia sprawdzanie interfejsów przy użyciu tych samych zestawów danych i poprawianie ogólnej dokładności testu.
Wydanie do środowiska produkcyjnego
Po zakończeniu pracy zespołu i spełnieniu "definicji gotowej" scenariuszy użytkownika należy wziąć pod uwagę następujące zadania:
Utwórz plan komunikacji dla wersji produkcyjnej.
Zrób plan "cut-over".
Plan wycinania obejmuje szczegółowe informacje o zadaniach i działaniach niezbędnych do przejścia z bieżącej platformy na nową platformę, w tym o krokach, które zespół planuje wykonać. Uwzględnij następujące zagadnienia dotyczące planu jednorazowego:
- Kroki dotyczące wymagań wstępnych
- Próbę sukienki
- Osoby
- Szacowania harmonogramu
- Wyłączanie interfejsów na starej platformie
- Włączanie interfejsów na nowej platformie
- Testowanie poprawności
Określanie planu wycofywania.
Uruchom testowanie poprawności.
Planowanie obsługi operacji lub obsługi produkcyjnej.
Wybierz kryteria "przejdź lub niedź", aby zwolnić do środowiska produkcyjnego.
Świętuj sukces zespołu.
Posiada retrospektywę.
Najlepsze rozwiązania dotyczące migracji usługi BizTalk
Chociaż najlepsze rozwiązania mogą się różnić w różnych organizacjach, należy rozważyć świadomy wysiłek w celu promowania spójności, co pomaga zmniejszyć niepotrzebne wysiłki, które "na nowo wymyślić koło" i nadmiarowość podobnych typowych składników. W przypadku ułatwienia ponownego korzystania organizacja może szybciej tworzyć interfejsy, które stają się łatwiejsze do obsługi. Czas obrotu jest kluczowym czynnikiem umożliwiającym transformację cyfrową, więc priorytetem jest zmniejszenie niepotrzebnych problemów dla deweloperów i zespołów pomocy technicznej.
Podczas ustanawiania własnych najlepszych rozwiązań rozważ dostosowanie się do następujących wskazówek:
Ogólne konwencje nazewnictwa dla zasobów platformy Azure
Upewnij się, że skonfigurować i spójnie zastosować dobre konwencje nazewnictwa we wszystkich zasobach platformy Azure z grup zasobów do każdego typu zasobu. Aby położyć solidną podstawę do odnajdywania i obsługi, dobra konwencja nazewnictwa komunikuje cel. Najważniejszym punktem konwencji nazewnictwa jest to, że je posiadasz i że organizacja je rozumie. Każda organizacja ma niuanse, które mogą być konieczne do uwzględnienia.
Aby uzyskać wskazówki dotyczące tej praktyki, zapoznaj się z następującymi zaleceniami i zasobami firmy Microsoft:
- Przykłady skrótów dla zasobów platformy Azure
- Narzędzie Nazewnictwa platformy Azure, które generuje nazwy zgodne z platformą Azure, ułatwia standaryzację nazw i automatyzowanie procesu nazewnictwa.
Konwencje nazewnictwa zasobów usługi Azure Logic Apps
Projekt aplikacji logiki i przepływu pracy stanowi kluczowy punkt wyjścia, ponieważ ten obszar zapewnia elastyczność tworzenia unikatowych nazw przez deweloperów.
Nazwy zasobów aplikacji logiki
Aby odróżnić zasoby aplikacji logiki Zużycie i Standardowa, możesz użyć różnych skrótów, na przykład:
- Zużycie: LACon
- Standardowa: LAStd
Z perspektywy organizacji można zaprojektować wzorzec nazewnictwa obejmujący jednostkę biznesową, dział, aplikację i opcjonalnie środowisko wdrażania, takie jak DEV, UAT, PRODitd., na przykład:
LAStd-<*business-unit-name*>-<*department-name* or *application-name*>-<*environment-name*>
Załóżmy, że masz standardową aplikację logiki, która implementuje przepływy pracy dla działu kadr w jednostce biznesowej Usług firmowych. Możesz nazwać zasób aplikacji logiki LAStd-CorporateServices-HR-DEV i użyć notacji Pascal Case, jeśli jest to odpowiednie dla spójności.
Nazwy przepływów pracy aplikacji logiki
Zasób aplikacji logiki Zużycie zawsze jest mapowy na tylko jeden przepływ pracy, więc potrzebujesz tylko jednej nazwy. Zasób standardowej aplikacji logiki może zawierać wiele przepływów pracy, dlatego należy zaprojektować konwencję nazewnictwa, którą można również zastosować do przepływów pracy elementów członkowskich. W przypadku tych przepływów pracy należy wziąć pod uwagę konwencję nazewnictwa opartą na nazwie procesu, na przykład:
Process-<*process-name*>
Jeśli więc masz przepływ pracy, który implementuje zadania dołączania pracowników, takie jak tworzenie rekordu pracownika, możesz nazwać przepływ pracy Process-EmployeeOnboarding.
Poniżej przedstawiono więcej zagadnień dotyczących projektowania konwencji nazewnictwa przepływu pracy:
- Postępuj zgodnie ze wzorcem nadrzędny-podrzędny dla przepływów pracy, w których chcesz wyróżnić pewną relację między jednym lub kilkoma przepływami pracy.
- Należy wziąć pod uwagę, czy przepływ pracy publikuje lub używa komunikatu.
Nazwy operacji przepływu pracy
Po dodaniu wyzwalacza lub akcji do przepływu pracy projektant automatycznie przypisuje domyślną nazwę ogólną dla tej operacji. Jednak nazwy operacji muszą być unikatowe w przepływie pracy, więc projektant dołącza sekwencyjne sufiksy liczbowe w kolejnych wystąpieniach operacji, co sprawia, że czytelność i odszyfrowywanie oryginalnej intencji dewelopera jest trudne.
Aby ułatwić zrozumienie nazw operacji, możesz dodać krótki deskryptor zadań po tekście domyślnym i użyć notacji Pascal Case w celu zapewnienia spójności. Na przykład dla akcji Przeanalizuj kod JSON można użyć nazwy, takiej jak Parse JSON-ChangeEmployeeRecord. W przypadku tego podejścia lub innych podobnych podejść będziesz pamiętać, że akcja to Analizowanie kodu JSON i konkretnego celu akcji. W związku z tym, jeśli musisz użyć danych wyjściowych tej akcji w dalszej części akcji podrzędnego przepływu pracy, możesz łatwiej zidentyfikować i znaleźć te dane wyjściowe.
Uwaga
W przypadku organizacji, które intensywnie używają wyrażeń, należy wziąć pod uwagę konwencję nazewnictwa, która nie promuje używania białych znaków (' '). Język wyrażeń w usłudze Azure Logic Apps zastępuje białe znaki podkreśleniami ('_'), co może komplikować tworzenie. Unikając z góry spacji, możesz zmniejszyć tarcie podczas tworzenia wyrażeń. Zamiast tego należy użyć łącznika lub łącznika ('-'), który zapewnia czytelność i nie ma wpływu na tworzenie wyrażeń.
Aby uniknąć późniejszej możliwej zmiany i problemów dotyczących zależności podrzędnych, które są tworzone podczas korzystania z danych wyjściowych operacji, zmień nazwy operacji natychmiast po dodaniu ich do przepływu pracy. Zazwyczaj akcje podrzędne są automatycznie aktualizowane po zmianie nazwy operacji. Jednak usługa Azure Logic Apps nie zmienia automatycznie nazw wyrażeń niestandardowych utworzonych przed wykonaniem zmiany nazwy.
Nazwy połączeń
Podczas tworzenia połączenia w przepływie pracy bazowy zasób połączenia automatycznie pobiera nazwę ogólną, taką jak sql lub office365. Podobnie jak nazwy operacji, nazwy połączeń muszą być również unikatowe. Kolejne połączenia z tym samym typem uzyskują sekwencyjny sufiks liczbowy, na przykład sql-1, sql-2 itd. Takie nazwy nie zawierają żadnego kontekstu, co sprawia, że różnicowanie i mapowanie połączeń z przepływami pracy jest niezwykle trudne, zwłaszcza dla deweloperów, którzy nie znają przestrzeni rozwiązania i muszą obsługiwać te przepływy pracy.
Dlatego istotne i spójne nazwy połączeń są ważne z następujących powodów:
- Czytelność
- Łatwiejszy transfer wiedzy i możliwość obsługi
- Ład korporacyjny
Ponownie, posiadanie konwencji nazewnictwa jest krytyczne, chociaż format nie jest nadmiernie ważny. Na przykład możesz użyć następującego wzorca jako wytycznych:
CN-<*connector-name*>-<*logic-app-or-workflow-name*>
W konkretnym przykładzie możesz zmienić nazwę połączenia usługi Service Bus w przepływie pracy aplikacji logiki OrderQueue przy użyciu nazwy CN-ServiceBus-OrderQueue . Aby uzyskać więcej informacji, zobacz wpis w blogu Turbo360 (dawniej Bezserwerowy360), Najlepsze rozwiązania dotyczące aplikacji logiki, porady i wskazówki: konwencja nazewnictwa łączników #11.
Obsługa wyjątków z zakresami i opcjami "Uruchom po"
Zakresy zapewniają możliwość grupowania wielu akcji, dzięki czemu można zaimplementować zachowanie Try-Catch-Finally. W projektancie możesz zwinąć i rozwinąć zawartość zakresu, aby zwiększyć produktywność deweloperów.
Podczas implementowania tego wzorca można również określić, kiedy należy uruchomić akcję Zakres i akcje wewnątrz, na podstawie stanu wykonania poprzedniej akcji, które mogą mieć wartość Powodzenie, Niepowodzenie, Pominięto lub Limit czasu. Aby skonfigurować to zachowanie, użyj opcji Uruchom po (runAfter) akcji Zakres:
- Powodzenie
- Nie powiodło się
- Pominięto
- Przekroczono limit czasu
Konsolidowanie usług udostępnionych
Podczas tworzenia rozwiązań integracji rozważ tworzenie i używanie usług udostępnionych do typowych zadań. Możesz utworzyć i uwidocznić kolekcję usług udostępnionych, z których może korzystać twój zespół projektu i inne osoby. Każdy zyskuje większą produktywność, jednolitość i możliwość wymuszania ładu w rozwiązaniach organizacji. W poniższych sekcjach opisano niektóre obszary, w których warto rozważyć wprowadzenie usług udostępnionych:
| Usługa udostępniona | Przyczyny |
|---|---|
| Scentralizowane rejestrowanie | Udostępniaj typowe wzorce dotyczące instrumentowania kodu przez deweloperów przy użyciu odpowiedniego rejestrowania. Następnie można skonfigurować widoki diagnostyczne, które ułatwiają określenie kondycji interfejsu i możliwości obsługi. |
| Śledzenie biznesowe i monitorowanie aktywności biznesowej | Przechwyć i uwidaczniać dane, aby eksperci z dziedziny biznesowej mogli lepiej zrozumieć stan transakcji biznesowych i wykonywać samoobsługowe zapytania analityczne. |
| Dane konfiguracji | Oddziel dane konfiguracji aplikacji od kodu, aby ułatwić przenoszenie aplikacji między środowiskami. Upewnij się, że zapewnia ujednolicone i łatwe replikowalny podejście do uzyskiwania dostępu do danych konfiguracji, dzięki czemu zespoły projektów mogą skupić się na rozwiązywaniu problemu biznesowego, a nie poświęcać czasu na konfiguracje aplikacji na potrzeby wdrażania. W przeciwnym razie, jeśli każdy projekt zbliżył się do tej separacji w wyjątkowy sposób, nie można korzystać z korzyści skali. |
| Łączniki niestandardowe | Utwórz łączniki niestandardowe dla systemów wewnętrznych, które nie mają wstępnie utworzonych łączników w usłudze Azure Logic Apps, aby uprościć obsługę zespołu projektu i innych osób. |
| Typowe zestawy danych lub źródła danych | Uwidacznianie typowych zestawów danych i źródeł danych jako interfejsów API lub łączników do użycia przez zespoły projektów i unikanie ponownego tworzenia koła. Każda organizacja ma wspólne zestawy danych, które muszą integrować systemy w środowisku przedsiębiorstwa. |
Następne kroki
Wiesz już więcej na temat dostępnych metod migracji i najlepszych rozwiązań dotyczących przenoszenia obciążeń programu BizTalk Server do usługi Azure Logic Apps. Aby przekazać szczegółową opinię na temat tego przewodnika, możesz użyć następującego formularza: