Adding Activity Diagram Elements for BPMs

User Activity

A user activity is used to indicate the work that is accomplished by the user in the BPM. When the engine reaches this node during processing, the engine creates a task item to be processed for a specified user (participant) or a group of users (for example, a working queue of a lane), and waits for the user to process the task item.

• You can configure Interface and Recipients on the User Task Configuration page.
  Figure 1 User Task Configuration page
  
  • Task Title: Title displayed on the task page.
  • Task Summary: Task description displayed on the task page.
  • Priority: Select a task priority from the drop-down list, such as Normal, High, and Low.
  • Render Type: Page on which the user processes a task. This parameter can be set to Standard Page, Standard Form, or Advance Page. When this parameter is set to Standard Form, you need to configure the actions that can be performed by the user (for example, approving or rejecting an operation). For details about how to create a standard form, see Creating a Standard Form.
  • Recipient Type: Type of the user who processes a task.
    • Current Lane: Bind a lane to a work queue so that user activity diagram elements in the lane are processed by the members of the corresponding work queue. Members of a work queue can include users, portal users, members of a group, roles, or roles with subordinates.
    • Manager of Process Starter: You need to specify Manager Level, that is, the department to which the manager belongs.
    • Name and Expressions: You can assign participants of the task in Expression, User, or Group mode. In this case, the work queue configuration in the lane does not take effect.
    • Rule-based: You need to configure rules.
  • Participants: This parameter is displayed only when Recipient Type is set to Name and Expressions. The participant type can be user, portal user, group, or expression.
    • User: Select the user who receives the task from the Value drop-down list, excluding portal users.
    • Portal User: Select the portal user who receives the task from the Value drop-down list.
    • Group: If you select a group from the Value drop-down list, the task is processed by members in the group. Members of a group can include users, portal users, members of other groups, roles, or roles with subordinates. For details about how to create a group, see Managing Public Groups in Applications.
    • Expression: Indicates the participant is a variable. You can drag or input a variable for Value.
      • Username or user ID. The username must be prefixed with user:.
      • Username or ID of the portal user. The portal user name must be prefixed with puser:.
      • Public group name or ID. The public group name must be prefixed with group:.
      • Role name or role ID. The role name must be prefixed with role:.

      For example, the task recipient is a portal user whose username is PortalUser1, a user whose user name is User1, a user whose user ID is 10XX000000XXXXXXX, a common group whose name is group1, and a role whose name is role1. The value is "puser:PortalUser1,user:User1,10XX000000XXXXXXX,group:group1,role:role1". Use commas (,) to separate multiple values. The values are enclosed in double quotation marks.

  • Rules: rule that the recipient meets. This parameter is displayed only when Recipient Type is set to Rule-based.
  • Who can approve: Select an approval type.
    • If you select Single: one of selected members to approve, the task process can be pushed to the next task only after one of the recipients completes the approval.
    • If you select Joint: wait for all assignees to approve, the task process can be pushed to the next task only when the user group of the recipient meets the approval conditions you set.
  • Regard group as single participant: If a group is selected as the approver, the group is considered to have approved the application when any one of the approvers in the group approves the application. This parameter is displayed only when Joint: wait for all assignees to approve is selected.
    • If this check box is selected, it indicates that if the approver contains a group, the group is considered to have been approved by the first person in the group and does not need to be approved by other users. The group is counted as a valid approver.
    • If this check box is not selected, it indicates that if the approver includes a group, each member in the group needs to approve the application and is counted in the number of valid approvers.
  • Outcome Percentage: The value of this parameter indicates the percentage. If the percentage is reached, the approval result with the highest vote will overwrite the value of $BP.TaskOutcome.
  • Default Outcome: The default approval result when the approval percentage (number of approved employees/total number of valid approvers) does not reach the voting result threshold. This parameter is displayed only when Joint: wait for all assignees to approve is selected.
  • Outcome Trigger Type: This parameter is displayed only when Joint: wait for all assignees to approve is selected.
    • When the minimum percentage is reached, the voting result is triggered immediately.
    • Wait until all voting tasks are complete and trigger the voting result.
  • Approval Actions: Set some actions as the default approval result.
  • Skip Approval on: Specify this parameter to terminate a task immediately.
  • Auto Approval: The platform supports automatic approval of user activities, for example, automatic approval of supervisor review tasks. On the user activity configuration page, specify the recipient of the task, assign the task to a user in the form of an expression, and set the recipient in the automatic approval.
    Figure 2 Automatic approval settings
    
    • Auto approve for process submitter: If this option is selected and the task recipient is the process trigger, the task will be automatically approved.
    • Auto approve if the owner handled the process before: If this option is selected and the task recipient has approved other user activities in the current BPM instance, the user activity will be automatically approved.

    If the task recipient is set to the work queue or user group corresponding to the current lane, the automatic approval function cannot be used. Automatic approval can be performed only when the task recipient is set to a user.

  • Default Action by auto approval: Set the default action selected during automatic approval.
• Actions: You can configure Pre Actions or Post Actions for the user activity.
  Figure 3 Configuring action
  
  • Pre Actions: Action executed before the user activity is executed in the BPM.
    • Criteria: Condition expression that triggers the action.
    • Action Type: Action to be performed when the trigger condition is met.
      • Notify Manager: An email is sent to notify the manager.
      • Notify Assignee: An email is sent to notify the assignee.
      • Call Flow: Call an activated flow.
      • Call Script: Call an activated script.
      • Send Event: Send an event.
      • Transfer: The user activity is transferred to another user or a user in the work queue for processing.
      • Set Status: The status of the user activity is configured.
      • Complete Task: Complete a task. The task will be automatically completed when the task expires.
  • Post Actions: Action executed after the user activity is executed in the BPM. For details, see "Pre Actions".
• Data Mapping: You can perform data mapping for the input and output parameters of the user activity.
  Figure 4 Data mapping
  
• SLA: You can also set an SLA timer for the user activity. If the timer expires, the urgency level is increased and the corresponding action is performed.
  Figure 5 Enabling the SLA timer
  
  • Start When: Start time of the timer.
    • Task Created: Set the time when the task is created as the start time of the timer.
    • Time Defined on Variable: The start time is specified by a time variable.
    • Time Defined on Expression: The start time is specified by an expression. For example, if the relative time of a specified time is supported, set the parameter to STRING2TIME('yyyy-MM-dd hh:mm:ss.S', {!variable1}). Relative time of the dynamically specified time. Set it to TIMEADD({!$Flow.CurrentDateTime}, 100).
  • Goal: When the user activity is within the target period and is about to expire, a specified action is triggered after the trigger conditions are met.
  • Deadline: The activity expires, and a specified action is triggered after the trigger conditions are met.
  • Urgency: Urgency of the timer.
  • Action: Action to be performed after the time expires. Click Add to add an action.
    • Criteria: Condition expression that triggers the action.
    • Action Type: Action to be performed when the trigger condition is met.
      • Notify Manager: An email is sent to notify the manager.
      • Notify Assignee: An email is sent to notify the assignee.
      • Call Flow: Call an activated flow.
      • Call Script: Call an activated script.
      • Send Event: Send an event.
      • Transfer: The user activity is transferred to another user or a user in the work queue for processing.
      • Set Status: The status of the user activity is configured.
      • Assignment: Assign a value to the user activity.
      • Complete Task: Complete a task. The task will be automatically completed when the task expires.

Record Create

This diagram element is for adding instance records of platform objects, akin to using an "INSERT INTO" statement in a database. The system provides the following two modes for adding object instance records:

• Object-based: Click , define an object variable or object variable array in Object Variable, drag the object variable or object variable array to the Variable text box, and use the value of the object variable or object variable array to create an instance record.
  Figure 6 Object-based
  
• Condition-based: You need to specify an object and assign values to the fields of the object to create a record. As shown in the following figure, add an instance record for the Account object and save the new record ID in the id variable.
  Figure 7 Condition-based
  

Record Lookup

This diagram element is for querying instance records of platform objects by condition, akin to using a "SELECT" statement in a database. The system provides the following two modes for querying object instance records:

• Object-based: Click , define an object variable or object variable array in Object Variable, drag the object variable or object variable array to the Variable text box, set conditions, and select a sorting mode, saves the query result in an object variable. As shown in the following figure, object data is queried based on conditions and the query result is saved in the object variable array account.
  Figure 8 Object-based
  
• Condition-based: You need to specify an object and set the values of some fields of the specified object in the condition. The system queries the object records that meet the condition and assigns the values to the configured variables.
  Figure 9 Condition-based
  
  • Object: Name of the object to be queried. Select an object from the drop-down list.
  • Is Distinct: Indicates whether to keep just one record and remove all duplicates in the search results.
  • Condition: After an object is selected, the fields of the object are displayed in this area. Click Add Row to set the conditions for querying data.

    Select the object field to be judged from the field drop-down list, select the corresponding comparison operator from the operator drop-down list, and drag a variable from the context or enter {!Variable name} in the value text box.

  • Sort Field/Order: Sorts the query results in ascending or descending order based on a field.
  • Skip Value: Pagination parameter. Skip the first n records and start to display from record n+1.
  • Limit Value: Maximum number of records displayed on each page.
  • Assign Total Record Numbers to Variable: The total number of queried records is stored in the variable.
  • (Output) Source/Target: output result. Source indicates the field to be queried, the query result needs to be saved to the configured variable, and Target indicates the configured variable.
  • Assign null value if no record is found: If no record is found based on the search criteria, the variable is left blank.

Record Update

This diagram element is for updating instance records of platform objects, akin to using a "UPDATE" statement in a database. The system provides the following two modes for updating object instance records:

• Object-based: Click , define an object variable or object variable array in Object Variable, and drag the object variable or object variable array to the Variable text box. Then, the object variable is updated to the database based on the record ID in the object variable, the value to be updated is obtained from the object variable. As shown in the following figure, the value of the object variable is updated to the database based on the record ID in the object variable array account.
  Figure 10 Object-based
  
• Condition-based: You need to specify an object and set the values of some fields of the specified object in the condition. In the value assignment, you need to set the target fields to be updated and the updated values. Then, the system searches for the object records that meet the conditions and updates the values in the value assignment to the database.
  Figure 11 Condition-based
  

Record Delete

This diagram element is for deleting instance records of platform objects, akin to using a "DELETE" statement in a database. The system provides the following two modes for deleting object instance records:

• Object-based: Click , define an object variable or object variable array in Object Variable, drag the object variable or object variable array to the Variable text box, and use the record ID of the object variable or object variable array to delete the corresponding object record.
  Figure 12 Object-based
  
• Condition-based: You need to specify an object and set the values of some fields of the object in the condition. Then, the object records that meet the condition are deleted.
  Figure 13 Condition-based
  

Call Script

When Call Script is reached in the BPM, the system automatically executes the script. After the script is executed, the BPM execution continues along the subsequent route. When using this element, you need to select the script to be called and set input and output parameters.

Figure 14 Page for configuring the script to be called

A BPM can only call resources, including scripts and flows, within its own application.

For example, if BPM A needs to call script B, ensure that A and B are in the same application. If they are in different applications, you have two options: either replicate script B into the application where BPM A is, or use the Use an Existing Script feature to import script B before making the call within BPM A. In BPM A, use the Call Script diagram element to call the script.

Figure 15 Use an Existing Script

Call Flow

When Call Flow is reached in the BPM, the system automatically executes the flow. After the flow is executed, the BPM execution continues along the subsequent route.

When using this element, you need to select the flow to be called and set input and output parameters.

Figure 16 Page for configuring the flow to be called

Call Activity

Other BPMs can be nested in a BPM. When Call Activity is reached in the BPM, the system automatically executes the activity (calls another BPM). After the activity is executed, the BPM execution continues along the subsequent route.

When using this element, you need to select the BPM to be called and set input and output parameters. You can also enable the SLA timer for the task. For details, see SLA.

Figure 17 Call Activity Detail page

Mail

When the Mail activity is reached in the BPM, the system automatically sends an email. After the email is sent, the BPM execution continues along the subsequent route.

Figure 18 Page for calling the email

• Email Config: You can Manually or Template to set email information.
• Subject: When Email Config is set to Template, you need to select an email template.
• Body: When Email Config is set to Manually, you need to configure the email content.
• Template: When Email Config is set to Template, you need to select an email template.
• Addresses: Set the email address of the recipient.
  • Text: Enter the email address. Separate multiple addresses with semicolons (;). Alternatively, drag a variable from Context to represent the email address of a recipient.
  • Collection: Drag a collection variable from Context. A collection variable is an array variable, indicating the email addresses of multiple recipients. If you select Is Collection when defining a variable, the variable is defined as a collection variable.
    Figure 19 Collection variables
    
• CC: Email address of the CC recipient.
• BCC: Email address of the BCC recipient.
• Should send synchronizedly?: Whether to enable the synchronous sending function.

Data Mapper

When the Data Mapper activity is reached in the BPM, the value assignment operation is performed. After values are assigned, the BPM execution continues along the subsequent route.

As shown in the following figure, the Data Mapper activity is configured to assign the business travel application data submitted by the employee to the director approval form, that is, Director_ApprovalForm.SubmissionForm={!SubmissionForm}.

Figure 20 Configuring Data Mapper

Sub Process

Sub Process is a special automation container activity that contains the creation, startup, and scheduling management of the Sub Process.

When the Sub Process activity is reached in the BPM, subprocess instances are automatically started based on the configured policy. The branch of the parent process is interrupted. The BPM execution continues along the subsequent route after all subprocess instances are complete.

The subprocess model can contain subprocess invocation to form a multi-level nested process.

Figure 21 Subprocess instance

The Call Activity and Sub Process diagram elements are embedded subprocesses of a BPM. The differences are as follows:

• Call Activity regards the sub-process as a black box (no need to pay attention to how the sub-process is implemented) and calls the sub-process through parameter transfer.
• If a sub-process is embedded, a sub-process is directly planned in the current BPM. The sub-process can share the variables of the parent process. It can be used to divide, encapsulate, and reuse process steps.

NOTICE:

If the termination event is used in an embedded sub-process, only the current embedded sub-process is terminated.