How to Monitor Asynchronous System Connectivity

Let's create a system cooperation monitoring application by combining Events of Message Start / Throwing Message Intermediate / Catching Message Intermediate.

Hi, there!

I heard from some of my customers that they are advancing the automation of their work using Questetra.
It has various features for automatic processing such as Google Drive collaboration, automatic PDF generation Step, etc.
We would be pleased if you use it actively and test it out.

There are many cases where automatic cooperation with the external systems is done in the context of automation.
(From the point of view of Questetra,) there are various types of connections when linking to external systems.

There are many cases of cooperation between systems using the Throwing Message Intermediate Event (HTTP).
Among them, there are two types that are:

* (Synchronous collaboration type) Receive linkage result in http response from external system
* (Asynchronous collaboration type) Receive linkage result by accessed from external system using Catching Message Intermediate Event

Many are “Synchronous collaboration type”, but there are cases where “Asynchronous collaboration type” is adopted depending on circumstances such as the processing time of the external system.

In “Synchronous collaboration type”, it can be said cooperation errors are relatively easy to detect. (You can judge by http response code.)
In “Asynchronous collaboration type”, if the initial communication (Questetra → external system) can be executed normally, at the next communication (external system → Questetra) an error cannot be detected unless it accesses Questetra.
Depending on the situation of the external system (and the network condition etc.), Questetra just waits.
If there is no access from the external system for a certain period of time, it is necessary to have an error handling mechanism to detect an error and notify it.

I would like to introduce the above mentioned method since I thought that there might be a demand for it as I have received inquiries in the past and one the other day.

Implementation Outline (Cooperation of an App for external system cooperation and an App for monitoring access from external systems)

It is done using two separate Apps, an App that links to an external system and an App (an Alert App) that monitors access from external systems.
<App linking to an external system>

1. Launch an Alert App concurrently with an App that waits for an external system Catching Message Intermediate Event
2. Access to the Alert App to terminate it when there is access to the Catching Message Intermediate Event from the external system

<App monitoring access from the external system (Alert App)>

1. App Started by receiving the Process ID from the App to link to the external system (the launch source)
2. Concurrently execute the flows to Terminate the Alert App itself and Sending an alert.
3. In the flow for terminating the Alert App itself, upon receiving an access from the App linked to an external system, it terminates itself.
4. In the flow of Sending an alert, (a) set the alert transmission time, (b) pass it to the Timer Intermediate Event, (c) send the alert.
* Loop (a) to (c) unconditionally

<Connection outline>
connection outline

I describe its operation on the following scenario.

1. Receive an alert.
2. Check the status of the external system.
3. Confirming the situation, access again from the external system or manually edit the connection data, and then forcibly terminate the Catching Message Intermediate Event.

Implementation details

I will explain the points regarding the connection outline.

About <App that monitors access from the external system (Alert App)>

1. App Started by receiving the Process ID from the App to link to the external system (the launch source)

it will be possible to set it to retrieve the Process ID of the “started Alert App” as shown in the following figure.

<Setting for retrieving Process ID>
Setting for retrieving Process ID

It is achieved by setting it to save the Response in Throwing Message Intermediate Event (HTTP) which accesses to the Message Start Event on the Alert App.
(To save the Response, it must be set as a String type Data Item (multiple lines))

About <App to link to external system>

2. Access to the Alert App to terminate it when there is access to the Catching Message Intermediate Event from the external system

<Setting for accessing to Catching Event for termination in Alert App>
Setting for accessing to Catching Event for termination in Alert App

It is achieved by accessing with setting the Process ID which retrieved at aforementioned <Setting for retrieving Process ID>, into processInstanceId parameter in Throwing Message Intermediate Event for terminating Alert App.

About <App that monitors access from the external system (Alert App)>

4. In the flow of Sending an alert, (a) set the alert transmission time, (b) pass it to the Timer Intermediate Event, (c) send the alert.
* Loop (a) to (c) unconditionally

<Setting of unconditional loop>
Setting of unconditional loop

It is achieved with the setting of unconditional looping to the auto-step “(a) set the alert transmission time”.

Afterwords

This is general-purpose “Alert application”, so it can be called from various Apps that are performing asynchronous type external system linkage.
The main idea in this method is “retrieving the Process ID from the Response of Message Start Event (HTTP)“.

By doing this, the App that has accessed the Message Start Event can take control of the Catching Message Intermediate Event of the access destination App.

Various patterns of App-to-App communication become possible by combining Message Start Events (HTTP), Throwing Message Intermediate Events (HTTP), and Catching Message Intermediate Events,
I hope you use it in various ways referring to the manual.

Auto Start Triggered by HTTP Request
By placing [Message Start Event (HTTP)] which is a mechanism of HTTP Start at the top, a new issue that takes over request data will be automatically started every time it receives an HTTP request. For example, you can build inter-system collaboration, such as launching a “Payment Reminder process” from the central system easily.

https://www.questetra.com/tour/m2/m221/

Standing by HTTP Request
By placing [Catching Message Intermediate Event (HTTP)], a Stand-by event, in the middle of the flow diagram, you can let each Issue stay on the Step standing by for HTTP requests. The external program sends a Request on specifying the Issue ID and Id on the Step (event). The external program makes a request specifying the issue ID which is standing by and the place in it.

https://www.questetra.com/tour/m2/m226/

Auto Sending of HTTP Request with Business data Inserted
By placing [Throwing Message Intermediate Event (HTTP)], the HTTP request event, an HTTP request will be sent at arriving of the instance. It is also possible to embed the business data that has been entered in the upstream processes into the request.

https://www.questetra.com/tour/m2/m225/

2017-04-05

About Masato Furukubo

Questetra, Inc. Sales Department
View all posts by Masato Furukubo

Recommendations
Prev article - 99. Miscellaneous Collaborating Various Web Service/Device with Cloud-based Workflow Easily
Next article - 99. Miscellaneous The Company's Teleworking Environment and my Job as a PTA President
Another article - Masato Furukubo Trouble-free! How to Perform an Options-XML Update?

Archive

 RSS