Centrum wsparcia Workiva

Przegląd

Seria „wiodących praktyk” przedstawia zalecane ogólne praktyki dla różnych artefaktów w pakiecie Data Management Suite na platformie Workiva. Należy pamiętać, że są to ogólne wytyczne i mogą wymagać dostosowania w zależności od konkretnych, unikalnych przypadków użycia. Celem tych zaleceń jest pomoc w poprawieniu organizacji Twoich miejsc pracy. Zacznijmy od omówienia tych konwencji nazewnictwa.

Konwencje nazewnictwa dla połączeń, łańcuchów i środowisk

Połączenia w łańcuchach

Podczas tworzenia połączeń w łańcuchach, kluczowe jest ustalenie optymalnych konwencji nazewnictwa, aby zapewnić przejrzystość i rozróżnienie pomiędzy środowiskami:

• Nazwa złącza: Podaj opisową nazwę złącza, która jasno wskazuje jego cel i funkcję.
• Typ obszaru roboczego: Określ obszar roboczy lub projekt, w którym wykorzystywany jest łącznik.
• Środowisko łącznika: Jasno zidentyfikuj środowisko (np. programistyczne, produkcyjne), któremu odpowiada łącznik.

Przykład:

• Połączenie SFTP | Raportowanie SEC | NON-PROD
  • Opis: Nawiązuje połączenie z serwerem SFTP dla rozwiązania obszaru roboczego raportowania SEC w środowisku nieprodukcyjnym, takim jak środowisko programistyczne, zapewnianie jakości, piaskownica itp.
• Połączenie SFTP | Raportowanie SEC | PROD
  • Opis: Nawiązuje połączenie z serwerem SFTP dla rozwiązania obszaru roboczego raportowania SEC w środowisku produkcyjnym.

Taka konwencja nazewnictwa ułatwia identyfikację i zarządzanie połączeniami w różnych środowiskach. Gwarantuje, że łańcuchy w obrębie określonych środowisk współpracują wyłącznie z odpowiednimi źródłami, zwiększając bezpieczeństwo i niezawodność. Połączenie Non-Prod można wykorzystać w środowiskach Non-Prod, Dev i Test.

Tę konwencję nazewnictwa należy stosować spójnie do wszystkich połączeń, bez względu na to, czy są to połączenia podstawowe, czy połączenia premium. Dzięki zachowaniu jednolitości nazewnictwa połączeń w różnych środowiskach można usprawnić proces awansu łańcucha i umożliwić bezproblemowe wykonywanie łańcuchów w różnych obszarach roboczych.

Konstruktor łańcuchów

Podczas tworzenia łańcuchów na platformie Workiva kluczowe jest zachowanie uporządkowanej konwencji nazewnictwa. Przejrzysta i spójna strategia nazewnictwa pozwala na efektywniejsze poruszanie się po Łańcuchach, zwłaszcza gdy liczba przepływów pracy rośnie. W tej sekcji przedstawiono najważniejsze praktyki nazewnictwa łańcuchów na podstawie ich celu, systemu źródłowego, częstotliwości i hierarchii przepływu pracy.

Cel i system źródłowy

Określanie celu łańcucha

Rozważ poniższe pytania, aby określić cel łańcucha:

• Jakiego rodzaju dane są wykorzystywane w ramach Łańcucha?
• Czy Łańcuch można wykorzystać w wielu procesach (czyli czy jest Łańcuchem Użytkowym)?
• Z jakiego systemu źródłowego pobierane są dane?

Częstotliwość

Określanie częstotliwości łańcucha

Nadając łańcuchowi nazwę, ważne jest wskazanie częstotliwości jego uruchamiania, zwłaszcza jeśli ma być uruchamiany automatycznie. Sugerujemy następujące wytyczne:

• Wskaż, czy łańcuch ma być uruchamiany ad hoc.
• Określ, czy Łańcuch działa codziennie, co tydzień, co kwartał czy co rok.

Hierarchia

Organizowanie złożonych kompilacji łańcuchowych

W przypadku kompilacji łańcuchowej składającej się z wielu przepływów pracy, zwykle istnieje łańcuch najwyższego poziomu z wieloma podłańcuchami wykonywanymi w sekwencji. Uporządkuj te łańcuchy, poprzedzając je numerowaną konwencją nazewnictwa.

Przykład konwencji nazewnictwa numerowanego:

• 1.0 Łańcuch najwyższego poziomu
• 1.1 Wykonaj zestaw danych
• 1.2 Ładowanie danych do tabeli Wdata
• 1.3 Odśwież połączenia przychodzące

Dzięki takiemu podejściu użytkownicy mogą szybko określić kolejność operacji w ramach przepływu pracy i automatycznie organizować Łańcuchy w Przestrzeni roboczej na podstawie kolejności numerycznej.

Praktyczne przykłady konwencji nazewnictwa łańcuchowego

Łańcuchy użytkowe

Łańcuchy narzędziowe to powszechne przepływy pracy wykonywane przez wiele innych przepływów pracy, takie jak Ładowanie danych do tabeli Wdata. Aby mieć pewność, że łańcuchy narzędzi będą dobrze widoczne na górze obszaru roboczego, należy zastosować następujące konwencje nazewnictwa:

• 0.0 - [Nazwa łańcucha narzędzi] | [Proces] | Łańcuch narzędzi
• 0.1 - [Nazwa łańcucha narzędzi] | [Proces] | Łańcuch narzędzi
• 0.2 - [Nazwa łańcucha narzędzi] | [Proces] | Łańcuch narzędzi

Systemy źródłowe

Termin „systemy źródłowe” odnosi się do źródła danych, które może obejmować różne systemy, takie jak ERP (Enterprise Resource Planning, EPM (Enterprise Performance Management), HR (Human Resources) i systemy księgowe, lub może być oparte na plikach, jak dane pochodzące z protokołu SFTP/FTP.

Poniższy przykład ilustruje organizację trzech Systemów Źródłowych:

1. Dzień roboczy
   • 1.0 - [Nazwa łańcucha/proces] | Dzień roboczy | [Częstotliwość]
   • 1.1 - [Nazwa łańcucha/proces] | Dzień roboczy | [Częstotliwość]
   • 1.2 - [Nazwa łańcucha/proces] | Dzień roboczy | [Częstotliwość]
2. SOK ROŚLINNY
   • 2.0 - [Nazwa łańcucha/proces] | SAP | [Częstotliwość]
   • 2.1 - [Nazwa łańcucha/proces] | SAP | [Częstotliwość]
   • 2.2 - [Nazwa łańcucha/proces] | SAP | [Częstotliwość]
3. Netsuite
   • 3.0 - [Nazwa łańcucha/proces] | Netsuite | [Częstotliwość]
   • 3.1 - [Nazwa łańcucha/proces] | Netsuite | [Częstotliwość]
   • 3.2 - [Nazwa łańcucha/proces] | Netsuite | [Częstotliwość]

W przypadku obszaru roboczego zawierającego dużą liczbę łańcuchów, w celu zapewnienia przejrzystości i lepszej organizacji należy stosować poniższe przykłady konwencji nazewnictwa:

Taka struktura zapewnia jasne i spójne konwencje nazewnictwa oraz organizację, dzięki czemu łatwiej jest identyfikować i zarządzać łańcuchami narzędzi i łańcuchami systemów źródłowych na podstawie ich procesu i częstotliwości wykonywania.

Konwencja nazewnictwa środowisk

Środowiska umożliwiają łatwe planowanie, testowanie i wdrażanie przepływów pracy. Usprawnia to stosowanie najlepszych praktyk cyklu życia oprogramowania (SDLC) w procesach automatyzacji. Podczas tworzenia środowisk sugerujemy korzystanie z następujących uproszczonych konwencji nazewnictwa, aby jasno określić cel każdego środowiska. Pomaga to użytkownikom szybko zrozumieć przeznaczenie każdego środowiska.

Typy środowisk i konwencje nazewnictwa

1. DEV (Rozwój)
   • Cel: Wykorzystywane do opracowywania nowych łańcuchów i procesów. Twórcy oprogramowania mogą bezpiecznie tworzyć i eksperymentować w środowisku programistycznym (DEV).
   • Przykład: DEV
2. Test (lub piaskownica)
   • Cel: Poświęcony procesom testowania i zapewniania jakości. Zespoły ds. zapewnienia jakości mogą przeglądać i testować w środowisku testowym.
   • Przykład: TEST
3. PROD (Produkcja)
   • Cel: Dla procesów, które zostały przetestowane, udoskonalone i są gotowe do wdrożenia w środowisku produkcyjnym. 

   • Przykład: PROD

     

Uwagi

• Wiele łańcuchów może mieć identyczne nazwy, ale każdy z nich jest wyróżniany unikalnym identyfikatorem znanym jako GUID.

• Każda przestrzeń robocza ma unikalny identyfikator (patrz adres URL), dzięki czemu wiele przestrzeni roboczych może mieć tę samą nazwę. Odradzamy jednak takie działanie ze względu na potencjalne ryzyko wprowadzenia użytkownika w błąd.
• Łańcuchy, Obszar roboczy i Środowisko obszaru roboczego to nazwy wszystkich obsługiwanych przestrzeni i standardowego zestawu znaków Workiva.
• Długość nazw:
  • Nazwy łańcuchowemają maksymalną długość 100 znaków.
    Uwaga: podczas kopiowania łańcuchów automatycznie dodawane są znaki „-- Kopia”. Jeżeli w rezultacie nazwa będzie dłuższa niż 100 znaków, łańcuch nie zostanie skopiowany.
  • Nazwy poleceń łańcuchowych( węzłów) mogą mieć maksymalnie 255 znaków. 
  • Nazwy obszarów roboczychmają maksymalną długość 50 znaków.
  • Nazwy środowisk roboczychmają maksymalną długość 25 znaków.

Podsumowanie

Użycie tych uproszczonych konwencji nazewnictwa pomaga zachować uporządkowaną strukturę środowiska, po której można łatwo nawigować. Gwarantuje to, że cel każdego środowiska jest jasny, co zmniejsza ryzyko nieporozumień i zwiększa wydajność podczas faz rozwoju, testowania i wdrażania.