• Geeks' Blog

Robotic Process Automation takes IT 20 years back

This all the turmoil and excitement around “RPA” reminds me a situation that I witnessed two decades ago. A company had a process of placing orders for products for resale that was completely manual - some people decided what kind of articles and quantity to order, others typed these orders into the computer system - line by line. They still work like that?

One of the guys who was doing this dull and stupid job decided to simplify his life. The list of items to be ordered was sent to him in an Excel file (someone else had previously done another dummy job). Then it had to be entered into the computer using a Unix terminal. Our hero came up with the idea of writing a macro in Visual Basic that would simulate his daily manual work - read the article number and its quantity from the file and then enter this data in the terminal. Sequence: 'copy', 'paste', 'enter', 'sendKeys' ... Thus, he launched the first "Robotic Automation" without even knowing it.

I have always believed that IT has the best marketing of all industries. Others – hold their beer! Tech companies has always been able to sell the greatest nonsense to rich organizations. We are in 2021 and the overlays for outdated software are sold as "robots".

Więcej…

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).

Więcej…

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.

Więcej…

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ń.

Więcej…

Strona 7 z 21

  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
© 2023
Powered by DataGeeks & Human Intelligence