I need to implement camunda bpmn where 1 of my task is a java delegate task which calls an api.
now the api what it calls is an async api, because of which the bpmn flow moves to next task after calling the async api but i want is that after calling the api the flow shud stop and then some call back happens through some api to camunda server(hosted as spring boot app).
what would be the best way to achieve the above scenario.
Options for asynchronous communication are
A send task/event follow by receive task/event
https://docs.camunda.org/manual/latest/reference/bpmn20/tasks/send-task/
https://docs.camunda.org/manual/latest/reference/bpmn20/tasks/receive-task/
https://docs.camunda.org/manual/latest/reference/bpmn20/events/message-events/
a service task of implementation type external
https://docs.camunda.org/manual/latest/user-guide/process-engine/external-tasks/
Advanced: Implement asynchronous service invocation using a Signallable Activity Behavior
https://github.com/camunda/camunda-bpm-examples/tree/master/servicetask/service-invocation-asynchronous
From this blog post, whcih provides a detailed explanation:
https://blog.camunda.com/post/2013/11/bpmn-service-synchronous-asynchronous/
You can do this to halt the execution for the specified amount of time.
This will halt the execution for the response
Related
Suppose we have a web-service written in python, that does some time-consuming file processing. It definitely should not be run inside the HTTP handler as it takes up to 10 mins to complete. Instead, the processing should be done asynchronously by some sort of workers, and it would be also nice to report the progress of the task execution to display to the user.
Would it be a good idea to setup Google Cloud Tasks with some Cloud Run or Cloud Functions service as a HTTP target to do this work?
Is Google Cloud Tasks suitable for handling this type of async tasks, where the user is sitting and waiting for result?
If not, is there any other options to achieve this with Google Cloud? (or should I use custom task services for this purpose, for instance, celery and redis) It also seems that Cloud Run Jobs features somewhat similar functionality, but there are not any queue systems to manage workers.
GC tasks is simply a tool for queuing tasks. It is a useful tool for ensuring that tasks do run, as it has built in retry mechanisms. How you use that in the context of an application depends on a lot of other detail of the application itself, but it is definitely possible to use it for background/asynchronous processing of tasks.
We use Google Cloud tasks to implement long running processes that report their progress via data store records. Some of these processes run longer than the standard 10 minute timeout, and trigger a new cloud task to complete the processing. We then have a simple lightweight handler that retrieves the status record from data store and reports that to the user. We poll that handler from the client, but you could also implement something like websockets.
GCP can handle Asynchronous tasks, Asynchronous execution is a well-established way to reduce request latency and make your application more responsive.
We can use cloud run or cloud functions for this type of tasks , Because we can increase the time limit upto 30 min in http task handlers in GCP cloud tasks.
For more information refer to this document.
We use Google Cloud tasks to implement long running processes that report their progress via data store records. Some of these processes run longer than the standard 10 minute timeout, and trigger a new cloud task to complete the processing.
I am using Camunda workflows to automate various processes. I have come across a scenario where the process is not moving from a service task. Usually, we call the task/{taskid}/complete to complete the task, but since the process is stuck on a service task, I am not able to complete that task. Can anybody help me find a way to complete the service task?
You are using a service task. That basically means "a machine should do something". The "normal" implementation is to provide code (a java Delegate or a connector endpoint) that is called by the process engine to execute this task.
The alternativ is to use the "external task" pattern. Think of external tasks as "user tasks for computers". So the process waits, tells subscribed clients that a job is to be done and waits for their completion.
I suppose your process uses the second option? (you can check in the modeler under "Implementation"). So completion can be done through the external task API, see docs.
/external-task/{id}/complete
If it is a connector then you likely will see when checking the log that retries have occurred and that the transaction rolled back. After addressing the underlying issue the service task (email) should be sent without explicitly triggering the service task and the following user task (Approval) should be created.
I want to create multiple step functions which can be invoke by parent workflow.
Explanation : I have Parent workflow and i want to invoke more than one step functions from that parent task state whenever i want to invoke, which is depends on a request from API gateway.
Yes - AWS Step Functions supports nested workflows.
It's implemented as a Step Functions service integration in a Task state. The Step Functions service integration supports all three service integration patterns:
Request Response
Run a Job (synchronous invocation)
Wait for a Callback with the Task Token
Running WSO2 EI 6.2.0
I have a simple use case (Sequence) for WSO2 EI ESB:
Extract some parameters from the original request
Call an Async REST API
Extract an Execution ID from the Async Call Payload
Poll Loop another Sync API to check Execution Status based on Execution ID
Halt polling when the Sync API says that the request is completed
Extract some parameters from the last Sync Call
Response
My problem lies on the Poll a Sync API until it returns some parameter saying that the previous Async execution is finnished.
Is there any WSO2 EI Sequence mediator for this sort of Poll Loop?
The ESB mediations (sequences) are not really intended to keep the state and wait for anything. I'd believe it is even intention not having any sort "do/while" loop. We had a project requiring many polling steps and we used a process server to do so. So - with pure mediation it is very difficult to accomplish what are you asking for. Even you may check this one http://bsenduran.blogspot.com/2017/08/while-loop-in-wso2-esb.html
I will propose a few things you could do:
write a custom polling mediator (I really do not advice to do so)
use a process server (requires additional no-so-lightweight server)
use messaging with message processor (send a message to a queue, a message processor will poll, call and send the back to the queue or to response)
In all cases - if a client is waiting for a synchronous response, you need to finish the polling before the client times out. IMHO the best option return a message to a client (we are working on it) and avoid polling if possible..
We've created a Google Cloud Function that is essentially an internal API. Is there any way that other internal Google Cloud Functions can talk to the API function without exposing a HTTP endpoint for that function?
We've looked at PubSub but as far as we can see, you can send a request (per say!) but you can't receive a response.
Ideally, we don't want to expose a HTTP endpoint due to the extra security ramifications and we are trying to follow a microservice approach so every function is its own entity.
I sympathize with your microservices approach and trying to keep your services independent. You can accomplish this without opening all your functions to HTTP. Chris Richardson describes a similar case on his excellent website microservices.io:
You have applied the Database per Service pattern. Each service has
its own database. Some business transactions, however, span multiple
services so you need a mechanism to ensure data consistency across
services. For example, lets imagine that you are building an e-commerce store
where customers have a credit limit. The application must ensure that
a new order will not exceed the customer’s credit limit. Since Orders
and Customers are in different databases the application cannot simply
use a local ACID transaction.
He then goes on:
An e-commerce application that uses this approach would create an
order using a choreography-based saga that consists of the following
steps:
The Order Service creates an Order in a pending state and publishes an OrderCreated event.
The Customer Service receives the event attempts to reserve credit for that Order. It publishes either a Credit Reserved event or a
CreditLimitExceeded event.
The Order Service receives the event and changes the state of the order to either approved or cancelled.
Basically, instead of a direct function call that returns a value synchronously, the first microservice sends an asynchronous "request event" to the second microservice which issues a "response event" that the first service picks up. You would use Cloud PubSub to send and receive the messages.
You can read more about this under the Saga pattern on his website.
The most straightforward thing to do is wrap your API up into a regular function or object, and deploy that extra code along with each function that needs to use it. You may even wish to fully modularize the code, as you would expect from an npm module.