Ibm Websphere Process Server Placement Papers - Ibm Websphere Process Server Interview Questions and Answers updated on 19.May.2024

Event handlers enable a running business process to react to events that might be triggered by a partner. By definition, events occur independently and asynchronously. There may be zero or multiple events at any time.

Event handlers can be associated with either a scope or with the business process (Start activity i.e global scope). When a scope starts, all associated event handlers are enabled. The event handlers belonging to a scope are disabled when the scope ends. If the scope ends with a fault, the processing of the event handler is terminated.

There are two types of events:

  1. Incoming messages that correspond to a WSDL operation. A status query or a cancellation is common examples of such events. A correlation must be specified for the incoming messages. 
  2. Alarms that go off after a user-defined period of time, or when a predefined point in time is reached. You can specify alarm events to repeat after a specified period of time.

A business rule is a representation of how business policies or practices apply to a business activity. It is anything that controls the behavior of, or imposes a structure on a business practice. A rule can enforce business policy, establish common guidelines within an organization, or control access in a business environment.

Business rules make business processes more flexible. Because business rules determine the outcome of a process based on a context, using business rules within a business process allows applications to respond quickly to changing business conditions.

Business state machines are service components that allow you to represent business processes based on states and events instead of a sequential business process model.

Business state machines specify the sequences of states, responses, and actions that an object or an interaction goes through in response to events.

Long running Process: A long running, where the process is specifically designed to complete swiftly. The process lifespan is deliberately, such that process versioning issues associated with longer running processes are avoided. human tasks or in-process events may be present. Common uses are to handle “straight through processing” or to manage parallel aggregation.

Short Running Process: A short running BPEL process is to string together service invocations within one traction, or where invocations are not tractional. Short running is also used as a preference for high performance since it does not need to perform persistence in-between steps of the process.

Compensation of microflows and long-running processes can be used to “undo” the outcome of service invocations that have already completed. It is used when choreographing non-tractional services. (If all the services were tractional, you could have them participate in a single traction).

In long-running processes, compensation of activities that have successfully executed is initially triggered by a fault raised in the process, or can be explicitly triggered using a compensation activity. This is a useful technique for reversing the effects of already-committed tractions within a long-running process.

A rule set is a group of if/then statements or rules where the if is the condition and the then is the action of the rule. Rule sets are best suited for those business rules that have very few condition clauses.

CEI provides basic event-management services, including consolidating and persisting raw events from multiple, heterogeneous sources and distributing those events to event consumers. It provides functionality for generation, propagation, persistence, and consumption of events representing service component processes.

Human Task: A human task is, quite simply, a unit of work done by a human. Quite often, this task involves the interaction with other services, and thus becomes a task within a larger business goal.

Types of Human Tasks:

@To-Do Task: Service Create a work item for Human Interaction.

@Invocation Task: Human Interaction Invokes a Service.

@Collaboration Task: Human Interaction invokes a service which creates a work item for another human. Interaction between two hum.

@Administrative task: This type of task grants a human administrative powers such as the ability to suspend, terminate, restart, force-retry, or force-complete a business process. Administrative tasks can be set up on either an invoke activity, or the process as a whole. 

Correlation sets are used to uniquely identify business processes using business data. If a message has to be delivered to a business process, correlation sets are used to identify the particular process instance with which the message is associated. (if it contains more than one receive activity).

A process must have a correlation set if it has more than one receive or pick activity.

A correlation set has a name and is defined by one or multiple properties. A property in turn has a name and a type. You can map a message parameter to a correlation property using a property alias.

An escalation is a course of action that takes place when a human task does not reach an expected state (for example, ended) within a specified time period.

If you add more than one escalation to a human task, you can create one or more escalation chains to define the required escalation path or paths. You chain escalations by specifying that one escalation follow after another escalation. You can create parallel escalation chains by giving the first escalation in two or more escalation chains the same activation state.

SOA: SOA is a Service Oriented Architecture. Service-oriented architecture (SOA) is a SOFTWARE DESIGN and software architecture design pattern based on structured collections of discrete software modules, known as services that collectively provide the complete functionality of a large software application. Purpose of SOA is to allow easy cooperation of a large number of computers that are connected over a network. Every computer can run an arbitrary number of programs – called services in this context – that are built in a way that they can exchange information with any other service within the reach of the network without human interaction and without the need to make changes to the underlying program itself.

A decision table is a scheduled rule logic entry, in table format, that consists of conditions, represented in the row and column headings, and actions, represented as the intersection points of the conditional cases in the table. Decision tables are best suited for business rules that have multiple conditions. Adding another condition is done by simply adding another row or column.

Like the if/then rule set, the decision table is driven by the interaction of conditions and actions. The main difference is that in a decision table, the action is decided by more than one condition, and more than one action can be associated with each set of conditions. If the conditions are met, then the corresponding action or actions are performed.

@SCA: The SCA binding, which is the default, lets your service communicate with services in other SCA  You use an import with an SCA binding to access a service in another SCA module. You use an export with an SCA binding to offer a service to other SCA modules.

@Web service: A Web service binding lets you access an external service using interoperable SOAP messages and qualities of service. You can also use Web service bindings to include attachments as part of the SOAP message.

The Web service binding can use a trport protocol of either SOAP/HTTP      (SOAP over HTTP) or SOAP/JMS (SOAP over JMS). Regardless of the trport      (HTTP or JMS) used to convey the SOAP messages, Web service bindings always handle request/response interactions synchronously.

@HTTP: The HTTP binding lets you access an external service using the HTTP protocol, where non-SOAP messages are used, or where direct HTTP access is required. This binding is used when you are working with Web services that are based on the HTTP model (that is, services that use well-known HTTP interface operations such as GET, PUT, DELETE, and so on).

@EnterpriseJavaBe (EJB): EJB bindings let SCA components interact with services provided by Java EE business logic running on a Java EE server.

@EIS: The EIS (enterprise information system) binding, when used with a JCA resource adapter, lets you access services on an enterprise information system or make your services available to the EIS.

@JMS bindings: Java Message Service (JMS), generic JMS, and WebSphere MQ JMS (MQ JMS) bindings are used for interactions with messaging systems, where asynchronous communication through message queues is critical for reliability.

An export with one of the JMS bindings watches a queue for the arrival of a message and asynchronously sends the response, if any, to the reply queue. An import with one of the JMS bindings builds and sends a message to a JMS queue and watches a queue for the arrival of the response, if any.

@JMS: The JMS binding lets you accessthe WebSphere-embedded JMS provider.

@Generic JMS: The generic JMS binding lets you access a non-IBM vendor messaging system.

@MQ JMS: The MQ JMS binding lets you access the JMS subset of a WebSphere MQ messaging system. You would use this binding when the JMS subset of functions is sufficient for your application.

@MQ: The WebSphere MQ binding lets you communicate with MQ native applications, bringing them into the service oriented architecture framework and providing access to MQ-specific header information. You would use this binding when you need to use MQ native functions.

An export allows exposing a service, so that the service can be called by a service requester.

An import allows calling a service.

Imports and exports have associated bindings that define the communication mechanism (for example, Web service bindings [SOAP/HTTP or SOAP/JMS]) and configuration that provides the details of the trport connection and the format of messages that flow on that connection.

Data bindings and data handlers are associated with import and export bindings to allow the message format to be configured.

EXPORT: Exports process incoming requests from outside SCA modules

IMPORT: Imports process outgoing requests to components outside SCA modules

BINDING: Binding determines how imports and exports interact with components outside a module

BPEL: Business Process Execution Language.

Faults are used to signal problems in BPEL business processes. They can be caught by a Catch or Catch All element in a fault handler. A Catch element specifies the fault that it catches by fault name and/or fault data. Unknown faults are caught by Catch All elements.

Fault handlers can be defined for invoke activities, for scopes, or for the complete business process. They catch faults that are thrown in their scope. If a fault is thrown in a scope, but is not caught by the fault handler of that scope, it is automatically re-thrown to the next enclosing scope.If a fault reaches the process level the process ends in the state failed after the associated fault handler was processed.

BPC is a Business Process Choreography. It used for monitor Process Instance, Process Template and human task Instance, Human task Template.

We can implement human task two ways.

@In-Line Human Task: Aninline task is defined within an implementation of a business process. It can either be implemented directly in the process using a human task activity, or as a property of an invoke, pick, receive, event handler, or on message activity. When you are first planning your human task, you should model it as an inline task if any of the following conditions are present:

  • You need information from the process logic to execute human interaction
  • You want to execute administrative tasks
  • You want to define authorization rights on specific activities

@Stand-alone Human Task: A stand-alone task exists independently of a business process, and implements human interaction as a service that can be used in many of the different components of the WebSphere Integration Developer family of tools. When you are first planning your human task, you should model it as a stand-alone task if any of the following conditions are present:

  • You do not need any information from the business process
  • The task provides just another service

A selector is a dispatch pattern you use to dynamically determine which implementation of a component to invoke at runtime. Like a rule group, a selector has date range entries, selection criteria, and a default destination. You select a destination in a selector the same as your would for a rule group. That is, when a selector is invoked, it selects a destination using the selection criteria and date range entries. A destination could be any service-oriented component.

One major difference between a selector and a rule group is that the destination of a selector can be any service component, while a destination in a rule group can be only a rule set or decision table. In other words, a selector can dynamically re-route a service call to any other component at runtime.

SCA: Service Component Architecture (SCA) is a software technology created by major software vendors including IBM, Oracle and TIBCO. SCA provides a model for composing applications that follow Service-Oriented Architecture principles. The technology encompasses a wide range of disparate technologies and as such is specified in various independent specifications in order to maintain programming language and application environment neutrality.