Design and Implementation of the micro-kernel Process Engine (IVR navigation)-General idea

Development Background

Our company is mainly engaged in the development of enterprise speech products, such as scheduling systems, command systems, teleconference systems, and call center systems. These systems share a common feature, that is, they involve calls, playing, sending and receiving buttons, and venue operations. Our business products are built on our softswitch system. The application servers of the softswitch system provide these services externally.

Problems

We found a problem during the development process. Each product will perform many repeated development on this interface, especially in IVR processing.

IVRInteractive Voice Response (Interactive Voice Response) can improve the quality of call service and save costs. IVR is a powerful automatic telephone service system.

Because our system is re-structured and the softswitch API interface is being developed, we try to solve this problem.

In order to facilitate upper-layer calls to underlying interfaces and reduce repeated development, the product can be rapidly changed to meet user needs, we propose the concept of transaction flow. That is, the upper-Layer Program sets a transaction stream. For example, when a call is initiated to the user 9092, the user is voiced after the user responds, and the user enters the password and the password verification is successfully added to the venue. The Upper Layer Program sets such a transaction stream and sends it to the lower layer for processing. After the lower-level processing is complete, the system replies to the processing result.

The concept of transaction stream is not implemented at the end. First, we have insufficient analysis on the Exception Processing of the transaction stream; second, we adopt the concept of transaction stream extensibility, And the maintainability is not very good.

Later, we introduced the concept of SOA on the basis of the transaction flow, which encapsulates the underlying interface as a series of loosely coupled services and implements the process editing function through service orchestration at the upper layer. However, it is very difficult to implement SOA. First, SOA has no large-scale application, less documentation, less experience, and more implementation risks. Second, it requires tools and investment to implement SOA. In this case, we would rather repeat development.

In the end, the process editing function is not complete, but we still implement a simple process editing in the API. This process editing is implemented by hard coding, it is quite different from our wishes.

New Ideas

Later, I came to the introduction of a platform software company, which is an enterprise application platform. A lot of enterprise applications are workflow. Their platform is integrated with an open-source workflow engine: jbpm. The first time I came into contact with jbpm, I felt that many ideas could be used for reference. Later, I found several articles about using the microkernel Process Engine when I searched for information on the Internet:

Demystifying jbpm Process Engine kernel design ideas and architecture