Lista SharePoint kontra Obieg słownikowy

Facebooktwitterpinterestlinkedinmail
Dotyczy wersji 2017.1.x; Autor: Tomasz Pytlak

Wstęp:

Listy SharePointowe stanowią wygodny sposób przechowywania informacji, do których odwołują się pola wyboru. Jednak w momencie przekroczenia pewnej ilości danych, wykorzystywanie ich jako źródła dla atrybutów znacznie spowalnia działanie systemu. W takim przypadku sensowną alternatywę stanowi stworzenie Obiegu słownikowego.

Obieg słownikowy, to zwyczajny obieg, wykorzystywany w celu odwoływania się do jego atrybutów.

Istnieją dwa rodzaje obiegów słownikowych:

  1. Obieg, w którym pojedyncza instancja odpowiada całemu słownikowi, natomiast pojedyncze elementy tworzone są przez listę pozycji.
  2. Obieg, w którym jedna instancja odpowiada jednej pozycji, do której można się odwołać.

W celu zademonstrowania możliwości Obiegu słownikowego stworzono trzy obiegi. Dwa pierwsze – „Produkty” i „Rodzaje produktów”, pełnią rolę udostępniających dane, trzeci – „Zamówienia”, jedynie odwołuje się do nich.

Poniżej przedstawiono poszczególne formularze oraz powiązania pomiędzy nimi.

Obieg „Rodzaje produktów”:

Dla tego obiegu utworzono tylko jedną instancję. Rolę elementów pełnią wiersze listy pozycji. Oczywiście w prawdziwym przypadku lista byłaby znacznie bardziej obszerna.

Rys. 1 Obieg słownikowy „Rodzaje produktów” na kroku „Aktywne rodzaje produktów”

 

Obieg słownikowy podpięty jest do WEBCON BPS jako źródło SQL poprzez bazę danych WEBCON.

 


Rys. 2 Obieg słownikowy „Rodzaje produktów” jako źródło danych

 

Obieg „Produkty”:

Pomimo że idea wykorzystania obiegu jako źródła danych jest taka sama, może ona zostać zrealizowana w inny sposób.

Niniejszy obieg składa się z 3 kroków wykorzystując schemat: Wersja robocza
-> Aktywna -> Archiwalna. Każda instancja znajdująca się na drugim kroku („Aktywne produkty”), stanowi pojedynczy element możliwy do wybrania w obiegu „Zamówienia”.

 

Rys. 3 Obieg słownikowy „Produkty” na kroku „Rejestracja”

 

Użytkownik wybiera typ produktu spośród wartości udostępnionych na liście pozycji w obiegu „Rodzaje produktów”. Pozostałe pola uzupełniane są „ręcznie”. Po przejściu ścieżką „Dodaj produkt”, staje się on dostępny w obiegu „Zamówienia”. Jego usunięcie jest możliwe poprzez przejście ścieżką „Archiwizuj”, a zapisanie zmian za pomocą ścieżki „Aktualizuj”.

Dodatkowo na ścieżce „Dodaj produkt” ustawiono walidację, która uniemożliwi dodanie produktu o wartości powyżej 10 000 osobie niebędącej członkiem grupy BPS_TP.

 

Rys. 4 Warunkowa walidacja wartości produktu

Ustawienie obiegu jako źródła może zostać zrealizowane w sposób analogiczny jak dla Rodzajów produktów, odwołując się do tabeli WFElements oraz zawężając do rodzaju obiegu i kroku. Zdecydowano się jednak wykorzystać alternatywną możliwość – „Źródło BPS”. Metoda ta pozwala na wybranie danych z istniejących obiegów identycznie, jak podczas konfiguracji WebPartów na witrynie. Więcej na ten temat można przeczytać w poniższym artykule:

Źródło danych WEBCON BPS

 

Rys. 5 Obieg słownikowy „Produkty” jako „Źródło BPS”

 

Rys. 6 Konfiguracja źródła danych BPS

 

Rys. 7 Wybór kolumn dla źródła danych BPS

 

Obieg „Zamówienia”:

Obieg zamówienia wykorzystuje dane udostępnione przez oba obiegi słownikowe.

Z obiegu „Rodzaje produktu” użytkownik wybiera „Rodzaj produktu”, a następnie system mapuje odpowiadające mu pole „Maksymalna wielkość zamówienia”.

Z kolei towary z obiegu „Produkty” wskazywane są przez użytkownika na liście pozycji. Dodatkowo zostają one zawężone, tak by „Typ” = „Rodzaj produktu”. Oprócz tego mapowana jest „Wartość jednostkowa” i walidacja sprawdza czy „Rzeczywista wielkość zamówienia” < „Maksymalna wielkość zamówienia”.

Widoczny po prawej stronie kolumny „Nazwa” przycisk  , służy do błyskawicznego przeniesienia się do elementu obiegu, z którego pobierana jest dana wartość.

 

Rys. 8 Obieg słownikowy „Zamówienia” na kroku „Rejestracja”

 

Przykładowa witryna:

Na przykładowej witrynie umieszczono WebParty umożliwiające startowanie obiegów oraz zarządzanie istniejącymi. Niestety na raporcie SWE nie ma możliwości przedstawienia elementów znajdujących się na liście pozycji. W związku z tym dla obiegu „Rodzaje produktów” udostępniono jedynie ID wraz z linkiem do obiegu.

Rys. 9 Przykładowa witryna procesu

 

Listy SharePoint:

Poniżej zamieszczono „Rodzaje produktów” i „Produkty” w formie list SharePoint. Warto zwrócić uwagę, że nie dają one możliwości wykorzystania zaawansowanych walidacji, a językiem służącym do ich zawężania jest CAML.

 


Rys. 10 Lista SharePoint SPS_RODZAJE_PRODUKTÓW w trybie odczytu

 

 


Rys. 11 Lista SharePoint SPS_PRODUKTY w trybie edycji

Wady i zalety obiegów słownikowych:

Obiegi słownikowe ujawniają swój potencjał w przypadku wykorzystywania większej ilości danych. Ich prędkość działania przekracza to co można osiągnąć za pomocą list SharePoint, gdyż informacje pobierane są prosto z bazy danych WEBCON.

Administrator nie musi obawiać się utraty danych związanej ze zmianą wersji słownika, gdyż w każdym momencie posiada dostęp do historii obiegu.

Technika ta jest bardzo elastyczna. W zasadzie każdy obieg może posłużyć jako słownikowy, jeżeli zajdzie potrzeba odwołania się do jego atrybutów. Co więcej bardzo łatwo można zawęzić się do rodzajów formularza, kroku czy też wartości danego atrybutu.

W obiegach słownikowych mogą być wykorzystywane różne walidacje, uniemożliwiające wpisanie błędnych danych. Z kolei dane wykorzystywane w innych obiegach, nie muszą być bezpośrednio wpisywane przez użytkownika ale np. być wynikiem pewnych procedur, wynikających z logiki biznesowej.

Największą wadą obu typów obiegów słownikowych jest szybkość ich edycji. W typie 1. opartym o listę pozycji, pojawia się problem z wydajnością formularza przy dużej liczbie wierszy (>100) i edytowalnych kolumnach (>5).

Z kolei w 2. rodzaju obiegu słownikowego, użytkownik musi znaleźć niezależnie każdy element, otworzyć go, zmienić wartość i przejść ścieżką. Przy modyfikacji dużych zbiorów danych, brak możliwości edycji z poziomu jednej strony, powoduje dużą stratę czasu.

Słabe punkty obiegów słownikowych stanowią zalety List SharePoint. Listy są bardzo proste w edycji. Wartości można kopiować bezpośrednio z arkusza Excel lub zaimportować. Posiadają one znaczną liczbę udogodnień takich jak sortowanie i grupowanie, bez konieczności dodatkowej konfiguracji. Oprócz tego są stronicowane, dzięki czemu nie ma problemu z wydajnością edycji.

Z drugiej strony są one znacznie wolniej przetwarzane przez WEBCON BPS, a w celu połączenia ich z tabelami SQL, konieczne jest wykonanie synchronizacji do SQL.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *