Request processing patterns for simple service flows

Stabilized feature: Service Flow Runtime and Service Flow Modeler capability in IBM Developer for z/OS 14.2.3 are stabilized. Consider exposing and orchestrating applications as API services by using z/OS Connect Enterprise Edition or CICS® web services, or by writing web applications in Java or Node.js. See also Stabilization notices and discontinued functions.

Simple service flows conform to the single connector pattern. Simple service flows are processed in slightly different ways, depending on whether the service flow is persistent. If the service flow is not persistent, the command that DFHMADPL uses to create the navigation manager process has an additional option.

The following steps describe the request processing of a simple service flow:
  1. A service requester invokes the service flow when it sends a request message using any of the supported interfaces.
  2. The CICS SFR interface program DFHMADPL receives the request and, using the request name in the request message, DFHMADPL reads the service flow repository file DFHMAASF.

    If the request is in XML, DFHMADPL invokes the XML-to-COBOL converter program to parse the XML header and return COBOL. DFHMADPL then reads the service flow repository file.

  3. The process mode of the service flow is defined in the service flow repository file. If the service flow is simple, DFHMADPL performs the following processing:
    1. Defines the BTS process using the BTS command EXEC CICS DEFINE PROCESS. If the service flow is persistent, a record is added to the BTS repository for the process, allowing CICS to recover if a failure occurs. If the service flow is not persistent and the BTS NOCHECK option is specified, a record is not added to the BTS repository.
    2. Writes application request data to the ADAPTER.INPUT data-container. The server adapter reads the ADAPTER.INPUT data-container to retrieve the application request data that is used to process the service flow.
    3. Writes state information to the ADAPTER.PROCESS data-container. State information includes the request name, the program name, and the transaction that will process the application request data. For service flows of the single connector type, the program and transaction is a FEPI or Link3270 server adapter.
    4. Runs the BTS process in synchronous or asynchronous mode, as defined in the service flow repository file.
  4. After the navigation manager is invoked, it performs the following processing steps:
    1. Reads the state information from the ADAPTER.PROCESS data-container.
    2. Defines the BTS activity that processes the request to run the service flow, using the BTS command EXEC CICS DEFINE ACTIVITY:
    3. Writes adapter state information to the ADAPTER.PROCESS data-container. Additional state information includes the activity ID, the CICS applid where the Navigation Manager is running, and the EIBTASKN of the running Navigation Manager.
    4. Runs the BTS activity for the service flow in synchronous or asynchronous mode, as defined in the service flow repository file.

When the Navigation Manager runs the BTS activity, the FEPI or Link3270 server adapter performs request processing to complete the request made by the service requester. Each business request issued by the service requester results in a different BTS process instance to run the appropriate service flow. Each process instance consists of a Navigation Manager activity and the server adapter activity that is needed to support that service flow.