Defining the application business logic through processes


BMC Helix Innovation Studioprovides Process designer, a graphical-based interface, to create and customize the business processes of a digital service application. Business logic is the core of each application, and a process is an application service that runs this business logic and achieves the application purpose. You can invoke business logic for an application by calling the processes of that application. Each process has a name, input, and output. For example, Approval is the service of the Approval application, which can be invoked by calling the Approval process through REST API or metadata.

Warning

Important

Application business analysts can customize the objects developed in their applications and that are marked customizable by the developers, but cannot customize the objects developed in com.bmc.arsys. For example, objects in core BMC applications like Foundation, Approval, and Assignment cannot be customized. For more information, see Customization-layer.

Before you begin

Before you create a process, make sure that:

  • You understand the process objective, required inputs, and desired outputs.
  • You have all the elements required to create or modify your process. If the required element is not available, request that your developer create and deploy it.
    For more information about process elements and an example of a process created in BMC Helix Innovation Studio, see Process-designer-elements.

Best practices for designing a process

Follow these recommendations when designing a process:

  • Do not create processes with many steps and actions. Process definitions represent a business procedure virtually. When the process definition becomes too big, it loses the benefit of a visual workflow. Instead, use a modular approach to divide the steps into smaller subprocesses. By using the Sub Process or Call Activity element.
  • Make sure that you have planned adequately between writing a coded process activity and using OOTB process activities. Consider the following scenarios when selecting the correct option to write code or use the Process designer:
    • Design a process by using the Process designer if the business logic needs to be visually described or if your users can configure it.
    • Use service tasks to perform a self-sustaining unit of work and let the process manage its own states.
    • Write the code if it is faster to implement complicated logic than by using the Process designer.
  • When creating a new process, concentrate on laying out the flow first. Do not focus on configuring each element. When the flow is completed, save the process and then continue to configure each element one by one.

Best practices for designing a process with parallel wait states

Follow these recommendations when designing a process with parallel wait states:

  • When designing processes with wait states on different parallel gateway paths (for example, User Tasks or Receive Tasks), consider that signals that arrive at the same time are processed sequentially. This mechanism helps prevent processes from entering an inconsistent state.
    For example, if a process has two parallel branches, one with a Receive Task and a Timer, and the other with a User Task, and both the branches resume at the same moment, the Process Engine processes the signals sequentially, so the process continues correctly.
  • Use the Process-Instance-Lock-Acquisition-Retry-Attempts setting to define the number of retry attempts and the Process-Instance-Lock-Acquisition-Retry-Interval-Seconds setting to define the wait interval between them.
    For more information about these settings, see Configuration settings N-R.
    For information about adding these configuration settings, see Updating configuration settings by using the AR System Configuration Generic UI form.
  • If you signal a process instance programmatically by using the SignalProcessInstance API and get the 6830 error, it indicates that the server could not acquire locks after the configured number of attempts. In such cases, configure your client to retry the operation only if required.

Workflow for defining the business logic

The following table lists the different tasks that are involved in defining a business logic:

Task

Action

Reference

Basic workflow

1

Start creating a process by accessing the process designer and adding permissions and elements to the process.

2

Add variables to the process to define the current value of a part of the process.

3

Perform the following actions:

  • Create process steps from start to end to create a business process flow or copy an existing process.
  • Create a process definition by using prompt-based conversation.
  • Provide the process flow order.
  • Loop through a data list.
  • Control the execution of a process flow.

4

View the process dashboard and manage the process execution, such as starting, stopping, or resuming a process.

Adding capabilities to your process

5

Integrate with other applications, enhance process readability, and model a user performing a task so that a process resumes after the task is complete.

6

Perform the following actions:

  • Add wait states, compute expression value to use the expression value in a process flow.
  • Add text annotations that provide additional information about a process.
  • Notify process users.

7

Create or update record instances and define a relationship between the record instances in a process flow.

8

Create a document instance and an array node in the document instance.

9

Analyze the tone of a written document, email, or chat conversation.

10

Manage errors in a process.

 

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*

BMC Helix Innovation Suite 26.1