BPM Advanced / Integration Designer / Process Server Interview Questions

Q: What are the differences between long-running process and micro-flows? when do you use each of them?

We use long running process only in the following conditions

• If your process requires more than one transaction.
• If your process will need to stop at any point and wait for external input, either in the form of an event or a human task,.
• If you have elements in your process that you would like to run in parallel

We use short running process in the following conditions

• A microflow is a process that is contained within a single transaction. 
• Because it runs automatically from start to finish, it is ideal for situations where the user is expecting an immediate response. 
• Example of a microflow would be a database query. 
• Microflows cannot be used for processes involving human tasks.
• If you have a short series of steps to model and want them executed very quickly in the runtime environment, use a microflow.

Performance: short running processes offer great performance; so, where ever feasible one should use short running processes.

Q: What is Human Task?
A human task is a unit of work that involves a person. Examples would be an review process, in which a manager must provide final approval, or when a follow-up telephone call with a client is required.

The definition of a human task includes the following information:

• who can perform the task
• what needs to be done
• what happens when the task takes too long
• how the task will be done

Q: What are different implementation mechanisms or subcategories of Human Tasks?

Stand-alone: A stand-alone task exists independently of a process, and implements human interaction as a service that can be wired to any other component.

There are two instances in particular when you should model your human task as a stand-alone task:

• The task provides just another service.
• You intend to replace the stand-alone task at a later stage and do not want to change the component to which it is wired.

Inline: An inline human task is a piece of a larger BPEL process that must be performed by a person.

You should model your process with an inline task when:

• You need information from the process logic to run the human task. Although information from the process can also be modeled into the input for a human task, the main reason to use an inline human task is because they have direct access to the process context without the need to explicitly model the required information into the input message.
• You want to define authorization rights on specific activities.

Whether a task is inline or standalone is defined by the manner in which you connect it to your BPEL process

Q: What are different types of Human Tasks?

• To-do task - a service schedules a piece of work for a person to perform.
• Invocation task - a person uses a service.
• Collaboration task - one person assigns work to another person.
• Administration task - a person is granted administrative powers over an activity or process.

Q: What is difference between the parallel flow and generalized flow activities in BPEL process?

Parallel Flow

• A parallel process (or flow) is a collection of other process activities that are all nested within a parallel activity. 
• The nested activities run sequentially in an order that is dictated by links and transition conditions (when no links are present, all activities will be executed concurrently). 
• Parallel activities are very versatile, and can add a depth to a long-running process.

Generalized Flow

• A generalized flow activity is very similar to a parallel activity in that you can nest other process activities within it, and then control the execution order of those activities through links. 
• The generalized flow activity differs in its ability to use conditional links to loop back to previous activities in the sequence

Q: How do you assign people to a process (people assignment)? What are the pre-defined roles for human tasks?

When you define a human task you must stipulate which people are eligible to view, initiate, perform and administer the task. This step is known as people assignment. You can assign work to a named individual, to a member of a certain group.

There are pre-defined roles for human tasks which you can assign people or groups to. Members of a role share the same level of authority. The roles are:

• Administrators - have the authority to perform high level duties like suspend, terminate, restart, force-retry, and force-complete.
• Potential creators - can create an instance of the human task, but cannot start it.
• Potential starters - have the authority to initiate an existing instance. The starter role is subtly different from that of creator, and although a creator can create a new instance, only a starter can start it.
• Potential owners - can claim, work on and complete tasks.
• Editors - can work with the content of a task, but cannot claim or complete it. For example, an editor can receive the work item to review a document and add comments, but an editor is not able to finish the task.
• Readers - are allowed to view tasks, but cannot work on them. This role can be used in situations where someone needs to monitor a task without taking any action in it.

Q: How do you run different versions of the same process at run-time or versioning BPEL processes?

A version is a copy of an existing process that is slightly different from the original. To understand how this differentiation takes place, you must first understand what identifies a version of a business process.
If the module that contains the BPEL process is not associated with a process application or toolkit, then a version of a business process is identified by the following properties:

• same process component name
• same target namespace
• different valid-from date

If the module that contains the BPEL process is associated with a process application or toolkit, then the following properties constitute a process version:

• same process component name
• same target namespace
• different snapshot ID

In addition, it is important to note the following requirements:

• Correlation set specifications of different process versions need be the same.
• Interface specifications of different process versions need to remain the same. If you change the WSDL definition in any way, you need to change the BPEL process to incorporate those changes. If the WSDL has changed, you will need to load the new WSDL into IBM® Integration Designer, because when you deploy the module to the runtime environment, it requires the service definitions in the consumer and provider to match.

Of critical importance, the two versions must have the same name and namespace, but have different valid-from dates or snapshot ID's. In addition, where applicable, they must also have the same interface, and correlation set specifications.

• It is with different valid-from dates that multiple versions of the same BPEL processes are distinguished.
• In practice, at run time the process engine could use a new version of a process that is set to become valid today, even if an older version of that process was still being used

Q: When do you decide to create a new version of BPEL process?
Here are some possible examples of when you would create a version of a BPEL process:

• In the likelihood that your BPEL process will need to be modified over time, but its callers will not. In such a case, you will want the existing callers to be able to seamlessly pickup the newest version of the process the moment it becomes effective.
• You have a solution where multiple versions of the same BPEL process must coexist. Although the solution as a whole cannot be uninstalled and reinstalled, you will need to be able to deploy new versions of the process in such a way as to ensure that new instances use the latest version and, wherever possible, existing instances also migrate to the latest version.

One important consideration is whether instances of the process that are already running should move to the new version. If you want to migrate running instances you need to create a Migration Specification. If you are content to allow existing instances to use the old version you do not need to create a migration specification.

Q: How do you handle faults or exceptions in BPEL process?

A fault is any exceptional condition that can change the normal processing of a BPEL process and, if not handled, can lead to undesirable conditions or results. A well-designed process is one that anticipates possible faults with fault handlers that are designed to lead to predictable outcomes.

Here are some of your options for dealing with faults that are available in the BPEL process editor:

• Use a terminate activity to stop the execution of a process or an activity so someone can step in and make necessary repairs.
• Use a reply activity with a fault name associated with it so it will respond with a fault.
• Use a throw activity to signal an internal fault.
• Use a fault handler to catch a fault and attempt to deal with it.
• Use compensation to roll back or undo a process or an activity that has failed after committal.

Q: What is Correlation or Correlation Sets? What is purpose of them?

• Correlations are used in runtime environments where there are multiple instances of the same process running. 
• A correlation set for a BPEL process consists of a name and one or more properties. They are used to distinguish the instances of same process in runtime.
• Correlation sets allow two partners to initialize a BPEL process transaction, temporarily suspend activity, and then recognize each other again when that transaction resumes.

Q: What is Compensation?

Compensation is the means by which operations in a process that have successfully completed can be undone to return the system to a consistent state if an error occurs.

You can compensate a BPEL process in two ways:

• Save the properties of the individual parts of a process so that they can be restored if the process cannot be committed and must be rolled back (compensation pairs).
• Use a compensation handler to return a failed process to a balanced state after a fault is thrown when the parent activity has already been committed.

Q: How do you Compensate long running process and short running process (microflow)?

• To set up compensation for a microflow, store the original properties for each of the invoke activities within the microflow so the original data can be restored if the process cannot be committed and must be rolled back.
• To set up compensation for a long-running process, you need to specify how to compensate each transaction if the process fails.

Q: What are Escalations?

If a task is overdue it needs to be escalated. Use escalation properties to define when a task must be completed and the actions to take if deadlines are missed

.

There are three possible states for which an escalation can be configured:

• Ready - when a human task is in a ready state, it is waiting to be claimed. You can configure an escalation to trigger if it sits unclaimed for too long.
• Claimed - if a staff member has claimed a task, but takes longer than the specified period of time to complete it, an escalation is triggered and another staff member is notified, for example, the manager of the claimant.
• Subtask started - a subtask is an additional unit of work that is split out from a parent task. If the subtask fails to complete within a specified period of time, the parent task is escalated and indicates that it is still waiting on the subtask.

Q: What are the transactional behavior options for the activities inside a BPEL process?

• Commit before: preceding transaction commits before this activity starts
• Commit after: transaction commits immediately after this activity is completed
• Participates: activity runs in existing transaction
• Requires Own: activity is isolated in its own transaction.

Q: How do you enter the input data required by the process?

Using the Business Process Choreography Explorer. It is access using Web Browser.

Q: What is Business State Machine? and When do you use BSM vs BPEL process?

Business State Machine is an alternative to BPEL process. If the process can be modeled in terms of life cycle i.e. state transitions and that these transitions are driven by events; typically have loop-based logic (returning to previous states), then choose BSM.

• A BSM, like other components in Process Server, is a SCA component. Its interface is defined using WSDL. 
• Any number of WSDLs can be predefined and associated with the BSM as it is developed. And, all of the operations defined in these WSDLs must be used in the BSM

Usage of BSM vs BPEL process:

• In cases where the state machines are--and will--remain simple, it may be better to use a BPEL process. For example, a state machine without any loops (returning to an earlier state), would probably make more sense being developed as a process. 
• However, if there is a lot of looping, the state machine provides a much more natural way to develop, debug, and monitor.
• If you do have performance constraints, then do not prefer BSM as it is internally will get converted into BPEL process by the Process Server runtime .

Q: What is rule group? How do you implement rule groups?

A business rule is a condition that must be satisfied when a business activity is being performed. A rule can enforce a business policy, make a decision, or infer new data from existing data.

• A rule group is the highest level implementation component of a business rule. The rule group acts as a gateway to the business rule. 
• The rule group defines the interface and operation that the business rules will implement. 

Rules logic are implemented using Rule sets and decision tables in Rule Groups.

• Rule sets and decision tables cannot be invoked directly and may only be invoked through a rule group. 
• One of the most important functions of the rule group is to define a date and time range during which a specific rule set or decision table will be used. An example would be a regularly scheduled July sales event.

Q: Compare the Rule sets and Decision Tables?

Rule sets model the typical if-then kind of business rules, if you need to model rules on values from multiple input combinations, then decision tables are preferred.

Q: What is use of templates in rule groups?

In order to create business rules that are dynamically modifiable at runtime the business rules must be based on templates. Decision tables can also be made dynamically modifiable at runtime by basing the conditions or actions of the decision table on templates.

A template defines what parts of a deployed business rule can be modified by an authorized user. The template uses parameters and constraints to provide dynamicity. Parameters and constraints define which values can be modified and by how much.

Q: What do you use to modify the business rules dynamically?

The Business Rules Manager is a Web client that allows dynamic control of parameter values in template-based rules that are deployed to the IBM Process Server.

If you build your rules using templates you provide runtime control over aspects of the rule. You also provide constraints so that the rules cannot be misused. The runtime administrator uses the Business Rules manager to adjust the implementation of the rule.

You access the Business Rules manager using a web browser. The default URL for accessing the business rules manager is as follows. The URL may vary according to your environment.
http://hostname:port/br