There are a number of ways in which your applications can handle the transfer of data to and from activities that are run asynchronously with the requestor. In the simplest case, a single data-container may be used for both input and output data. If the activity will be activated only once, this presents no problems. Perhaps separate containers are used, one for input and one for output data. Again, if the activity will be activated only once, this presents no problems. However, if the activity may be activated, asynchronously, multiple times, you must take care that the contents of containers are not over-written inadvertently. You should take particular care when designing client/server applications, and applications which involve activities being acquired and run multiple times by transactions external to their parent process.
If an application chooses to run a server process or an acquired activity asynchronously, it needs to be aware of the state of the activity being activated. In the normal case, the activity is dormant--awaiting the activation and ready to perform its function. The activation occurs almost immediately, the activity program executes and places any results in a container. In a client/server application, the activity may then be left dormant, ready for the next request. If the activation is triggered by an external interaction, it’s likely that the activity will complete; the firing of its completion event causes its parent to be reactivated.
However, you should take account of the fact that, when the RUN ASYNCHRONOUS command is executed, the target activity may not be dormant, waiting for work--it may be in any of the other possible processing modes, or it could be suspended. If, for example, the target activity has been suspended, the asynchronous activation will not happen immediately. Thus, in a client/server application, it’s possible for the client program to issue a request to the server before a previous request has been serviced. You should be aware of these possibilities when designing your applications. If, for example, the protocol between a client program and its server activity relies on a single container for passing data, the client needs to check that the container is not occupied by a previous request before issuing subsequent requests. Another solution would be for the client to use multiple containers to form a queue of requests for the server activity; the containers could be named sequentially.