Budujemy workflow w Oracle Apex
Do czego potrzebny nam "przepływ pracy" w aplikacji?
Zdecydowana większość aplikacji biznesowych ma jakiś "wokflow". W każdym biznesie grupa ludzi wykonuje swoją pracę by „dostarczyć wartość”. Ale nie robimy wszystkiego wspólnie i rozbijamy zadanie na aktywności ponieważ się specjalizujemy i realizujemy zadania według umiejętności - roli. Wykonujemy swoją pracę i przekazujemy ją do następnej osoby – niczym taśma produkcyjna. Te aktywności wykonywane są w ramach procesu ktory działa wg. szablonu - "wokflow". Ma on swoje etapy, taski, statusy.
Oracle Apex nie posiada gotowego modułu do budowania "przepływu pracy" jak byśmy powiedzieli w języku polskim. Jeślibyśmy chcieli zbudować np. proces akceptacji, musimy tworzyć funkcje lub procedury w językach dostępnych w Apex (JavaScript, PL/SQL). Napisanie takiego kodu jest problematyczne. Największym jednak wyzwaniem jest zarządzanie zmianą. Wszyscy wiemy jak "biznes" zmienia założenia do aplikacji - zaczyna się do "takiego małego czegoś do takiego czegoś" a ewoluuje w całkiem duży, skomplikowany system. Więc workflow który służy nam np. do akceptacji faktur z jednego poziomu rozrasta się do kilku, powstają kolejne warunki biznesowe i wyjątki (np. przepływ zależny od rodzaju faktury, od sumy faktury, od kategorii dostawcy/klienta).
Camunda - polaczenie procesu z zewnetrznym API (REST)
Najczęściej spotykanym scenariuszem odczytu tasków i uruchamianiem aktywności w zewnątrznych systemach jest budowanie 'listy tasków' na zewnątrz Camundy. Camunda zajmuje się tylko przesyłaniem informacji a rolą zewnętrznych systemów jest odpowiednie reagowanie w zależności od otrzymanego sygnału (czytaj więcej). Czasami jednak chcemy Camundzie zlecić pracę połączenia się z zewnątrznym API, np. serwisem REST by otrzymać lub przekazać dane. Camunda oferuje taką możliwość z wykorzystaniem "service task" i konektora "http-connector".
Poniżej przedstawiamy tutorial jak zbudować diagram BPM, konektor i dokonać właściwych ustawień by proces Camundy łączył się z API.
Budujemy diagram procesu
Ten tutorial bazuje na przykładzie REST Service Task opublikowanym przez Camunde na Github. Z tamtejszego repozytorium możesz pobrać pliki użyte w tym przykładzie. Gotowy diagram to plik invokeRestService.bpmn. Otwórz go w Camunda Modeler.
Grafowe bazy danych - jak naprawdę mogę ich użyć w realnym świecie?
Ostatnio dużo słyszymy o grafowych bazach danych. I choć ten typ bazy danych nie jest nowy, przykłady użycia są ciąle te same. Najczęściej są to artykuły- wypełniacze potrzebne do promocji treści wiec nie pisane przez osoby które naprawdę używają grafowych baz danych.
W tym artykule chcemy podzielić się z Wami przykładami użycia w realnym świecie, w firmach dużych i całkiem małych. Gdzieś na końcu powiemy że takie bazy danych są fantastyczne w podpowiadaniu kto jeszcze jest przyjacielem Klary i który bank jest zamieszany w pranie pieniedzy ale, nie oszukujmy się, wiekszość z Was nigdy nie będzie mieć takich potrzeb. Jak najbardziej będzie jednak chcieli się dowiedzieć które produkty zarekomendować klientom by zwiększyć sprzedaż, dotrzeć szybko do informacji, nie zgubić orientacji w aktywnościach klientów, dokonać obliczeń zdecydowanie szybciej niż to robisz teraz.
Obliczenia
Choć praktycznie wszystko co jest możliwe do zrobienia w grafowej bazie danych, jest także możliwe do wykonania w relacyjnej, grafowe robią wiele takich obliczeń zdecydowanie szybciej. Np. wyobraź sobie zapytanie MySQL które oblicza percentyl lub medianę cen produktów. Możesz? A teraz napisz takie zapytanie i zmierz ile czasu czekasz na jego wykonanie. Nawet nie musisz - nie będą to milisekundy. A w grafowej bazie danych, np Neo4j, będą. Tak więc jeśli np. budujesz funkcję która w programie wyświetli sugerowaną cenę przy tworzeniu oferty, użyj raczej grafowej bazy danych niż relacyjnej. Nie chodzi tu zresztą tylko o czas dostarczenia danych. Same zapytanie będzie prostsze, a baza posiada już gotowe funkcje. Czego nie możesz powiedzieć o wielu relacyjnych bazach danych - by np. wyliczyć percentyle trzeba wykonać wiele linijek kodu i poskładać rezultaty tych obliczeń.
Camunda BPM - aktywacja HTTP Basic Authentication
Interfejs API REST Camundy posiada uwierzytelnienie podstawowe HTTP (HTTP Basic Authentication). Domyślnie ta autentykacja jest wyłączona, ale można ją aktywować, dodając filtr serwletu Tomcat w następujący sposób:
<!-- Http Basic Authentication Filter -->
<filter>
<filter-name>camunda-auth</filter-name>
<filter-class>
org.camunda.bpm.engine.rest.security.auth.ProcessEngineAuthenticationFilter
</filter-class>
<async-supported>true</async-supported>
<init-param>
<param-name>authentication-provider</param-name>
<param-value>org.camunda.bpm.engine.rest.security.auth.impl.HttpBasicAuthenticationProvider</param-value>
</init-param>
<init-param>
<param-name>rest-url-pattern-prefix</param-name>
<param-value></param-value>
</init-param>
</filter>
Ten filtr znajduje się już w pliku 'camunda-bpm-tomcat-X.XX.X\server\apache-tomcat-X.X.XX\webapps\engine-rest\WEB-INF\web.xml', wystarczy go odkomentować w tym pliku.