Skip to Content

Creating Dynamic Task Subjects  and Descriptions in SAP NetWeaver BPM

Summary

SAP NetWeaver provides an out of the box capability where in a task subject and descriptions can be generated during runtime. Everybody would be familiar with creation of a static task subject. Let us assume we have a case wherein the task subject and description should change at runtime as per the process context data. This article deals with this scenario wherein a task picks up the process context data and generates a subject and description dynamically at runtime.

Creating a dynamic task header

Most of the human tasks in UWL have a static subject and description, for example, “Creation of Purchase Order” or “Data Entry for Material Creation” and so on. However, imagine a situation wherein a particular user has many hundreds of these tasks and have to pick up a particular task pertaining to a particular material number. If the task subject were to be static, the user would see hundreds of similar tasks with exactly the same subject in his Universal Work List (UWL). He would have to pick up each task manually, open it and identify if this is the task that he has to complete on priority. Let us address this problem by creating task subjects, which would clearly indicate to the user the right task that he has to pick up, and complete, thereby making the Task subject and description dynamic.

Technical Implementation

Whenever a human task is created, a static text can be entered in the  ‘Subject’ and ‘Description’ in the ‘User Texts’ of a task. This text is shown in the UWL as the task subject and the description is displayed in a column below the UWL task list when a task is selected. To make this dynamic, we have to create variables under the ‘Variables’ section as shown ‘User Texts’.

In Process development perspective, when a task is modeled, process context data can be passed into a UI through ‘Input Mapping’. These process context parameters that are passed into the UIs are accessible to ‘Variables’ in ‘User Texts’ in a task. As an example, let me take a case wherein my description should be a combination of some process specific attributes like material ID, project ID etc. These are passed into the UIRequest through Input mapping from process development perspective.

In ‘Variables’, create a new variable by clicking on the ‘Add’ button. Give a name for the variable, for example, as shown in Figure 1 below, the variable is named Material_Id. Once this is done, select Material_Id and click on ‘Edit’ button. This opens up an expressions editor. From the ‘Context’ of the editor, select the UIRequest/Material_Number, which has to be associated with the newly created variable Material_Id. Now the variable Material_Id holds the value of the Material_Number, which has been passed from the process context.

To make the task subject and descriptions dynamic, these newly created variables, which hold the process context values have to be used with { } placeholders. Assuming that the subject line should be “Create Material 20226348”, in the Subject, the text should be Create Material {Material_ID}. Please refer Figure 2 for an example of how this is done.

Similarly, in the descriptions, variables in { } can be used to dynamically manipulate the description text. For example, {Project_ID} {Material_ID} in the description would show the description as 2401 20226348 as the text in UWL assuming that 2401 and 20226348 are passed from the process context.

Figure 1

Figure 1

Figure 2

Figure 2

Benefits

Let us come back to the hypothetical scenario that I raised in the beginning of this article. A user who has hundreds of tasks in his UWL wants to identify a task pertaining to a particular material number. With dynamic task subject in place, the user would be able to search for that material number in the UWL filter and get the list of tasks associated with that material number, thereby making the user’s life simpler. Thus, some very clear benefits out of this are burgeoning improvement in usability, increased productivity and better transparency.

Figure 3

Figure 3

Process Context Keeping it clean and simple:

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply