Best practices for Process Modelling in SAP Build Process Automation to use in SAP Ariba Intake Mngt

[NMZ]

In this blog, we share best practices that you can apply to develop processes in SAP Build Process Automation with the specific intent to publish and deploy them as Intake Request Types for the SAP Ariba Intake Management solution.

Make use of the existing documentation

Use SAP Build Process Automation

Explore the available learnings

Re-use action-structures

If you are using actions, the according structures are generated into your project and you can re-use them directly.

Use data types

If you use structures aside from actions, create them as data type in SAP Build Process Automation (SBPA), so you can re-use them at any point in your project. Otherwise, you would have to define them in each input/output of each step you use them in.

Create custom variables

If you need a variable to be available in the whole process then create a custom variable. Custom variables can also make use of created data types.

Use constants

Using constants will avoid typo-based errors in evaluations/comparisons. SBPA does not provide such a thing in the editor, but you can use a custom variable with a default value as a replacement for a constant.

Actions, numbers, and strings

When an action is created via an interface description, fields that are of type EDMX.Decimal will be transformed to “string” in order to avoid truncation issues. If your process is using input that has been defined as “number”, use a script task to convert the number into a string (e.g. via the toString() function) before using it as an input to the action.

Actions and deep mapping

If actions are being used to trigger APIs with deep nested structures (e.g. the Purchase Order API in SAP S/4HANA Cloud Public Edition), the complete structure depth will not be offered in the process editor for mapping. You can use a script task to create an according object as a custom variable and select “bind Object” in the according action input.

How to disable type checking in the script editor

The script editor is checking the complex types you are using within it. For complex structures it will require you to set a value to a field, even if the field is not mandatory. In such cases you can hide the type-information from the editor:

// import the item data from the context
// ignore type information to prevent clashes with editor
var orderItem = JSON.parse(JSON.stringify(
$.context.action_getAPurchaseOrderItem.result.d));
…
// take over the table of account assignments into the PO item
orderItem.to_AccountAssignment = (orderItem.to_AccountAssignment.results && orderItem.to_AccountAssignment.results.length > 0) ? orderItem.to_AccountAssignment : undefined
…

// create POI object with results array
var POI = {
  results: [orderItem]
}

// write the created item data to a custom variable 
// but ignore type information (again) to prevent clashes with editor
$.context.custom.poi = JSON.parse(JSON.stringify(POI))

Now the custom variable “POI” can be used to populate the deep nested to_PurchaseOrderItem input of a “Create Purchase Order” action:

Capture the output of a “Wait for API call” step

The “Wait for API call” steps have outputs that unfortunately can’t be used directly as an input for the next upcoming step. Use a script task to take over the value into a custom variable.

Use sub-processes

If you are creating complex approval workflows, the usage of sub-processes may help to master the complexity. They allow to cut a huge process into smaller manageable pieces. They also help to visualise milestones in the process.

Consider the usage of template variants

It also will give some degree of flexibility, compared to a pure predefined process running in a SaaS environment. You start with a normal process project. There you can add a “Variant Template” step via the “+” anywhere into your process flow. This can be compared to adding an extension point, where (restricted) custom logic can be added in the form of predefined sub-processes.

If you open the editor, you can add sub-processes to it, define inputs/outputs, and general constraints, for example if a step is required or if there is a maximum number of usages. With the “Variant Editor” you also need to create a default variant. Then a “Variant Management” project needs to be created (see here) and maintained as a dependency in the process project. This way an app can be offered to the customer that allows to define and manage variants. The variants that are available can automatically be chosen by predefined rules. If there is no rule in place, the default variant will be chosen.