Name: Implementing an Automated Step with Workflow Automated Actions in SAP Commerce Cloud
Uploaded: 2024-7-19
Duration: 487 s
Description: This video demonstrates how to implement an automatic workflow action step in SAP Commerce Cloud.

Share feedback

<p><u><strong>Planned maintenance of Practice Systems</strong></u></p>

Planned maintenance of Practice Systems

Why create an SAP account?

Enhance your learning experience

SAP Learning

Choose your subscription

Manage your subscription

Live Sessions

Hands-on Practice

Certification

My Learning

Ready to start learning?

<div><div><div><div><div><div><div>This video demonstrates how to implement an automatic workflow action step in SAP Commerce Cloud.</div></div></div></div></div></div></div>

Implementing an Automated Step with Workflow Automated Actions in SAP Commerce Cloud

Hello everyone! In this video we are going to talk about workflows  How about if we want to add some automated steps into a workflow?  Such as in the example that, the “Check Changes” action can be performed by an automatic checking mechanism.  This is where an automatic workflow action step can come into play.  If no manual interaction is needed or wanted in executing an action, any service layer business logic can be implemented as an automated workflow action.  Implementation steps are as follows: you must define an automated workflow template job Java implementation class, declare a Spring bean to point to your class, and finally, connect the Spring bean to a workflow action and relate it to a workflow template.  Let us go through the details step-by-step.  First, we need to implement the AutomatedWorkflowTemplateJob Java interface.  Here, we see that the corresponding WorkflowActionModel is passed to the perform() method, through which we can access the attachment items.  In our case, the attached items are the products to which details were added.  For each product, we can invoke a predefined method to check the related product changes.  If the checking of any product fails, we can return a REJECT decision;  whereas if we get through the list of products, we can return the predefined APPROVE decision.  As the next step, we need to declare a bean in the Spring context pointing to the implementation class.  Please note, if we do not specify the scope, all beans are instantiated as Singleton.  That’s why we need to specify the scope as prototype, so that a new object is created every time a new workflow is generated.  Finally, we create an AutomatedWorkflowActionTemplate, and assign the job handler attribute the bean id that was declared in the Spring context to point to the automatic action class.  This is typically done in the Backoffice administration cockpit, but we can also do it via ImpEx, as in the example here.  The code of the new automatic action is “AutomatedProductsCheck”.  It is related to the workflow template named “ProductDetailWorkflowTemplate”, and most importantly, the job handler is “checkChangesAction”, the id of the Spring bean defined in the previous step.  Now let us look at the previous example one more time.  Once the workflow is started, detailManager can add summary information to specific products and trigger the workflow to transition to the next action, “Check Summary”, where, qualityManager manually checks the summary changes, and either accepts the changes, or reject it.  We can modify the workflow to contain an additional automatic action called “precheck summary”.  It will check whether the summary field of each related product is blank or not.  If yes, it will return a decision “reject precheck” and detailManager will need to “add summary” again; otherwise, it will pass “accept precheck” and the remaining process stays the same.  Different from the previous way, I will create the workflow template completely via the following ImpEx.  The two employees: detailManager and qualityManager, are created here.  A workflow template named “Product Summary Workflow Template” is created with the owner set to admin.  3 action templates are created as well, they are: the “Add Summary Products”, assigned to detailManager, with “Start” as the action type.  The “Check Summary Product”, assigned to qualityManager, with “Normal” as the action type; the “Summary OK” as the “End” action, assigned to the backofficeproductadministratorgroup  I’ll also create the 3 decision templates: “done Summary”, connecting from the “add summary products” action;  ”reject Summary”, and “accept Summary”, connecting from the “check summary product” action as the 2 outgoing decisions.  I’ll need to link the decisions to subsequent actions as well, therefore, “done Summary” is connected to the “check summary product” action, “reject Summary” to the “add summary products” action, and finally “accept Summary” to the “Summary OK” action.  After importing the ImpEx, we can make sure the workflow template “Product Summary Workflow Template” is generated.  As a good practice, I’ll create a new extension to hold my custom implementation via “ant extgen”.  Don’t forget to import the extension and add it in localextensions.xml.  Based on the 3 steps mentioned earlier, the first step is to create a class which implements the “automated workflow template job” interface.  The “Abstract Product Related Workflow Action Job” class provides a general “get attached products” method which accepts an action model and returns the attached products of the model.  As the actual implementation, the class “check product summary workflow action” extends the previous class.  In the essential perform() method, the action object is used to obtain the list of attached products via the getAttachedProducts() method of the parent class.  Then, for each product, it is checking whether the summary field is blank or not; if yes, it returns the decision that starts with “reject”, otherwise, It returns the decision that starts with “accept”.  As the next step, I’ll register a new bean named “checkProductSummaryWorkflowAction” in the new extension’s spring.xml file to point to the Java class.  I’ll now run “ant all” to build SAP Commerce Cloud, and once the build is successful, I’ll start the Commerce Cloud Server.  In the HAC of the running Commerce Cloud Server, I’ll use this ImpEx script to create a new “Automated Workflow Action Template”, linking the “Product Summary Workflow Template” with the previously defined Spring bean “checkProductSummaryWorkflowAction”, and name the automated action template: “PreCheckProductSummary”.  In Backoffice, I can see the new action “PreCheckProductSummary” is created and included in the workflow template.  By clicking the pencil icon, I can see the current workflow template’s structure.  I’ll delete the connecting edge between “finished adding” and “check summary”.  Then I’ll add a new edge to connect ‘finished adding’ to ‘precheck summary’.  I’ll also add two new decisions, ‘accept precheck’ and ‘reject precheck’, and connect them in the way that the “precheck” has two possible outgoing decisions, “reject precheck” connecting to the “add summary” action, and “accept precheck” connecting to the “check summary” action.  It’s time to test the automated workflow template.  In the product cockpit, I’ll use the same way to place a product to create a new workflow, select the workflow template as the “product summary workflow template”, I’ll give it a name as “product summary workflow 001”.  I’ll click next and make sure the attached product looks OK, and finally start the workflow.  Finally, I can log in as detailManager and in the Tasks tab there is an add summary Task.  I’ll keep the summary as blank on purpose and save the product.  After choosing the decision to trigger the workflow to transition to the next step, I can see that there is a task in the task pane again, telling us to add the summary.  This is not an error, because the logic implemented in the “check product summary” workflow automated action class detects that there is a product with a blank summary, so it returns the reject decision, and the workflow sends the task right back to detailManager with the same product.  Only when the summary attribute is filled, the notification will disappear as the workflow passes the automatic check.  This is how we achieved an automated way to pre-check the summary before going to the quality manager queue.  Thanks for watching.