What is a BTS application?

The components of an application written using the CICS® business transaction services API are illustrated, in simplified form, in Figure 1. (For brevity, in the rest of this book we shall refer to an application that uses the CICS business transaction services API as "a BTS application".)

Figure 1. Components of a BTS application
 The picture shows all the components of a BTS application that are described in the following list, except for events and timers. At the top of the picture, an initial request causes a BTS process to be started and its root activity to be run. The process is represented by a large rectangle. Within the process, in a tree structure, is a hierarchy of activities, with the root activity at the top. At the second level, are three child activities (children of the root activity). At the third level, are two children of one of the second-level activities (grandchildren of the root activity). One or more small boxes, to the left and right of each activity, represent the input and output data-containers of the activity.

The roles of the components are as follows:

Initial Request
A CICS transaction that starts a CICS business transaction services process.
Process
A collection of one or more BTS activities. It has a unique name by which it can be referenced and invoked. Typically, a process is an instance of a business transaction.

In the vacation example, an instance of the business transaction may be started to sell Jane Doe a vacation in Florida. To identify this particular transaction as relating to Jane Doe, the process could be given the name of Jane Doe’s account number.

Activity
The basic unit of BTS execution. Typically, it represents one of the actions of a business transaction--in the vacation example, renting a car, for instance.

A program that implements an activity differs from a traditional CICS application program only in its being designed to respond to BTS events. It can be written in any of the languages supported by CICS.

Activities can be hierarchically organized, in a tree structure. An activity that starts another activity is known as a parent activity. An activity that is started by another is known as a child activity.

Root activity
The activity at the top of the activity tree--it has no parent activity. A process always contains a root activity. When a process is started, the program that implements its root activity receives control. Typically, a root activity is a parent activity that:
Data-container
A named area of storage, associated with a particular process or activity, and maintained by BTS. Each process or activity can have any number of data-containers. They are used to hold state data, and inputs and outputs for the activity.
Event (not shown in Figure 1)
A BTS event is a means by which CICS business transaction services signal progress in a process. It informs an activity that an action is required or has completed. "Event" is used in its ordinary sense of "something that happens". To define an event recognizable by CICS business transaction services, such a happening is given a name.
Timer (not shown in Figure 1)
A BTS object that expires when the system time becomes greater than a specified date and time, or after a specified period has elapsed. Each timer has an event associated with it. The event occurs ("fires") when the timer expires.

You can use a timer to, for example, cause an activity to be invoked at a particular time in the future.

The preceding components are managed by CICS, which:

The components of a BTS application, and how they relate to each other, are described in more detail in Using the BTS API to write business applications.

Control flow

The high-level control flow of a typical BTS business transaction is as follows:

  1. A CICS transaction makes an initial request to start a process.
  2. CICS initiates the appropriate root activity.
  3. The root activity program, using the BTS API, creates a child activity--or several child activities. It provides the child activity with some input data (by placing the data in a data-container associated with the child), and requests CICS to start the child activity.

    If, as is often the case, the child activity is to run asynchronously with the root activity, the root activity program returns and becomes dormant.

  4. The root activity is reinvoked when one of its child activities completes. It determines which event caused it to be reinvoked--that is, the completion of the activity that it started earlier. It retrieves, from the completed activity’s output data-containers, any return data that the completed activity has placed there.
  5. Steps 3 and 4 are repeated until all the child activities that make up the business transaction have completed.
  6. CICS terminates the root activity.

    If the business transaction has completed normally, the process is no longer known to CICS.

Related concepts
Recovery and restart in BTS
Client/server support in BTS
Web Interface support in BTS
Support for existing code in BTS
Sysplex support in BTS
Monitoring in BTS
The BTS sample application
Related reference
Requirements for BTS
[[ Contents Previous Page | Next Page Index ]]