Introduction

In the examples we have looked at so far, after the initial order details have been collected from a user terminal the Sale business transaction has proceeded without further interaction with the outside world. Each activity has been started automatically by CICS® business transaction services, following the completion of its predecessor.

In practice, many business transactions require some sort of interaction with things external to themselves. For example, most business transactions include activities that require human involvement. (Such activities are known as user-related activities. They cannot be started automatically by BTS, because they rely on the user being ready to process the work.) Other examples of external interactions are dependencies on input from the World Wide Web or from MQ queues.

To permit interaction with the outside world, BTS allows a program executing outside a process to acquire access to an activity within the process. This means, for example, that CICS transactions can:

Use BTS processes as servers
A client transaction outside a process can "acquire" the root activity of the process. This enables it to pass business data to the process in the process or root activity’s containers. The transaction does not become part of the process--rather, it is able to activate the process and use it as a server.
Acquire BTS activities
A transaction outside a process can acquire a descendant activity within the process. Acquiring the activity gives the transaction access to the activity’s containers, and allows it to activate the activity.

Both these examples use input events to signify that a process or activity requires some external interaction to take place before it can complete.

Acquiring processes and activities

Before a program executing outside a process can activate an activity within the process, it must acquire access to the activity. Acquiring an activity enables the program to:

To gain access to an activity from outside the process that contains it, you use the ACQUIRE command. An activity that a program accesses by means of an ACQUIRE command is known as an acquired activity.

There are two forms of the ACQUIRE command:

ACQUIRE ACTIVITYID
Acquires the specified descendant (non-root) activity.
ACQUIRE PROCESS
Acquires the root activity of the specified process.
Note:
When a program defines a process, it is automatically given access to the process’s root activity. (This enables the defining program to access the process containers and root activity containers before running the process.) When a program gains access to a root activity by means of either a DEFINE PROCESS or an ACQUIRE PROCESS command, the process is known as the acquired process.

For definitive information about the ACQUIRE command, see the CICS Application Programming Reference.

Some rules

  1. A program can acquire only one activity within the same unit of work. The activity remains acquired until the next syncpoint. This means, for example, that a program:
  2. If a program is executing as an activation of an activity, it cannot:
  3. An acquired activity’s process is accessible in the same way as the activity itself can access it. Thus, if the acquired activity is a descendant activity: Conversely, if the acquired activity is a root activity:

Related concepts
Using the BTS API to write business applications
The Sale example application
Related tasks
Using client/server processing
Acquiring an activity
Transferring data to asynchronous activations
Related reference
Overview of BTS API commands
BTS application programming commands

6.
If the acquired activity is a root activity, against the process.

[[ Contents Previous Page | Next Page Index ]]