Design and Implementation of micro-kernel flow engine (IVR navigation) (I) -- Development Background

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, Upper LayerProgramSet a transaction stream. For example, when a call is initiated against user 9092, the user is voiced after the user responds, and the user enters the password. 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 searched several articles on the Internet to study the microkernel process engine.Article:

Demystifying jbpm Process Engine kernel design ideas and architecture

Design idea and architecture of microkernel Process Engine

Microkernel workflow engine architecture and some solutions

These articles are the core foundation of my process engine design. After reading this, I decided to design a microkernel process engine.

Use open source or self-developed

There are two methods before you decide to start development: one is to use open-source products, such as jbpm, and the other is to develop it on your own. At that time, the considerations were as follows:

1. jbpm is developed in Java. Currently, our company's business products are basically C, which is inconvenient to interact with Java.

2. jbpm is designed for enterprise workflows. An important difference between workflows and IVR navigation is that IVR Navigation requires high timeliness. The system is required to respond in a timely manner.

3. I was not a Java student, but I was still a little worried about Java.

Therefore, we decided to use the C ++ development process engine.

If it is now, even if you decide to develop it by yourself, you will take a good look at the jbpm source code.

Other ideas for Reference

1. Data-driven (dd ). Define the process in XML in the script. After the program starts, the process is read into the program and then called by the upper program. If the process is changed, modify the script directly.

2. BPEL. The abbreviation of Business Process Execution Language, meaningBusiness Process Execution Language, Is an XML-based, used to describe the Business ProcessProgramming Language. For my footstep language, refer to the description of BPEL.