Workflow - Set up Containers and Assigning agent to a Task.

8: Set up containers.

There are a number of data containers, which are used in this process to transport relevant data between events, tasks and methods, we need to make a few small modifications to these.

Click on the Containers button. Now click the Create button. Create three fields in the container with reference to the database table. For the first field give reference table name as ‘BKPF’ and reference field name as ‘BUKRS’, for the second give reference field ‘BELNR’ and ‘GJAHR’ for the third. Now go back to the Triggering Event tab, highlight the newly created record in the table and click the Binding Definition button.

This shows us how data is transferred from the Event container into the Task container. There should be four records. Now click on the Event Parameter Container button, this shows us what data is present in the event for transfer to the task. If there is matching data in the Event Parameter Container, copy the element name from the screen and insert it in to the associated slot in the binding definition (Enclosed in &'s).

The last step of all is to activate the event linkage, by pressing the small red button to the left-hand side of the event record. When it is activated it becomes green. This creates the link between the event and the task - which will call the method, which in turn calls the required transaction or reports or function module.

9: Assigning agent to a Task.

Determine the possible Agents for executing the single step Task.

An agent is an executor of a work item.

•       A work item is the actual runtime representation of a workflow process step (task).  Work items appear in users’ integrated inboxes.

•       Possible agents are a collection of agents who qualify to execute a work item, and therefore could potentially receive a work item in their integrated inboxes.

•       Selected agents are those possible agents (1 or more) who are elected to execute a task at runtime.  They actually receive the work item in their
integrated inboxes.

•       The actual agent is the agent among those selected agents who actually processes the work item.  When the actual agent processes this work item, it disappears from the integrated inboxes of any other selected agents.

•       At runtime, a pool of selected and actual agents can be created for the following types of actual agents:

–      The processing agent: The person(s) who actually processes the
work item.

–      The deadline agent: The person(s) informed when a work item is not processed fully within the specified deadline.  This notification is received via a deadline work item in the deadline agent’s integrated inbox.

•       The notification agent: The person(s) notified when an activity step is fully processed. This notification is received via notification e-mail in the notification agent’s SAP office e-mail. The notification

agent is informed if a work item or workflow has been processed and the status of the work item is “completed” or “logically deleted”.

Responsibility can be assigned to a single person, to multiple people (a shared task) based on jobs, positions or organizational unit. This flexible assignment provides the greatest stability and maintainability since the tasks do not have to be reassigned every time specific employee changes and the workflow definition do not need to be changed. The possible agents designated at the single-step task level must already have SAP authorization to execute the functionality in the method. If they don’t, when the task becomes a work item at runtime and the user attempts to execute it, they will get a message: - “You are not authorized to execute this transaction”.

Agents are an important part of tasks.  Agents (capable executors of the task) must be assigned to the single-step task.  (Within the task definition, Additional data®Agent assignment®Maintain.)  These are the agents drawn from the organizational plan who are qualified to perform the task.