Browse Prior Art Database

Installation Management in Business Processes During Changes and Failures Based on Priority Disclosure Number: IPCOM000131146D
Original Publication Date: 2005-Nov-08
Included in the Prior Art Database: 2005-Nov-08
Document File: 4 page(s) / 52K

Publishing Venue



Business processes are subject to changes during their life-cycle and there are meant to have multiple changes. For example, a business process might have to follow a new process or a new component to be part of its infrastructure. It might have a new ?approval? or it might have a new ?message? to be sent out for integrating a business partner asynchronously. Bottom line, business processes are ever changing based on geo-political restrictions or with the ever evolving enterprise on-demand. Limitations in existing infrastructures: · Installation of existing business processes requires a downtime or a maintenance service · Changes in an existing business process will require re-deployment of the entire business process without any single component update. · Existing infrastructure has a set of processes or components that can be reused for the new business process. · Failure of a particular component will result in the failure of the entire business process. Reinstallation of a particular component will require root-component failure analysis, component re-installation and then wiring the component to the current business flow.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 34% of the total text.

Page 1 of 4

Installation Management in Business Processes During Changes and Failures Based on Priority

1 Summary of Invention

1.1 Installations in Business Processes with New Business Process

Structured Activities that are defined in BPEL define a way or order in which a collection of activities take place. Structured Activities define a way how a business process is executed and created by composing the basic activities it performs into structures that express the control patterns and data flow between process instances involved in a business protocol. There are many different <activity>* existing in BPEL which provide a way to handle flow management between software service providers. However, if there is a new flow requirement or government regulation which requires the data to be filtered through a certain software system or when the data leaves a certain sub-system, then we are required to install the new sub-system, incorporate it along with the existing activity patterns. Here is a picture to better explain what we are trying to accomplish:

In order to incorporate a new sub-system or porttype or an <activity>* into the system we have to accomplish the following things:

1.1.1 Update <partnerLink> and <partner>

The relationship of a business process to a partner is typically peer-to-peer, requiring a two-way dependency at the service level. In other words a partner represents both a consumer of a service provided by the business process and a provider of a service to a business process. In order to add a new system, sub-system or <activity>*, a <partnerLink> and <partner> as necessary for the BPEL process.


[This page contains 1 picture or other non-text object]

Page 2 of 4

1.1.2 Update the Variable Messages

The business processes that are involved in a BPEL process have stateful interactions. That is state involved consists of messages received and sent as well as other relevant data such as time-out values. The maintenance of the state of a business process requires the use of state variables, which are called variables. The variables are equivalent to SOAP message or XML messages that are being sent between complex systems.

1.1.3 Update all effected BPEL <activity>*

The next step in the process is to update all the <activity>* that are in the path of the new sub-system or <activity>*. We have to be update to incorporate the new change in the system followed by a BPEL updates.
1.1.4 Introduce <pick> to enable Dynamic Creation of Process

The <pick> activity awaits the occurrence of one of a set of events and then performs the activity associated with the event that occurred. The occurrence of the events is often mutually exclusive. The selection of the activity depends upon whichever event occurs first. The special form of <pick> is used when the creation of an instance of the business process could occur as a result of receiving one of a set of possible messages. In this case, the <pick> itself has a createInstance attribute with a va...