Zostaw swoje dane kontaktowe, a my wyślemy Ci nasz przegląd e-mailem
Wyrażam zgodę na przetwarzanie moich danych osobowych w celu przesyłania spersonalizowanych materiałów marketingowych zgodnie z Regulaminem. Politykę Prywatności. Potwierdzając zgłoszenie, użytkownik wyraża zgodę na otrzymywanie materiałów marketingowych
Thank you!

The form has been successfully submitted.
Please find further information in your mailbox.

Innowise jest międzynarodową firmą tworzącą oprogramowanie w pełnym cyklu założona w 2007 roku. Jesteśmy zespołem ponad 2000+ specjalistów IT tworzących oprogramowanie dla innych profesjonalistów na całym świecie. profesjonalistów na całym świecie.
O nas
Innowise jest międzynarodową firmą tworzącą oprogramowanie w pełnym cyklu założona w 2007 roku. Jesteśmy zespołem ponad 2000+ specjalistów IT tworzących oprogramowanie dla innych profesjonalistów na całym świecie. profesjonalistów na całym świecie.

Automatyzacja procesów biznesowych z Camunda: bezawaryjna implementacja schematów BPM

In today’s digitally driven world, maintaining a competitive edge requires streamlined and efficient business processes. Automation stands out as a key solution to achieving this. According to Statista, the business process management (BPM) market ma osiągnąć wartość 14,4 miliarda dolarów amerykańskich do 2025 roku. Rosnąca popularność i zapotrzebowanie na narzędzia BPM, takie jak Camunda, znana ze swojej elastyczności i skalowalności, świadczy o tym trendzie. W miarę jak firmy szukają niezawodnych narzędzi do optymalizacji swoich działań, Camunda wyłania się na czoło, torując drogę dla innowacyjnych, bezawaryjnych rozwiązań automatyzacyjnych w branży.

Czym jest Camunda?

Mówiąc najprościej, Camunda to platforma open-source do automatyzacji przepływu pracy i decyzji, która łączy użytkowników biznesowych i twórców oprogramowania. Dzięki solidnemu zestawowi narzędzi i funkcji Camunda oferuje sposoby projektowania, wdrażania i optymalizacji przepływów pracy BPMN (Business Process Model and Notation), dzięki czemu operacje biznesowe są płynniejsze i bardziej przejrzyste.

Camunda, Spring Boot i BPMN: zrozumienie pojęć

Trzy kluczowe elementy zrewolucjonizowały zarządzanie procesami biznesowymi: Camunda, Spring Boot i BPMN. Każdy z nich wypracował swoje miejsce, oferując unikalne funkcjonalności, które adresują różne aspekty zarządzania procesami. Jednak w połączeniu stają się one niepowstrzymaną siłą, zdolną do zrewolucjonizowania cyfrowych operacji przedsiębiorstw.

Camunda: This isn’t just another tool in the vast BPM toolbox; it’s a standout. As a robust open-source platform, Camunda specializes in workflow and decision automation. Its primary objective? To seamlessly fuse the worlds of business strategists and software developers. By doing so, it ensures that the conceptualization, design, and implementation of business processes are efficient, transparent, and cohesive.

Spring Boot: Spring Boot wykorzystuje mocne strony frameworka Spring i podnosi je na wyższy poziom. Oferując usprawnioną metodę tworzenia samodzielnych aplikacji Java stał się ulubieńcem programistów, którzy chcą zminimalizować kod szablonowy i skupić się bezpośrednio na specyficznych funkcjonalnościach projektu. Jego siła tkwi w elastyczności i podejściu konwencji ponad konfiguracją, które propaguje inteligentne ustawienia domyślne. To podejście pozwala programistom na szybsze budowanie skalowalnych aplikacji, zapewniając terminową dostawę i spójną wydajność.

BPMN: Gdybyśmy mieli spersonifikować BPMN, byłby to elokwentny lingwista świata biznesu. Jako uznany na całym świecie standard, BPMN zapewnia wizualne słownictwo do tworzenia procesów biznesowych, dzięki czemu są one łatwo zrozumiałe dla szerokiego grona interesariuszy. Ten uniwersalny język zapewnia, że techniczne niuanse procesu są możliwe do rozszyfrowania zarówno przez obeznanego z technologią programistę, jak i stratega biznesowego, sprzyjając dialogowi opartemu na współpracy i podejmowaniu bardziej świadomych decyzji.

The synergy of Camunda’s automation capabilities, Spring Boot’s development ease, and BPMN’s standardized notation presents businesses with a dynamic trifecta. Together, they ensure that BPM schemes transition from mere theoretical constructs on paper to actionable, real-world implementations. The end goal? To cultivate business processes that are agile, resilient, and perfectly aligned with the evolving demands of the contemporary digital enterprise landscape.

Podstawowe komponenty BPMN

Dla tych, którzy nie znają BPMN, zrozumienie jego podstawowych komponentów jest kluczowe. Te elementy stanowią fundament każdego diagramu BPMN.

Wydarzenia

Oznaczają one coś, co dzieje się podczas procesu. Zdarzenia mogą rozpoczynać, przerywać lub kończyć przepływ i często są reprezentowane jako okręgi.

Bramki

Bramki obsługują podejmowanie decyzji w ramach procesu. W oparciu o warunki kontrolują przepływ procesu, zwykle przedstawianego jako diamenty.

Działania

Działania reprezentują wykonywaną pracę. Mogą to być zadania lub podprocesy i są wyświetlane jako zaokrąglone prostokąty.

Łączenie obiektów

Elementy te, w tym przepływy sekwencji, przepływy komunikatów i asocjacje, ilustrują sekwencję procesów i przepływ komunikatów.

Swimlanes

Klasyfikują elementy BPMN według ról (np. menedżer, księgowy) lub systemów (np. system ERP).

Artefakty

Oferują one dodatkowe informacje o procesie. Typowe artefakty obejmują obiekty danych, grupy i adnotacje.

Zalety i wady Camunda

As with any technological solution, Camunda brings a mix of advantages and challenges. Here’s a comprehensive look into its pros and cons.

Zalety:

  • Elastyczna i łatwa integracja z aplikacjami Java poprzez Spring Boot.
  • Intuicyjny interfejs modelera dla BPMN 2.0.
  • Zapewnia szczegółową analizę metryk procesów.

Wady:

  • Może mieć bardziej stromą krzywą uczenia się dla użytkowników nietechnicznych.
  • It’s a strong starting point, but think of it as just the base – while Camunda is a powerful workflow engine, you’ll still need further software development.

Usprawnienie przeciążonych diagramów BPMN

Surowa rzeczywistość

Camunda została zaprojektowana tak, aby programiści i analitycy mówili tym samym językiem, ale często rzeczywistość interweniuje. 

Mikroserwisy zawodzą, użytkownicy wprowadzają nieprawidłowe dane, wszystko może się zdarzyć. W takim przypadku piękny diagram analityczny zaczyna być upiększany różnymi modułami obsługi błędów, rejestratorami i alternatywnymi ścieżkami. Analityk projektuje piękny, zwięzły i zrozumiały schemat. Ma on kilku delegatów i zapewnia logiczne ścieżki dla przepływu procesu w różnych okolicznościach. Tak wygląda tymczasowy schemat, gdy trafia w ręce dewelopera:

However, there are downsides. Such a scheme might contain a brief task description, like “check the client”, which implies several stages, decision-making based on each outcome, and compiling the derived decisions into a single result, possibly with the subsequent transfer of this result to external systems.

It’s clear that at this point, error handlers, loggers, and technical service elements appear on the diagram or in the code. This way, one “analytical” task in the Java implementation becomes voluminous and complex, or the number of steps on the scheme increases, each being accompanied by handlers and alternative pathways. As a result, the scheme quickly becomes convoluted, difficult for further support and modification, and adding new functionality might entail restructuring a vast area of both the scheme and the delegate code. In essence, it contains a massive number of identical elements.

Here’s how the previous scheme might look in a real deployment: 

Oczywiście schemat został rozszerzony i stał się bardziej kłopotliwy. Są jednak zalety: wszystkie zadania stały się atomowe i pojawiły się gałęzie zachowań w przypadku błędów.

Zrozumienie problemu

Jeśli spróbujemy oddzielić i enkapsulować schemat oraz logikę biznesową kodu Java, możemy zrobić następujące rzeczy:

  • Uniknąć powielania podobnych elementów w schemacie.
  • Użyć uniwersalnej i wielokrotnego użytku implementacji delegatów w kodzie Java.
  • Zoptymalizować i przyspieszyć przepływ procesu.
  • Simplify the handling of technical errors and establish a process behavior logic when they arise – almost without the involvement of Java code. This will significantly simplify debugging and manual analysis of failed processes that are in an incident.
  • Drastically reduce the number of processes that “fall” into incidents when technical exceptions arise.
  • Stworzyć solidną podstawę do dalszego rozwoju.

Aby ułatwić pracę z produktem, lepiej zdekomponować schemat na zadania atomowe, zmniejszyć całkowitą liczbę elementów schematu, zmniejszyć liczbę obsługiwanych usług, zredukować objętość kodu Java w każdym delegacie oraz ponownie wykorzystywać uniwersalnych delegatów, prowadząc natychmiastowy refaktoring w razie potrzeby. Wszystko to automatycznie implikuje pisanie testów jednostkowych dla wszystkich delegatów i głównych ścieżek procesu.

Rozkład i atomizacja

If you look closely at the process application and analyze its nodes, you can see many repetitive functions: queries to external systems, logging, error handling, sending callbacks, etc. In other words, one needs to critically assess the process application, identify objects from it that can be easily encapsulated… But into what? Into Java code? No, that would be illogical, because in this case, the scheme would be closely tied to its Java implementation. In this situation, it makes sense to consider process pools.

A process pool is a scheme of a separate process that will have its own context. It is noteworthy that it’s convenient to extract atomic pieces of functionality from the main process into such pools, as well as all repetitive moments: sending notifications, requests to external systems, etc.

Może istnieć wiele pul procesów i logiczne byłoby pogrupowanie ich tematycznie. Na przykład zapytania do konkretnego mikroserwisu, alertowanie, wysyłanie różnych powiadomień. Interakcje między takimi pulami można łatwo skonfigurować za pomocą komunikatów Camunda. Za każdym razem, gdy taka pula jest wywoływana w silniku Camunda, przekazywana jest pewna wiadomość zawierająca nagłówek warunkowy i numer procesu nadrzędnego do zwrócenia odpowiedzi, a także zestaw danych niezbędnych do działania tej konkretnej małej puli.

Tutaj widzimy, jak główny proces (na dole) wysyła wiadomość, do której subskrybowany jest starter innej puli. Po wystąpieniu zdarzenia druga pula uruchamia nową instancję procesu, wysyła żądanie i wysyła odpowiedź z powrotem do głównego procesu, po czym pomyślnie kończy działanie. W tym czasie proces główny oczekuje na zdarzenie odpowiedzi z puli zewnętrznej, do której wysłał żądanie. Gdy wiadomość nadejdzie, proces jest kontynuowany. Jeśli nie ma odpowiedzi w określonym przedziale czasu, proces rozumie, że obliczenia zewnętrzne są niedostępne lub nie powiodły się, i kończy działanie.

Co to oferuje:

  • Możliwość ponownego wykorzystania kodu. Jeśli zachodzi potrzeba wywołania tego samego kodu kilka razy w różnych warunkach w całym procesie, można po prostu utworzyć określone komunikaty i wywołać odpowiednie pule procesów atomowych;
  • Encapsulation of the software implementation scheme from its business representation. It doesn’t matter how the main scheme will be redesigned, or which paths the process will take. All interactions have already been moved to separate minor processes, which gives complete flexibility: just form a request and wait for a response.
  • Liczba i prawdopodobieństwo awarii głównego procesu zostały znacznie zmniejszone. Przed takim podziałem proces znajdował się w niepewności 4 stanów:
  •  Odpowiedź nadeszła.
  •  The response didn’t come because the external microservice crashed.
  •  The response didn’t come because the main process crashed while sending the request.
  •  The response didn’t come because a timeout was exceeded.

With this division, the process is always in a strictly single state: the response either came, or the process waited and ended. For business, it matters how exactly the process ended: whether it was an error or not. But this will be a proper conclusion, not an incident. This is important because a process not stuck in an incident doesn’t “consume” resources, and errors can be easily logged, statistics gathered, alerts set up, and analyzed.

  • It no longer matters what happens with the minor processes. They can do whatever they want: crash, run… Only the result is important: the response from the external resource. And even then, not always, because the main process shouldn’t guarantee the functionality of external systems. For instance, there might be no sense in the process waiting for a response from the notification microservice since there could be no response at all. 
  • Złożoność głównego procesu jest znacznie zmniejszona. Złożona logika może być dystrybuowana pomiędzy oddzielnymi małymi pulami, które są łatwiejsze do debugowania. Na przykład, weryfikacja klienta może wyglądać mniej więcej tak:

Here, we can see that in the external pool, multiple tasks are called simultaneously. Let’s delve deeper into this point.

Zrównoleglenie obliczeń procesowych

Camunda allows for the concurrent execution of branches of process computations. For this purpose, there’s a special gateway called the Parallel Gateway, using which the flow can be divided into parallels or to merge multiple parallel computations into one stream. It’s clear that to accelerate the flow of a process, it would be advantageous to delegate certain tasks to parallel threads. If the logic is independent, it can be executed in parallel, for example, making simultaneous requests to external systems and waiting for responses from all of them at once:

Each time at such a gateway, there will be overhead costs associated with creating new threads for task division and merging the results. One may encounter various locking exceptions, and, of course, it’s not always necessary or justified to always act this way, especially without testing, but the benefits are evident.

With sequential execution, the total execution time equals the sum of the execution times of each operation. In contrast, with parallel execution, it equates to the execution time of the longest operation. Given the conditions of non-instant responses from external sources, retries, and failures, this difference is far from insignificant. Another undeniable advantage is the form of “free retries”, i.e., while the longest request is being executed, the other tasks hypothetically have the opportunity to fail several times and attempt to redo their actions without impacting the overall task execution time.

Wyjątki i próby powtórzenia

Broke? It happens. The out-of-the-box version of Camunda has the capability to retry a failed transaction. By “transaction”, we mean Camunda’s internal mechanism for executing delegate code. The start of a transaction can be, for example, the “async before” or “async after” marker on a task in the modeler. When the engine encounters this marker, it commits its information to the database and starts a new asynchronous thread. This is important. To delve deeper, by “transaction”, we mean the execution section between the calls to the .complete() method in TaskService, followed by recording information to the database. These transactions, like others, are atomic.

Gdy wystąpi wyjątek techniczny, tj. jakikolwiek błąd niebiznesowy, na przykład dzielenie przez zero i zapomnienie o sprawdzeniu wartości null, transakcja wykonuje wycofanie i próbuje rozpocząć od nowa. Domyślnie robi to trzy razy z rzędu bez żadnych przerw. Próba ponowienia rozpoczyna się, gdy pojawi się zwykły wyjątek, który w świecie BPMN nazywany jest wyjątkiem technicznym, a nie BpmnError. Pojawiający się BpmnError zatrzymuje proces bez żadnych prób ponowienia. Wyobraź sobie, jak zwiększa to odporność procesu.

It makes sense to maximize this feature. Therefore, on every delegate that requests an external system, these markers are set, specifying the number of retries and the pause between them, and in the delegate code separates logic for when the process should be terminated and when it shouldn’t. It gives full control over the exception handling and retry mechanisms. As a result, the process tries to redo the failed task several times, and only after a series of failures it produces an error.

Perhaps, the biggest challenge is the handling of technical exceptions and BPMN-related errors, as well as designing the logic of their handling for a continuous flow of the process. We’ve already discussed some errors related to handling responses from external sources when talking about dividing into process pools. We’d like to remind you that the very call was encapsulated into a separate mini-process, and the main one either received a response and proceeded further or, due to a timeout, followed the “I didn’t receive a response” route.

Now, let’s look at that very small process:

Do you see the frame? It’s a subprocess. It contains specific tasks and captures errors thrown by internal tasks. Moreover, on such frames, the job executor is capable of creating a job for the timer, which sets the execution time for everything inside the subprocess.

How does it work? The execution flow reaches the subprocess, creates parallel timer processing, and waits either for the completion of what’s inside or, if the timer runs out first, it will follow the timer route. If an exception is thrown during the process, which the subprocess frame captures, the process will stop its execution on the current branch and follow the error branch.

It’s also evident that there’s an option to create response dispatches for critical requests. Note that error capturing works only for BpmnError with a specific code. Therefore, technically, it’s essential to catch any exception and throw a BpmnError with the required code, which works for the ErrorBoundaryEvent.

Error handling in the main process works similarly. From several tasks, logical units are singled out that can be placed in a subprocess frame, with a listener set up for a specific error code. But there are two nuances here. The first is that creating multiple identical branches with error handling, differing only in code, is inconvenient. If the error handling strategy changes or, for example, logging, then many delegates on the scheme would need to be redesigned, which isn’t desirable. Therefore, one might consider looking into event-based subprocesses.

At its core, this is a separate subprocess of the process pool, which starts only when a certain event it’s subscribed to occurs. For instance, if you subscribe such a subprocess to the BpmnError event with a code, say, MyCustomBusinessError, then when this event occurs, the handler will be triggered, and upon its completion, the process will end correctly. Yes, it didn’t end in success, but it ended correctly. In these subprocesses, you can also implement different handling logic for the same event depending on external conditions, for example, optionally notifying about an application error when the process passes a conditional point.

Drugi niuans jest znacznie bardziej skomplikowany. W prawdziwym życiu cykl życia każdego procesu jest prawdopodobnie podzielony na dwa etapy biznesowe: przed generowaniem leadów i po nim. Jeśli błąd wystąpił przed sformatowaniem danych w leada, proces można było prawdopodobnie po prostu zakończyć, powiadamiając o napotkanych trudnościach. Po wygenerowaniu leada nie jest to już możliwe.

We also don’t recommend ending processes if legal obligations arise during the process, for instance, if a contract is signed. How do we handle such errors? Some technical errors, like those associated with the unavailability of external services, are handled by automatic retries within a pre-agreed timeout. But what if the process crashed, retries have passed, but the hypothetical external microservice is still down? 

Optymalizacja ręczna

Dochodzimy do koncepcji ręcznego rozwiązywania lub, znanej również jako, kompensacji.

How does it work? Any errors are caught, delegates are given the opportunity to retry if necessary, and if luck still doesn’t favor them, the process goes into an error state, but with the appropriate code, for instance, COMPENSATION_ERROR. This code is caught by another event-based subprocess, which processes, logs, notifies, and importantly, cannot fail unexpectedly. Only where it’s designed to, it throws an uncatchable technical exception and crashes into an incident.

Why do it this way? For monitoring, you can use EXCAMAD – an external admin panel for Camunda, an analogue to Cockpit, with powerful features. It highlights processes in incidents in red. These processes can be modified or restarted from the desired point. For instance, you can place the necessary variable value in the context and restart the process from the point right after the problematic one. This is convenient, straightforward, and allows for manual problem resolution with minimal effort.

Automatyzacja procesów biznesowych z Camunda: rzeczywiste przykłady

Renowned for its open-source platform and user-friendly interface, Camunda has empowered numerous enterprises to optimize their workflows. Let’s explore a few real-life examples.

Bankowość i finanse

Münchener Hypothekenbank eG, niezależny bank hipoteczny, przeszedł na korzystanie z silnika przepływów pracy Camunda, aby poprawić i zautomatyzować wewnętrzne procesy, w szczególności obsługę korespondencji i koordynację wniosków o kredyty między działami. Wcześniej ich system był sztywny, brakowało mu elastyczności, co prowadziło do złożoności, które zwiększały wskaźniki błędów.

Przechodząc na architekturę mikrousług opartą na Javie, firma wybrała Camundę na podstawie wewnętrznych rekomendacji i ściśle współpracowała z WDW Consulting Group. Niektóre korzyści uzyskane natychmiast dzięki Camunda były gotowymi funkcjami, podczas gdy inne wymagały dalszego rozwoju. To przejście zaowocowało scentralizowaną listą zadań używaną przez wszystkich pracowników i zapewniło elastyczność w utrzymywaniu poszczególnych procesów bez wpływu na inne.

Najbardziej zauważalnym rezultatem była znaczna poprawa szybkości przetwarzania wniosków kredytowych. Jest to korzystne zarówno dla pracowników, jak i klientów końcowych. Jako świadectwo sukcesu, inne działy chcą teraz przyjąć Camundę, a bank zatrudnił nawet więcej programistów, aby dalej wspierać jej wdrożenie.

Ubezpieczenia

SV Informatik, spółka zależna SV SparkassenVersicherung, specjalizuje się w dostosowanych rozwiązaniach IT dla firm ubezpieczeniowych. Wdrożyli Camundę, aby zautomatyzować różne procesy w działach, co doprowadziło do znacznych oszczędności czasowych i poprawy czasów reakcji na potrzeby klientów. Firma przyjęła Camundę w 2018 roku jako rozwiązanie w poszukiwaniu skutecznego narzędzia do modelowania procesów biznesowych, koncentrując się na poprawie procesów i zwiększeniu współpracy między IT a innymi działami.

Od momentu wdrożenia, Camunda zautomatyzowała takie zadania jak anulowanie polisy ubezpieczenia komunikacyjnego i wnioski o wydanie dokumentów polisy. Godnym uwagi osiągnięciem było zautomatyzowane przetwarzanie zgłoszeń szkód burzowych online przez 80%. Okazało się to szczególnie cenne podczas powodzi i burz w Niemczech w 2021 roku. Narzędzia takie jak Camunda Optimize i Camunda Cockpit ułatwiają monitorowanie i optymalizację procesów.

Gościnność

W 2020 roku grupa SV, operating in Germany, Switzerland, and Austria, launched a disruptive digital platform called ‘likeMagic’ with Camunda’s assistance. This platform provided a seamless guest experience, from booking to check-out, with outcomes including a 95% self-check-in/out rate and a 9 out of 10 guest happiness score. The innovation reduced staffing needs and integrated platforms like Airbnb seamlessly. Recognizing its potential, SV Group offered ‘likeMagic’ to other hospitality providers. By 2023, they expanded from 2 to over 30 customers in the DACH region, with plans for a broader European reach and targeting 15,000 rooms by year-end.

Podsumowanie

Camunda’s transformative potential lies not just in its core functionalities but in its ability to redefine business operations at a fundamental level. Combined with Spring Boot, it opens a doorway to seamless integrations and enhanced scalability. Understanding the nuts and bolts of BPMN is paramount to leveraging Camunda’s full potential. As businesses evolve in this digital age, tools like Camunda stand out, offering dynamic solutions that can pivot and adapt to ever-changing needs. It’s not just about automating processes, it’s about innovating workflows, enhancing efficiency, and driving tangible results that make a difference. Embrace the power of Camunda, and let your business soar to new horizons.

Spis treści

Oceń ten artykuł:

4/5

4.8/5 (45 opinii)

Powiązane treści

Blog
Looker vs Power BI - Revolutionizing Industry Small Cover
Blog
Why your project is likely to fail without BA
Blog
Why IT projects fail

Skontaktuj się z nami

    Prosimy o podanie szczegółów projektu, czasu trwania, stosu technologicznego, potrzebnych specjalistów IT i innych istotnych informacji.
    Nagraj wiadomość głosową na temat projekt, który pomoże nam lepiej go zrozumieć
    W razie potrzeby dołącz dodatkowe dokumenty
    Prześlij plik

    Można załączyć maksymalnie 1 plik o łącznej wielkości 2 MB. Ważne pliki: pdf, jpg, jpeg, png

    Informujemy, że po kliknięciu przycisku Wyślij Innowise będzie przetwarzać Twoje dane osobowe zgodnie z naszą Polityką prywatności w celu dostarczenia Ci odpowiednich informacji.

    Co będzie dalej?

    1

    Po otrzymaniu i przetworzeniu Twojego zgłoszenia skontaktujemy się z Tobą wkrótce, aby wyszczególnić potrzeby projektu i podpisać umowę o zachowaniu poufności, aby zapewnić poufność informacji.

    2

    Po przeanalizowaniu wymagań, nasi analitycy i programiści opracowują projekt z zakresem prac, wielkością zespołu, czasem i kosztami szacunki.

    3

    Umówimy się z Tobą na spotkanie, aby omówić ofertę i dojść do porozumienia porozumienia.

    4

    Podpisujemy umowę i rozpoczynamy pracę nad projektem tak szybko, jak to możliwe.

    Спасибо!

    Cобщение отправлено.
    Мы обработаем ваш запрос и свяжемся с вами в кратчайшие сроки.

    Dziękuję!

    Wiadomość została wysłana.
    We’ll process your request and contact you back as soon as possible.

    Dziękuję!

    Wiadomość została wysłana. 

    Przetworzymy Twoją prośbę i skontaktujemy się z Tobą tak szybko, jak to możliwe.

    arrow