[Camunda BPMN Advanced] E-commerce order process design and debugging

Table of contents

Summary

BPMN-based software design ideas

E-commerce order process business scenario

Basic order process BPMN design

1. The most basic process design

2. Add the function of automatic cancellation of overtime payment 

3. Add 15 minutes payment reminder

4. Add user cancel order event

Advanced order process BPMN design

1. Execute tasks using parallel gateways

2. Merge tasks with the same event branch into sub-processes 

3. Use Event Sub Process

4. Change the delivery completion notification task to Message Event

Use Camunda REST Api to debug Workflow

1. Get Service Task

 2. Service Task fetch and lock

 3. Complete Service Task

4. Manually cancel the order Handle BPMN Error

reference


Summary

If you want to learn BPMN and want to learn about Camunda as a workflow engine for the first time, then welcome to bookmark this blog. Because I will introduce some of the most important elements of BPMN, I also attached the complete BPMN design source file and the Postman script of the Camunda REST Api for debugging.

Source file address: Camunda-BPMN - Repos (azure.com)

If you don’t know anything about BPMN, please refer to my previous blog: Camunda BPMN_Guo Mahua’s Blog-CSDN Blog 

This time we use a common business scenario: the order process to illustrate how Camunda works in practice.

BPMN- based software design ideas

BPMN (Business Process Modeling Notation, business process modeling notation), is a common and standard language for process modeling. Before learning BPMN, you need to realize :

  • BPMN is a language that can be recognized and executed by programs, not a simple flow chart;
  • The BPMN flow does not care about the specific implementation (the system can use microservices or monoliths, asynchronous or synchronous, or any implementation);
  • BPMN can be executed through a process engine such as Camunda;
  • The Camunda process engine will only notify the outside world of the state of the current process, and receive program feedback and respond.

This development method requires us to divide software services into two types: process scheduling and task execution .

The process scheduler needs to cooperate with Camunda to achieve orderly and correct execution of tasks. For example, when the process scheduler receives the notification from Camunda and comes to the step of "order payment is successful, send a notification to the user" , it will obtain the order process from the current workflow The status information, such as the order number, can then be called through Api, or message queue, etc. to complete the task of user notification.

The design of the task program will be simpler, it does not need and should not consider what happens before and after the workflow, that is something that should be scheduled and coordinated when designing BPMN. For example, the task of "successful order payment, send a notification to the user" , what it needs to do is to obtain the required order information and the content template of the payment success notification according to the order number, and send information to the user.

To put it simply, process scheduling service: "whatever you are asked to do"; task service: "whatever you ask me to do".

E-commerce order process business scenario

All e-commerce platforms support online ordering. We design a Camunda workflow with the following business requirements as the background:

  1. Users can purchase products on the page and click submit to place an order.
  2. The system sends a notification of successful order placement through SMS, WeChat and other channels.
  3. The user needs to complete the payment within 30 minutes. If the payment is not made within the time limit, the order will be automatically canceled and a cancellation notice will be sent.
  4. If the user fails to pay within 15 minutes after placing the order, a pending payment reminder will be sent.
  5. After the user's payment is successful, send a payment success notification and wait for delivery.
  6. Before the delivery is completed, the user can manually choose to cancel the order at any time, and the system background needs to cancel the order and refund.

Thinking question: What if you cannot submit a refund application for an order after the business requires delivery?

Basic order process BPMN design

1. The most basic process design

The most basic order process should be like this. When the user submits an order, the leftmost Start Event is triggered, and a workflow instance is created.

1. The rectangular grid with gears in BPMN represents tasks that can be automatically executed, called Service Task . The first task is " Create Order ". The order service can be notified by the process scheduler to create an order. The order service can choose to write to the database and update the cache, etc.; it can even do nothing and directly reply to the current workflow. It is also possible that the task has been completed. The process engine is only responsible for notifying and receiving program feedback, and does not care about the implementation.

2. Tasks such as " Pay for order " and " Pickup " are User Tasks , and they do not have a clear completion time. When the user completes the payment at a certain time, the program needs to notify the workflow that the current user task has been completed. At this time, the workflow will automatically continue to execute.

To be good at using variables in the workflow, they can store important information of the current workflow and pass it down. It is very important to use appropriate Input and Output Parameters for tasks in BPMN!

2. Add the function of automatic cancellation of overtime payment 

We only need to add a Timer boundary event in the " Pay for order " phase of the workflow, and change the trigger time to 30 minutes later. When the workflow is still in the Pay for order stage after 30 minutes, the Timer in the solid circle indicates the Interrupting mode. When it is triggered, it will end the current Task and turn to the " Order Automatically Canceled " task below.

3. Add 15 minutes payment reminder

You only need to add a Non-Interrupting Timer represented by a dotted line, which is triggered after 15 minutes. When it is triggered, it will not end the current Task, but split the Process token to the " Send Order Unpaid Notification " below, and the payment reminder will be sent automatically . The workflow will continue to wait for user operations.

4. Add user cancel order event

Add an Error Event on " Pay for order " and " Pickup ", indicating that during the waiting for payment and delivery stage, workflow will receive the " Order Manually Canceled " event sent by the program. When this event occurs, the current task should be ended immediately , to perform tasks related to order cancellation.

Advanced order process BPMN design

A basic BPMN process design idea was introduced above. Next, we will design a clearer and less coupled BPMN process based on business requirements.

 1. Execute tasks using parallel gateways

After the order is created and before the delivery is completed, I divide all the events and tasks into the same sub-process, which will be introduced later. Here, the two tasks of " send order creation success notification " and " wait for payment " are executed separately by parallel gateway, because from a business point of view, failure to send notification should not affect user payment, so these two tasks must not be executed serially.

Here, a Timer Event that automatically ends after timeout is added to " Send Order Created Notification ". This is because the sub-process cannot be terminated because it contains a surviving Process Token. If edge tasks such as sending notifications fail, the program should continue to execute normally. Of course, in addition to using BPMN to ensure the normal execution of the process, you can also use the program to ensure that each Service Task is ended regardless of the result.

For the concept of Process Token, please refer to: BPMN Process Token and Gateway - Camunda Workflow Development Practice

2. Merge tasks with the same event branch into sub-processes 

The reason why the above services are added to the same Sub Process is that they have the same process branch, namely order cancellation.

According to business requirements, users can choose to cancel the order at any stage before the delivery is completed, or cancel the order automatically when the timeout expires. Therefore, it is more reasonable to combine the above tasks into the same sub-process and create a unified Error Event handler for the sub-process.

Tips: Error Event can carry information to the workflow, provided that its Code Variable or Message Variable needs to be set.

3. Use Event Sub Process

As shown in the figure, we can continue to add sub-processes among sub-processes. Here I changed the two Timer triggers I added before into an event subprocess.

The event sub-process is also divided into two modes: Interrupting and Non-Interrupting. After dividing the Timer into the event sub-process, we must rely on the current state of the workflow to determine whether the order has been paid to determine the next state.

Therefore, we need to save the " Paid " status to the current workflow instance after the order is paid , so I added an Output Parameter to the " Pay for order " task, and we can pass any parameters when ending the Task, but only when these After the parameters are declared in the Output, they can be added to the workflow and used in subsequent processes.

In the above case, after the " Pay for order " task ends, the IsPaid parameter can be determined to be True. The use of ${execution.getVariable('IsPaid')} here is to obtain from the parameters passed by the code.

4. Change the delivery completion task to Message Event

Message Event represents the arrival of a notification. Maybe the delivery of the order is not done by humans, but by IoT devices. Therefore, we can replace the original " Pickup " User Task with a Message Event (see the envelope pattern above), only when The system will not continue until it receives a message that the delivery is complete.

Use Camunda REST Api to debug Workflow

I have placed the Postman files of Camunda’s commonly used interfaces in the code warehouse at the beginning, and Basic authentication can be used.

1. Get Service Task

 2. Service Task fetch and lock

 3. Complete Service Task

 It can be seen that it is waiting for the order to be paid at this time, and the reminder of the order to be paid is sent, and the two tasks are carried out at the same time. And the " Send Order Created Notification " above has timed out when I took a screenshot.

4. Manually cancel the order Handle BPMN Error

 At this time, because the order cancellation event is received, all activities in the sub-process will be terminated, and the workflow will turn to the " Order Manually Canceled " handler.

There are still some interfaces, which will not be listed here. You can go to Camunda-BPMN - Repos (azure.com) to learn and download.

reference

REST API Reference | docs.camunda.org

BPMN 2.0 Implementation Reference | docs.camunda.org

Guess you like

Origin blog.csdn.net/qq_40404477/article/details/128153437