Skip to Content

Workflow – Summary of the Tool

Workflow in SAP Hybris Cloud for Customer is an often forgotten or under-utilized productivity tool. The three pillars of Workflow are: the right notification/action to the right person at the right time. SAP Hybris Cloud for Customer allows administrators to easily configure workflow rules that will automatically perform notifications and/or system tasks.

At a high level, workflow configuration is an administrative/key user task that consists of the following steps within SAP Hybris Cloud for Customer.

  1. Enter Basic Data – configuration of the workflow name, associated business object, and the timing (triggering event).
  2. Define Conditions – configuration of the Boolean operations that define the data conditions that must be satisfied for a given action.
  3. Define Actions – configuration of the rule type (Action, E-mail, Field Update, Message, Notification). Based on the rule type, additional configuration parameters are revealed.

The prudent business process analytical work necessary to properly configure workflow rules cannot be over-emphasized. For detailed information on the capabilities and configuration of C4C Workflow, please refer to the SAP Hybris Cloud for Customer Administration Guide, which can be accessed here.

Workflow Rule Configuration Considerations

When analyzing and optimizing business processes for workflow automation, please keep the following considerations in mind.

  • For complex notification scenarios, minimize the number of workflow rules – use Boolean operators to consolidate rules to the extent possible.
  • Utilize ‘Scheduled’ timing for workflow triggering.
  • ‘Before Save’ fields configured in workflow rule conditions are designed for use in ‘On Create’ and ‘On Save’ timing scenarios. These field values cannot be correctly evaluated in workflow rules with ‘Scheduled’ timing.
  • For ‘Scheduled’ rule execution, background processes are spawned and distributed within system application servers to optimize throughput.
  • A slight delay may occur in the processing of ‘Scheduled’ rules and resulting emails, but this delay should not be noticeable to the end user, nor should it impact associated business processes.
  • Use report ‘(Beta) Response Time Analysis’ to obtain data on the amount of time spent on workflow rule execution. Look for opportunities to use ‘Scheduled’ timing in workflow rule configuration to reduce the end-to-end response time.

Workflow Rule Execution Considerations

End-to-end (E2E) response time of the UI can be impacted by workflow configuration timing parameter. Because of this, the system behavior of the ‘On Create’, ‘On Save’, and ‘Scheduled’, timing parameter values in workflow rules must be understood and considered in designing workflow rules.

  • The individual response time for ‘On Create’ and ‘On Save’ depends on the number of workflow rules configured for a given business object. These workflow rules are executed synchronously, meaning that the rule evaluation and the resulting actions are completed prior to returning control to the user. They are a component of the overall user end-to-end response time.
  • Whenever a new business object instance is created/or saved, the systems checks all the workflow rules configured for that business object.
  • The workflow condition(s) associated with the business object instance are evaluated.
  • If the conditions are met, trigger and execute the rule (Email/Field Update/Action, etc.)
  • For ‘Scheduled’ rules, the execution of the rule occurs asynchronously, and minimally affect end-to-end response times. The business object instance + workflow rule instance information are stored in a queue to be executed later (based upon the scheduled timing configured in the workflow rule).

Given that ‘Scheduled’ timing causes the workflow rule to be triggered asynchronously, and the timing offset configuration introduces the intended wait state before rule execution, the queued workflow rules are processed in the following manner:

  • Scenario 1 – a master job runs every hour and it selects all workflow rules scheduled to be executed in the next one hour. The process has been designed such that it groups these workflow rules together to the nearest 5 minute interval, such that a maximum of 12 groups and hence 12 background processes are scheduled to be executed by the system. Each time the background process runs, it runs MDRO (Mass Data Run Object), which executes all the workflow rules queued for execution within that 5 minute interval.
  • Scenario 2 – a rule is scheduled for a time before the next master job execution (scenario 1). For example, the last master job executed at 10 AM, the next scheduled run is at 11 AM, and a business object instance (ticket) was changed at 10:10 and the rule is to executed at 10:20. In this case, this business object instance is directly scheduled using a single background job for each business object instance create/change. In this case, the system does not wait for the next scheduled master job at 11 AM to select this business object instance, as this will delay the rule execution. With this scenario, it is possible that many business object instances may be created/changed, which would result in many background processes being created (one for each). In this case, the system attempts to club these together to the extent possible for collective processing. When MDRO is executed in the background process, it picks all the rules to be executed before/at that time. These rules are clubbed together in packages 10 and are executed in parallel. A maximum of 5 packages are executed in parallel and the rest are queued and are executed serially.
  • The execution and performance of these background processes depends on available system resources, and is not managed by the workflow engine.

If a workflow rule fails during execution the first time, the system re-tries to execute it three times before setting the status of the rule as ‘Failed/Cancel’. If the rule is successfully executed then the status is set to ‘Completed’. This information can be viewed from the Monitoring Log UI. The user can also retry a failed rule manually from the Monitoring UI.

Workflow rules are based upon the BRF+ (Business Rules Foundation Plus) engine. For each workflow rule, a BRF+ class is generated for condition evaluation. This happens automatically in the backend system. The generated class ensures the most efficient processing of the workflow rule conditions.

New Feature for Administrators – Workflow Changes Facet

In the 1611 release, a feature has been provided that will allow administrators and end users to view the workflow log of the business object instance. The screen print below is from the Service Ticket UI, and it presents the new facet ‘Workflow Changes’.

The new facet allows the administrator to monitor all rules that were executed on the business object (in this example, a ticket), or are planned to be executed. It allows the admin to see whether the rule was executed successfully, as well as retry failed rules.

To report this post you need to login first.

1 Comment

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

Leave a Reply