Walking through the search in Habrahabr, we managed to find not so much information on, I must say, not very common language BPEL (Business Process Execution Language). Generally speaking, BPEL is an XML-based language that allows you to describe the logic of business processes through the use of web services.
I don’t know very much about the implementation of engines that allow creating processes using this language. In particular, we can mention Oracle BPEL Process Manager and the product that will be discussed later - Serena Business Manager (SBM). SBM allows you to quickly create web applications that automate a process. In the process model (workflow), it is possible to call an external web service at the time of state change. And if you need to implement some logic and a single call is not enough? This is where a procedure written in the BPEL language and executed by the same BPM platform comes in handy.
I will not dwell in more detail on the language itself; on the net one can find enough information on this topic, for example,
here . I will describe the implementation of a specific task.
The task was set as follows - to develop the functionality of copying business entities (in my process - TD Links), but not just like that, but with a preliminary survey of a third-party web service. This service (bridge) has a method that accepts some attributes of a TD Link object as input. The bridge then polls the third-party system and, in response, reports whether an object with such attributes can exist in our system. As he does it does not interest me, the bridge for me is a "black box".
')
In addition, I needed another web service that implements the functions of working with business entities in our system (reading, creating, etc.). I will call it AppServices.
The list of steps from which a process can be built looks like this:

The most important ones are:
- Service. Allows you to issue an appeal to the web service.
- Service. Allows you to issue an appeal to the web service.
- Calculate. Used to work with variables, data mapping, treatments, etc.
- Scope, Compensate and Throw. Steps to handle errors.
The remaining steps implement the basic functions - cycles and conditions.
The final worflow looks like this:

Since TD Links objects exist in the system not on their own, but in connection with other objects (such as Stagings), I first needed to find the Stagings I needed in the system.
AppServices has a method for sampling using a SQL query. The SQL query is assembled directly as a string:

Yes, an important digression. The engine allows you to define variables that will be used during the process, which I used in this case:

Having formed a SQL query, you can proceed to calling the required method by performing data mapping:

For mapping, both variables and the results of the previous steps of the process (for example, the result of starting a web service) can be used.
After a similar way (via SQL query), the selection of objects for copying is done - TD Links and the start of the cycle.
And, finally, the stage of polling the external web service is also configured through the element of the type “Service”.
The last step is to create a copy of the TD Link object, while preserving the results received from the bridge (including an error message, if any).
Naturally, there is no getting away from debugging, and the development tool has quite good possibilities for this. In particular, you can look at the result of each step taken separately and see which of them something went wrong.

What can be said in the end. From the advantages of the proposed implementation, the following points can be noted:
- Ease of development. In essence, no coding was required.
- Rapidity. You can create and debug a small process in a couple of hours. At the same time, I did not have to go beyond the standard SBM Composer development environment.
- Convenience debugging. All logs in one place; you can see at what step the failure occurred. In addition, there is a single log where errors are reset during the operation of all running processes.
- Controlled ease of change. Updating web service descriptions, renaming variables, making changes to data mapping is all very easy. And at the same time, my changes are recorded in the built-in version control system - at any time you can roll back to the previous working version.
- Ability to run using an external event. In my case, the process is initiated by the user by pressing a button on the user interface, but the initiator of the process may be some external event.
There are also disadvantages, of course:
- The problematic implementation of complex algorithms. However, the workflow creation tool is limited in its capabilities. Complicated data processing is still better done in its own web service.
- Difficulties with data mapping. Sometimes you have to use additional process steps for data mapping, which makes the process somewhat more difficult.
- Restrictions on web services. Only SOAP and REST architectures are supported (via a special wrapper), there are also a number of limitations imposed on the WSDL file.
Thanks to everyone who read the post to the end. We will be happy to answer your questions in the comments.