Dotyczy wersji 8.3.x; Autor: Jacek Język
Wstęp
System WEBCON BPS w wersji 8.3 posiada mechanizm pozwalający przenosić definicje procesów między kilkoma niezależnymi środowiskami. W pełni wspierany jest model środowisk DEV-TEST-PROD, w którym to modelu środowisko deweloperskie (DEV) przeznaczone jest do tworzenia nowych procesów, środowisko testowe (TEST) służy wykonywaniu testów funkcjonalnych przed ostatecznym wdrożeniem rozwiązania na środowisko produkcyjne (PROD) na którym pracują użytkownicy.
Tworzenie procesów w taki sposób by były one niewrażliwe na kontekst środowiska w którym pracują, wymaga przestrzegania pewnego reżimu. Wynika on jednak naturalnie z funkcjonalności dostępnych w WEBCON BPS Studio oraz działania mechanizmów platformy. Dzięki właściwemu podejściu zastosowanemu przy projektowaniu procesów, możliwe będzie wykorzystanie mechanizmu Eksport-Import do automatycznego i szybkiego przenoszenia zmian między środowiskami.
Zanim przejdę do omawiania zasad jakimi należy się kierować tworzą eksportowalne obiegi, kilka słów wyjaśnienia dotyczących działania mechanizmu Eksport-Import. Jego zrozumienie pozwoli łatwiej wyjaśnić konieczność stosowania opisywanego podejścia przy tworzeniu procesów.
Eksport-Import od strony technicznej
Wszystkie elementy tworzonego procesu takie jak atrybuty formularza, typy dokumentów, obiegi dokumentów czy źródła danych są w systemie jednoznacznie identyfikowalne przez identyfikator ID.
Przykłady identyfikatorów różnych elementów procesu.
Obiegu:
Atrybutu:
Kroku:
Identyfikatory są unikalne w skali środowiska (a dokładniej bazy danych) na którym zostały utworzone. Oznacza to, że identyczny proces utworzony na dwóch różnych środowiskach, będzie posiadał różne identyfikatory swoich obiektów (atrybutów, obiegów, dokumentów etc.).
Przykładowy proces „Proces składania wniosku urlopowego” wdrożony na środowisku TEST oraz PROD – różne identyfikatory procesu.
| Środowisko TEST | Środowisko PROD |
 |
 |
Mechanizm Eksport-Import podczas przenoszenia procesu na inne środowisko musi być w stanie skojarzyć proces importowany z istniejącym na środowisku by rozpoznać, które elementy zostały zmienione, które zostały dodane a które usunięte. By możliwe było jednoznaczne zidentyfikowanie wszystkich elementów procesu, mechanizm Eksport-Import bazuje nie na ID (które jak wcześniej wspomniałem jest różne na różnych środowiskach) ale na dedykowanym identyfikatorze GUID. Identyfikator GUID, podobnie jak ID, jest automatycznie nadawany elementom procesu podczas ich tworzenia. W przeciwieństwie jednak do identyfikatora ID, GUID pozostaje niezmienny w kontekście wielu środowisk. GUID nie jest widoczny dla użytkownika tworzącego proces z poziomu WEBCON BPS Studio niemniej jest zapisywany w bazie danych i przenoszony wraz z importowanym procesem na nowe środowiska. Dzięki temu technicznemu rozwiązaniu, mechanizm Eksport-Import bazując na GUID, będzie w stanie rozpoznawać wszelkie zmiany i poprawnie aktualizować proces.
Uwaga.
Pracując w rygorze DEV-TEST-PROD, z wykorzystaniem mechanizmu Eksport-Import do przenoszenia zmian z jednego środowiska na drugie, nie można dokonywać ręcznych zmian w procesie na środowisku PROD. Wynika to prostego faktu. Dodany poza mechanizmem Eksport-Import nowy element procesu na środowisku PROD, będzie posiadał inny identyfikator GUID co sprawi, że przy najbliższym imporcie tego procesu ze środowiska TEST wszelkie zmiany zostaną nadpisane (nowo utworzony element zostanie usunięty, ponieważ na środowisku TEST obiekt o takim GUID nie istnieje).
W przypadku sytuacji awaryjnej w której jakakolwiek modyfikacja procesu musiała zostać dokonana manualnie, poza mechanizmem Eksport-Import, należy zadbać by wszystkie środowiska zostały po takiej zmianie poprawnie zsynchronizowane. Przez poprawną synchronizację należy rozumieć wyeksportowanie zmienionego procesu ze środowiska PROD a następnie zaimportowaniu go na środowisko TEST oraz DEV.
Synchronizacja ręczna, czyli ręczne wykonywanie identycznych modyfikacji procesu na pozostałych środowiskach, nie jest poprawnym podejściem ponieważ nie gwarantuje spójności procesu w ramach środowisk DEV-TEST-PROD i może doprowadzić do błędów przy wykonywaniu importów w późniejszym czasie.
Podstawowe zasady tworzenia eksportowalnych procesów
Omówię teraz podstawowe zasady którymi należy się kierować przy projektowaniu i tworzeniu procesów by było możliwe ich wdrożenie na środowisko PROD, przy pomocy mechanizmu Eksport-Import w sposób szybki i bezbłędny. Poniższe zalecenia są ważne nie tylko z powodu możliwości korzystania z Eksport-Import, należy je stosować generalnie, jako dobre praktyki tworzenia procesów dzięki którym tworzone rozwiązania będą bardziej zrozumiałe, mniej wrażliwe na zmianę a w konsekwencji bardziej niezawodne.
Używanie Tagów
Tagi są elementami używanymi przy tworzeniu wyrażeń (SQL, CAML, JavaScript). Tag reprezentuje konkretną wartość konkretnego obiektu w systemie np. wartość atrybutu formularza.
Tagi w przypadku SQL oraz CAML mają postać nawiasów klamrowych { i }
w przypadku JavaScript nawiasów klamrowych w połączeniu ze znakiem „hash” (jest to nowość w wersji 8.3) #{ i }#
Tagi zamieniane są na konkretne wartości w trakcie wykonywania wyrażenia.
Ponieważ tagi reprezentują obiekty których ID może się zmieniać po przeniesieniu procesu na inne środowisko, jest niezmiernie ważne by w tworzonych wyrażeniach (warunkach wykonania, zapytaniach) używać właśnie tagów zamiast liczb jako stałych identyfikatorów. Wówczas w importowanym procesie automatycznie zostaną one podmienione na poprawne z punktu widzenia środowiska identyfikatory obiektów.
Poniżej przykład wyrażenia JavaScript ustawiającego wartość wiersza w konkretnej kolumnie listy pozycji. Zarówno identyfikator listy pozycji jak i identyfikator kolumny został zdefiniowany przy pomocy tagów.
To samo wyrażenie w trybie podstawowym edytora wyrażeń JavaScript.
Korzystanie ze zmiennych globalnych lub procesu w celu uniezależnienia się od środowiska
Różne środowiska z definicji będą różnić się od siebie pewnymi cechami. Najbardziej oczywistym jest to, że środowisko PROD będzie posiadać inny adres WWW niż środowisko TEST. Podobnych różnic wynikających z tego, że środowiska oparte są na innej infrastrukturze technicznej może być więcej.
Jeśli wewnątrz procesu konieczne jest odwołanie się do wartości, która może być inna na różnych środowiskach, należy korzystać z funkcjonalności Zmiennych globalnych lub Zmiennych procesu, kolejnej nowości wprowadzonej w wersji 8.3 BPS.
Funkcjonalność Zmiennych globalnych pozwala zdefiniować różne wartości w zależności od środowiska na którym będzie uruchamiany proces. Wartości te użyte jako tagi przy tworzeniu wyrażeń wewnątrz procesu, zostaną podmieniony na właściwe w zależności od środowiska.
Źródła danych w trybie DEV-TEST-PROD
Źródła danych są kolejnym elementem, który w naturalny sposób może różnić się w zależności od środowiska na którym jest definiowany. Różnica ta może wynikać z innego adresu źródła, innego użytkownika lub hasła dostępu do źródła.
Źródła danych definiowane w WEBCON BPS Studio pozwalają na podanie różnych parametrów połączenia w zależności od środowiska na którym mają pracować. Wykorzystanie tej funkcjonalności uniezależnia tworzony proces od kontekstu środowiska w którym będzie pracował.
Uwaga.
Źródła danych jako element definiowany poza procesem (proces korzysta ze źródła danych, niemniej źródło definiowane jest w konfiguracji systemu, nie w konfiguracji procesu) może być bezpiecznie modyfikowany po zaimportowaniu go na środowisko docelowe. Oznacza to, że tworząc proces na środowisku DEV, korzystający z zewnętrznego źródła danych nie jest wymagana znajomość adresu tego źródła na wszystkich środowiskach (TEST oraz PROD). Konfigurację źródła w kontekście właściwego środowiska można odłożyć do momentu wdrożenia procesu na to środowisko.
Korzystanie z bazodanowych nazw kolumn
Wartości atrybutów procesu przechowywane są w bazie danych w kolumnie przydzielanej w momencie utworzenia atrybutu.
Przykład atrybutu „Data rejestracji”, którego wartości przechowywane będą w kolumnie WFD_AttDateTime13.
Eksportując a następnie importując proces na inne środowisko, mechanizm Eksport-Import dba o to, by na nowym środowisku atrybut nadal był osadzony dokładnie w tej samej kolumnie bazy danych jak na środowisku z którego proces został wyeksportowany. Dzięki temu możliwe jest jednolite tworzenie zapytań, funkcji SQL lub procedur składowanych bazujących na nazwach kolumn bez konieczności ich modyfikowania w kontekście wielu środowisk.
Poniżej przykład zapytania zwracającego sygnaturę dokumentu oraz datę rejestracji wniosku urlopowego. Taka konstrukcja zadziała poprawnie niezależnie od tego na jakim środowisku (DEV-TEST-PROD) zostanie uruchomiona.
Przykłady poprawnych i niepoprawnych konstrukcji
Poniżej przedstawię kilka konkretnych przykładów wyrażeń SQL w formie niepoprawnej z punktu widzenia funkcjonalności Eksport-Import oraz ich przenoszalności między środowiskami. Wyjaśnię na czym polegają błędy, czym będą skutkować i jak powinny wyglądać prawidłowe wyrażenia.
Identyfikatory obiektów w wyrażeniach
Jak już wcześniej wspomniałem w konstrukcji wyrażeń należy unikać wpisywania identyfikatorów obiektów jako stałych liczb.
Poniżej przykład warunku wykonania akcji w zależności od typu dokumentu (Nieprawidłowo).
W przykładzie tym niepoprawnie została użyta wartość 16 określająca identyfikator typu dokumentu.
Identyfikator ten jest co prawda poprawny w kontekście środowiska DEV, lecz po zaimportowaniu procesu na środowisko PROD identyfikator typu dokumentu może być inny, a w konsekwencji cały warunek może nie zadziałać poprawnie.
Zamiast podawać wprost identyfikator obiektu należy użyć właściwego tagu, który zostanie prawidłowo podmieniony w momencie importowania procesu.
Wyrażenie po poprawieniu (Prawidłowo)
Oraz to samo wyrażenie w trybie podstawowym (Prawidłowo)
Grupa SharePoint jako zmienna globalna
Innym, bardziej złożonym przykładem jest wykorzystanie funkcji SQL sprawdzającej czy użytkownik o podanym loginie należy do danej grupy SharePoint.
Warunek taki może być użyty w celu określenia widoczności atrybutu (Nieprawidłowo).
W powyższym przykładzie niepoprawnie została użyta liczba 45 jako identyfikator grupy SharePoint oraz adres witryny w postaci ciągu znaków https://intranet.webcon.pl. Obie te wartości będą inne na środowisku PROD co sprawi, że warunek będzie działał nieprawidłowo.
By uniezależnić powyższe wyrażenie od kontekstu środowiska na którym będzie wykonywane należy wykorzystać mechanizm Zmiennych globalnych.
W konfiguracji systemu tworzymy dwie zmienne: „Adres witryny” oraz „Grupa SP administratorzy” w których definiujemy poprawne wartości, oddzielnie dla każdego środowiska.
Tak utworzone zmienne należy użyć jako tagi w wyrażeniu. Dodatkowo zamiast na sztywno wpisanego loginu użytkownika został użyty tag reprezentujący aktualnie zalogowanego użytkownika.
Wyrażenie (Prawidłowo)
Oraz to samo wyrażenie w trybie podstawowym (Prawidłowo)
Tagi w momencie wykonywania wyrażenia zostaną zastąpione poprawną, z punktu widzenia środowiska na którym wyrażenie jest wykonywane, wartością.
Hiperłącze
Rozważmy przypadek w którym obieg „Korespondencja” ma dwa typy dokumentów: Korespondencji przychodzącej i Korespondencji wychodzącej. Każdy dokument Korespondencji wychodzącej jest powiązany do jednego dokumentu Korespondencji przychodzącej. Na formularzu Korespondencji przychodzącej chcemy wyświetlić wszystkie dokumenty powiązane Korespondencji wychodzącej oraz dać możliwość przejścia do tych dokumentów za pomocą linka.
Do tego celu można użyć atrybutu typu „Tabela SQL” w którym wyświetlone zostaną sygnatura, data rejestracji oraz data wysłania dokumentu powiązanego. Sygnatura będzie linkiem umożliwiającym przejście do danego dokumentu.
Przykładowe wyrażenie zwracające dane dla Tabeli SQL może wygadać w następujący sposób (Nieprawidłowo):
By w wierszu tabeli wartość Sygnatury wyświetlana była jako link z możliwością nawigacji do konkretnego elementu użyta została składnia:
'link:http://intranet.webcon.pl/DEV/Korespondencja/_layouts/15/WebCon/WFDynamic.aspx?WFD_ID=' + cast(WFD_ID as varchar(12)) + ';displayname:' + WFD_Signature
która jest w trakcie uruchomienia zapytania rozwijana w następujący sposób:
link:http://intranet.webcon.pl/DEV/Korespondencja/_layouts/15/WebCon/WFDynamic.aspx?WFD_ID=1;displayname:BPM/2015/03/0001
W efekcie na formularzu otrzymujemy tabelę w której po kliknięciu w sygnaturę otworzy się formularz dokumentu powiązanego.
Rozwiązanie będzie działać poprawnie na środowisku DEV na którym adres witryny dla obiegu korespondencji wychodzącej to http://intranet.webcon.pl/DEV/Korespondencja/ .
Jednak po przeniesieniu tak zdefiniowanego obiegu na środowisko PROD (na którym adres witryny będzie zupełnie inny), link będzie odnosił się nie do zupełnie innego dokumentu.
Rozwiązaniem jest utworzenie Zmiennej globalnej w której zdefiniowany zostanie właściwy adres witryny dla różnych środowisk.
Zmienną ta należy następnie użyć przy tworzeniu linka w wyrażeniu SQL (Prawidłowo).
W ten sposób wyrażenie na którym oparta jest lista SQL będzie niewrażliwe na kontekst środowiska na którym będzie wykonywanie, co oznacza że funkcjonalnie będzie działało poprawnie na każdym ze środowisk.
