iProcess Conductor and iProcess Engine Implementation

1.3 iProcess Conductor and iProcess Engine Implementation

Order sent by BE is received by IPC through BW layer. IPC then becomes the orchestrator for that order.

It will start a case of the Fulfillment procedure to accomplish the goals for that order. Later it will build an

Execution Plan based on the Plan Fragments and then processing of the order will proceed based on that

plan. Plan Fragments (Execution Plan template) consists of process component which are created in IPC.

These process components are associated with iProcess subprocedures. In IAL Execution Plan is

created by using AOPD (Automatic order plan development) feature of IPC. AOPD as its name suggests

facilitate runtime generation of execution plan.

Below are the tasks performed by iPC during complete lifecycle of an order.

IPC order reception (OrderRequest).

IPC stores automatically the order in the database.

IPC creates a case of fulfillment procedure in IPE for the order received (the main procedure).

IPE requests the execution or fulfillment plan to BE (via BW) sending the Order ID.

IPC receives the fulfillment plan (AOPDRequest), stores it automatically in the database and

sends a response (AOPDResponse) which contains the Unique Plan ID.

BW receives the AOPDResponse message, extracts the Unique Plan ID and sends it to IPE in

order IPE tells to IPC to associate the execution plan to its IPC Order and start the plan.

IPC starts the Execution Plan. There will be executed all tasks in the plan. Each task represent a

Fenix or Tibco event.

1.3.1 iPC Implmentation

1.3.1.1 Order Reception

Order Schema and description

Order sent by BE to iPC should be based on the order schema defined in IPC for Order reception. This

order is sent on a TIBCO EMS queue, “queue/ COMOrderRequestInjectorQueue”, preconfigured in

iPC from order reception. Please refer section 1.2.11 for the mapping of iPC order with Siebel order

message.

BE BW iPC iPE

OrderRequestOrderRequest

OrderIdOrderId

AOPDRequest AOPDRequest

AOPDResponse

Unique Plan Id

Start Plan-

The communication between BE and BW is done through JMS queues

The communication between BW and iPC is done through JMS queues

The communication between BW and iPE (and viceversa) make use of the iProcess BusinessWorks Server Plug -in

OrderRequest sent internally

Internal messages

Internal messages

OrderRequest

Name Type Multiple Obligatory Description

OrderHeader OrderHeaderType No Yes Element defined on order

level

OrderLines OrderLines No Yes Element defined for each

orderline in the order

OrderHeader


OrderRef String No Yes Reference of the Siebel

Order. Siebel Order id

customerRef String No Yes Customer id

requiredByDate DateTime No No Date by which order is

expected to be

completed

invoiceAddress GeographicAddressType No No Address for invoice

generation

deliveryAddress GeographicAddressType No No Address for order deliver

Notes String No No ATTRIBUTE

Slas SlasType No No Service level aggrement

UDFs UDFsType No No User defined field

GeographicAddress


Country String No Yes Country

StateOfProvince String No Yes StateOfProvince

urbanAddress UrbanPropertyAddress

Type

No No urbanAddress

supplementaryLocation String No Yes supplementaryLoca

tion

UrbanpropertyAddress


streetNr String No No streetNumber

streetName String No No streetName

streetType String No No streetType

Locality String No No Locality

Postcode String No No Postcode

SLAS


Sla SLAType Yes Yes Element

SLA


Id SLAType Yes Yes SLA id

UDFS


UDF UDFType Yes Yes Element

UDF


Name

String No Yes User defined

Field name

Value

String No Yes Value for the

above field

Orderlines


orderLine

orderLineType No Yes Complex

element

orderLine


lineNumber String No Yes Line Item id

productId String No Yes Clarify ProductId

Quantity String No Yes Quantity

UOM String No Yes UOM

orderLineAction NMTOKEN No Yes LineItem Action

requiredByDate

dateTime No No Date by which

lineitem is to be

delivered

Notes String No No Added message

UDFs

UDFsType No No User defined

fields

Slas

slasType No No Service level

aggrement

deliveryAddress

GeographicAddressType No No Address for

deliver

customerItemId String No No CustomerItem Id

characteristics

characteristicsType No No Extra

specification for

line item

Characteristics


characteristic characteristicType Yes Yes Element

characteristicsType


characteristicName String No Yes characteristicName

characteristicDesc String No Yes characteristicDesc

characteristicValues characteristicValuesType No Yes characteristicValues

characteristicsValuesType


characteristicValue characteristicValueType Yes Yes Element

characteristicsValueType


charValueName String No Yes charValueName

charValueType String No Yes charValueType

charValue String No No charValue

charValueFrom String No No charValueFrom

charValueTo String No No charValueTo

Sample Order XML:

<?xml version="1.0" encoding="UTF-8"?><jsx2:Order xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:jsx1="http://www.tibco.com/AFF/OM/services" xmlns:jsx2="http://www.tibco.com/AFF/classes/order" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<jsx2:OrderHeader><jsx2:CustomerID>ORG_ACME_CORP</jsx2:CustomerID><jsx2:SubscriberID>S200030</jsx2:SubscriberID><jsx2:SubmittedDate>2009-05-11</jsx2:SubmittedDate><jsx2:InvoiceAddress>

<jsx2:AddressLine1>1290 Sed St.</jsx2:AddressLine1><jsx2:Locality>Everett</jsx2:Locality><jsx2:Region>Fl.</jsx2:Region><jsx2:PostCode>A2R 3K1</jsx2:PostCode><jsx2:Country>Anguilla</jsx2:Country>

</jsx2:InvoiceAddress><jsx2:DeliveryAddress>

<jsx2:AddressLine1>1290 Sed St.</jsx2:AddressLine1><jsx2:Locality>Everett</jsx2:Locality><jsx2:Region>Fl.</jsx2:Region><jsx2:PostCode>A2R 3K1</jsx2:PostCode><jsx2:Country>Anguilla</jsx2:Country>

</jsx2:DeliveryAddress><jsx2:UDFs>

<jsx2:UDF><jsx2:Name>HEADER_UDF</jsx2:Name><jsx2:Value>header-udf-value</jsx2:Value>

</jsx2:UDF></jsx2:UDFs>

</jsx2:OrderHeader><jsx2:OrderDetails>

<jsx2:OrderLines><jsx2:OrderLine>

<jsx2:LineNumber>1-LI01</jsx2:LineNumber><jsx2:SubscriberID>S200030</jsx2:SubscriberID><jsx2:ProductID>LINEA_MOVIL</jsx2:ProductID><jsx2:Quantity>1</jsx2:Quantity><jsx2:UOM>-</jsx2:UOM>

<jsx2:OrderLineAction>PROVIDE</jsx2:OrderLineAction>

<jsx2:UDFs><jsx2:UDF>

<jsx2:Name>itemSpecId</jsx2:Name><jsx2:Value>TUC000</jsx2:Value>

</jsx2:UDF><jsx2:UDF>

<jsx2:Name>action</jsx2:Name><jsx2:Value>PROVIDE</jsx2:Value>


<jsx2:Name>MSISDN</jsx2:Name><jsx2:Value>677838383</jsx2:Value>


<jsx2:Name>RECORD_STATUS</jsx2:Name><jsx2:Value>ACTIVE</jsx2:Value>


<jsx2:Name>CIMAGEURL</jsx2:Name>

<jsx2:Value>http://localhost:8080/images/default.jpg</jsx2:Value></jsx2:UDF><jsx2:UDF>

<jsx2:Name>PRODUCTIDEXT</jsx2:Name><jsx2:Value>NULL</jsx2:Value>


</jsx2:OrderLine><jsx2:OrderLine>

<jsx2:LineNumber>1-LI02</jsx2:LineNumber><jsx2:SubscriberID>S200030</jsx2:SubscriberID><jsx2:ProductID>PLAN</jsx2:ProductID><jsx2:Quantity>1</jsx2:Quantity><jsx2:UOM>-</jsx2:UOM>

<jsx2:OrderLineAction>PROVIDE</jsx2:OrderLineAction><jsx2:UDFs>

<jsx2:UDF><jsx2:Name>LinkID</jsx2:Name><jsx2:Value>S200030</jsx2:Value>


</jsx2:OrderLine><jsx2:OrderLine>

<jsx2:LineNumber>1-LI03</jsx2:LineNumber><jsx2:SubscriberID>S200030</jsx2:SubscriberID><jsx2:ProductID>DESCUENTO</jsx2:ProductID><jsx2:Quantity>1</jsx2:Quantity><jsx2:UOM>-</jsx2:UOM>

<jsx2:OrderLineAction>PROVIDE</jsx2:OrderLineAction><jsx2:UDFs>

<jsx2:UDF><jsx2:Name>PORCENTAJE</jsx2:Name><jsx2:Value>5</jsx2:Value>


</jsx2:OrderLine>

</jsx2:OrderLines></jsx2:OrderDetails>

</jsx2:Order>

1.3.1.2 Duplicate Detection in iPC

Once order is received in IPC first of all a validation for duplicacy of the order is checked.Duplicate

management will be performed in order to make sure that the same order is not processed multiple times

in iPC/iPE.If the order is a duplicate one, a case of the duplicate error handler procedure will be started

and it logs in a log file and the order will be discarded.If and only if the order is a new one, then only a

case of the Fulfillment procedure is started in iPE and it further process the order.

Duplicate Management approach and Implementation

We will set orderAmendment.enabled property to false in the Appconfig.xml which is located in <Web

Server Home directory>\server\default\conf\appframeworks as mentioned below:

<setting>ok ok<name>orderAmendment.enabled</name><value>false</value>

</setting>

We will have a Duplicate Order Error Handler procedure- IALDOERR in iPE and the name of this

procedure will be configured in the OrchExceptionHandlerConfig.properties file which is located in <Web

Server Home directory>\server\default\conf\appframeworks folder. This procedure will be publishing the

duplicate order details to the EMS queue: VF.IAL.Queue.Error which is consumed by Common Error

Handling Framework BW process. Please refer section1.4.4.1 for the BW process for the error handling

framework

Below is the relevant part of the OrchExceptionHandlerConfig.properties file

## handler for staffware order amendment exceptionsamendDisabledException.className=com.staffware.frameworks.base.exception.handler.StaffwareExceptionHandleramendDisabledException.sw.procName=IADOERRamendDisabledException.sw.description=Duplicate Order WarningamendDisabledException.sw.userName=ipeadminamendDisabledException.sw.fieldName=WARNING

amendDisabledException.sw.fieldType=MEMO_TYPE

Please refer Dulpicate order error handle procedure for the iPE sub procedure.

1.3.1.3 Fulfillment/Execution Plan generation using AOPD

IPC is in charge of the plan orchestration and iPE is in charge of executing the tasks. The tasks

represented in the fulfillment plan require defining different objects inside IPC and IPE. IPE define

procedures that contain all the logic to execute the tasks. IPC define the process components that

references one IPE procedure and have additional information relevant for the execution (like the duration

of the task, jeopardy conditions, etc.). Finally, IPC defined plan fragments which are execution plan

templates. This plan fragments are assigned to each task in the fulfillment plan (the AOPDRequest). The

plan fragments defined will contain only one process component.

IPC Plan Fragment

IPC Process component

IPE Procedure

The responses required to send back to Siebel per line item will be managed by IPC, this means the last

task in the plan for an order line item will be in charge to call a BW process that sends a the response to

Siebel. Taking this into account, there will be defined three IPE procedures:

1.3.1.4 Process Component

Process components are responsible for the execution of the tasks to achieve the goal of an order.

Process components are part of execution plan and are associated an iProcess subprocedure. Basically

process component acts as a wrapper for the iProcess subprocedure. It consists of:

• Input and output data

• Milestones

• Resource requirements

Input and Output Data

iProcess procedures are created with’field payloads’ that contain the input and output data consumed or

provided by each EAI Orchestration step in a process component. So this is the data exchange between

iProcess procedure and iProcess conductor.

Milestones and Dependencies:

A milestone in a process component is a point in the underlying process which can be dependent on

another event or another milestone in some way.

Milestones arise while considering the inputs and outputs of each activity. For example, the output of the

exchange connection: provide process component may be an exchange ID. It could be that another

activity requires the exchange ID as input. Both of these activities would become milestones, and the

exchange ID part of the process signature.

Milestones may also arise from a significant activity in the process that has to be synchronized with other

activities. For example, suppose in the process component there is an expensive activity that should not

be canceled once it begins. In that case, this activity should be made a milestone near the end of the

process component and have it depend on the other milestones finishing.

In IAL since we have three iProcess procedures, so we will have three process components for executing

all tasks. We will be using iProcess conductor web interface to create process components.

Steps to create process components:

Log into iPC web interface with appropriate credentials.

TIBCO iProcess Conductor > Managed Object Maintenance > Process Components

click on create

In the new window that is displayed, click on Add a new Process Version button

Choose PCGEN from the list of the iProcess procedures displayed to create the generic process

component.

Then complete the below details in the window displayed below and click done.

In Valid From, choose today’s date

Save the process component

Repeat the above process to create Dummy process component for PCDUMMY iProcess procedure and

Last process component for PCLAST iProcess subprocedure. . The following table shows the configured

information for the three process components:

Process Component PC_GENERIC PC_LAST PC_DUMMY

Component ID PC_GENERIC PC_LAST PC_DUMMY

Description of Process

component

Generic Process

Component

Last Task Process

Component

Dummy Task Process

Component

Originator TBD TBD TBD

AssociatedI_PE

subprocedure

PCGEN PCLAST PCDUMMY

Description of IPE

subprocedure

Generic PC component

procedure

Last Task PC

procedure

Dummy Task PC

procedure

Major version TBD TBD TBD

Minor version TBD TBD TBD

Exception Handler IPERROR IPERROR IPERROR

Process

Milestone

Start Start Milestone Start Milestone Start Milestone

End End Milestone End Milestone End Milestone

Overall

schedule

Typical

duration

TBD TBD TBD

Max allowed

duration

TBD TBD TBD

1.3.1.5 Plan Fragments/Execution Plan template

Plan fragments are execution plan templates that can be use as building blocks in AOPD.Using such fragments makes it easier to develop an execution plan that will fulfill the order. Multiple plan fragments can be combined to form one consolidated plan which then fulfills the order. These plan fragments consists of process components.

In IAL based on the three process components we will be creating three plan fragments as follows: Generic plan fragment Dummy plan fragment Last plan fragment

Steps to create plan fragments:

Log into iPC web interface with appropriate credentials.

TIBCO iProcess Conductor > Managed Object Maintenance > Execution Plans

click on create

The Execution Plan Designer window appears

Double click on the row with the message "<double-click to set plan header>"

In the new window that is displayed, Enter the following:

o Execution Plan ID: IAL_GEN_EP_01

o Description: Plan fragment for generic component

Click OK.

Now to add the earlier created generic process component in the plan fragment, Click Insert a

new plan task in the execution plan creation window displayed.

Click on the left-most icon (Insert a new Plan Task)

Choose PC_GENERIC from the list (click on the row)

Click OK

The component is added as a Task in the execution plan

Expand it to see the details and see the duration for this process .

Click on the save button to save the plan.

Click the button shown to validate the plan and release it.

Click OK .

The plan status changes to Pending.

Now change the Plan status to Template.

Repeat the above steps for creating plan fragments for Dummy and last process components

respectively. . The following table shows the configured information for the three plan fragments.

Execution Plan ID IAL_GEN_EP_01 IAL_LAST_EP_02 IAL_DUMMY_EP_03

Description Generic Plan fragment Last Task Plan fragment Dummy Task Plan

Fragment

Process Component

ID

PC_GENERIC PC_LAST PC_DUMMY

1.3.1.6 AOPD Request

An execution or fulfillment plan is a collection of the activities that need to be completed to fulfill a

customer order. Execution plans are usually instantiated from execution plan templates that specify how

the process components should be arranged to fulfill the order. If no suitable template is available to meet

a particular order An execution plan or execution plan template consists of the following:

• Plan tasks and their associated process components• Actions• Dependencies

Execution plan can be created manually (Static) or dynamically at run time. IPC provide AOPD framework

for automatically generation of execution Plan. Automatic execution plan development (AOPD) enables to

automate the process of creating these execution plans. AOPD enables to create dynamic execution

plans using plan fragments - which are execution plan templates for parts of the overall plan – as building

blocks.

In IAL AOPD is used for fulfillment/execution plan generation. An AOPD request xml is generated based

on the AOPD request schema defined by iPC. This AOPD request xml is sent on the preconfigured EMS

queue in IPC (queue/AOPDProcessQueue). IPC will generate the AOPD response, detailed execution

plan for that order on basis of the AOPD request and referring the order xml. iPC will then send the AOPD

response to the preconfigured queue "queue/AOPDResponseQueue" and will start the orchestration of

the order on basis of that plan.

AOPD Request: AOPD request is basically prototype or template of the Execution plan upon which actual

execution plan for the particular order is generated. AOPD request is based on the pre defined AOPD

schema structure in iPC.

AOPD request schema.

AOPDRequest


OrderID String No Yes This is the primary key of the order

for which the AOPD request is

generated.

Originator String No Yes Originator of the AOPD request

Items AOPDItemsType No Yes Complex Element containg tasks

AOPDItems


Item AOPDItemType Yes Yes Element for each task

AOPDItem


TaskID String No Yes The task ID of the summary group

that will be created.

This ID must be unique within the

scope of this request.

Description String No No This is an optional element used to

describe this task.

planFragmentUniqueId String No Yes The unique ID of the plan to be

imported as part of the summary

group. The plan must exist in the

iProcess Conductor database

before submiting the

Request.

Udfs UDFsTyp

e

No No Specifies the User-Defined Fields

for this item. Through this, custom

user information can be passed to

the generated plan.

orderLineIds orderLine

IdsType

No No Line Item Id to which this task

belongs to.

Dependencies AOPDDe

pendenci

esType

No No Complex element containing

dpendency element.

Dependency


Time AOPDTimeType No Yes Complex Element

Point AOPDPointType No Yes Complex Element

AOPDTime


Type String No Yes Type of dependencies eg. Must

Start On dependencies , Start

No Earlier Than dependencies

timeDelta Long No No The time in milliseconds,

measured from plan activation,

that the milestone or summary

group should start execution.

absoluteTime dateTime No No The absolute time when the

milestone or summary group

should begin executing

consequentialActions JeopardySuperType No No Complex element

Point


timeDelta Long No No The time in milliseconds,

measured from plan

Activation, that the

summary group should

wait after the

dependency is satisfied.

TaskID String No Yes The ID of the 'dependent

on' summary group.

JeopardySuper


Def JeopardyDefType Yes No Complex element

containing type and

action element.

JeopardyDefType


type String No Yes The jeopardy configuration for this

dependency if the milestone or summary

group does not start at the configured date

and time.

This can be one of:

• section.THRESHOLD: Event generated when the time has passed and the milestone or summary

group has not started execution.• section.PREDICTION_CROSSOVER_ UP: Event generated when the dependency is predicted to be violated in the upward direction.• section.PREDICTION_CROSSOVER_ DOWN: Event generated when the dependency is predicted to be violated in the downward direction.

action

s

ConsequentialActi

onsType

No Yes Complex Element containing action element.

ConsequentialActions

Name Type Multiple ObligatoryDescription

Action String Yes No The action to be taken

when the particular

jeopardy event

described above is

detected. This can be

one of:

•SUSPEND_PLAN:

Suspend the plan.

• JMS_MESSAGE: Send

a JMS message. This

will be sent out to the

IPCJeopardyTopic.

• WORK_ITEM: Start an

iProcess Engine

Corrective action case.

Sample AOPD request XML

<?xml version="1.0" encoding="UTF-8"?><ns0:aopdRequest xmlns:ns0="http://www.staffware.com/frameworks/gen/valueobjects"> <ns0:orderId>ORD1000234</ns0:orderId> <ns0:originator>AOPDTest</ns0:originator> <items xmlns="http://www.staffware.com/frameworks/gen/valueobjects"> <item> <taskId>TSK-01</taskId> <description>TEST-09-15</description> <planFragmentUniqueId>EP_001</planFragmentUniqueId> <udfs> <UDF> <name>itemSpecId</name> <value>TUC01</value> </UDF> <UDF> <name>action</name> <value>Add</value>

</UDF> <UDF> <name>MSISDN</name> <value>123456</value> </UDF> </udfs> <orderLineIds> <orderLineId>LI-01</orderLineId> </orderLineIds> </item> <item> <taskId>TSK-02</taskId> <description>TEST-09-24</description> <planFragmentUniqueId>EP_001</planFragmentUniqueId> <udfs> <UDF> <name>itemSpecId</name> <value>TUC01</value> </UDF> <UDF> <name>action</name> <value>PROVIDE</value> </UDF> <UDF> <name>MSISDN</name> <value>164656</value> </UDF> </udfs> <orderLineIds> <orderLineId>LI-01</orderLineId> </orderLineIds> <dependencies> <dependency> <point> <taskId>TSK-01</taskId> </point> </dependency> </dependencies> </item> <item> <taskId>TSK-03</taskId> <description>TEST-09-24</description> <planFragmentUniqueId>EP_001</planFragmentUniqueId> <udfs> <UDF> <name>itemSpecId</name> <value>TUC01</value> </UDF> <UDF> <name>action</name> <value>PROVIDE</value> </UDF> <UDF> <name>MSISDN</name> <value>164656</value> </UDF> </udfs> <orderLineIds> <orderLineId>LI-01</orderLineId> </orderLineIds> <dependencies> <dependency> <point> <taskId>TSK-02</taskId> </point> </dependency> </dependencies> </item> <item> <taskId>TSK-001</taskId> <description>TEST-09-24</description>

<planFragmentUniqueId>EP_001</planFragmentUniqueId> <udfs> <UDF> <name>itemSpecId</name> <value>TUC01</value> </UDF> <UDF> <name>action</name> <value>PROVIDE</value> </UDF> <UDF> <name>MSISDN</name> <value>164656</value> </UDF> </udfs> <orderLineIds> <orderLineId>LI-02</orderLineId> </orderLineIds> dependencies> <dependency> <point> <taskId>TSK-03</taskId> </point> </dependency> </dependencies> </item> <item> <taskId>TSK-002</taskId> <description>TEST-09-24</description> <planFragmentUniqueId>EP_001</planFragmentUniqueId> <udfs> <UDF> <name>itemSpecId</name> <value>TUC01</value> </UDF> <UDF> <name>action</name> <value>PROVIDE</value> </UDF> <UDF> <name>MSISDN</name> <value>164656</value> </UDF> </udfs> <orderLineIds> <orderLineId>LI-02</orderLineId> </orderLineIds> <dependencies> <dependency> <point> <taskId>TSK-001</taskId> </point> </dependency> </dependencies> </item> </items></ns0:aopdRequest>

1.3.1.7 AOPD Response

AOPD response is the execution Plan genetrated for an order based on the AOPD request. AOPD

response has all the details required to execute an order for achieving the goals. This includes various

subprocedures to be grafted for differents items of the order, dependencies between different tasks and

line items, fulfillment procedures case number instantiated for the order and jeopardy management

details.

AOPD Response Schema

1.3.2 iPE Implementation

1.3.2.1 iPE Fulfillment Procedure (IALFULFI)

Once order is received in iPC, It will identify a Fulfillment procedure in iPE based on the order, to

accomplish the goals of an order. For IAL we will have one common Fulfillment procedure for all new

orders. Once the order is received by iPC, it will automatically store the order in the database and

instantiates a case of the Fulfillment procedure

Fulfillment procedure contains the following:

Steps or sub procedures to determine order Feasibility, Order Plan Development and Order Plan

Execution.

An Event step to to facilitate Execution Plan ID to be passed back to the fulfilment procedure. This

event step name is referenced in the EAI Orchestration step that starts the execution plan.

If an order fails any of the three states (Feasibility, Order Plan Development, Order Plan Execution)

there must be ways to gracefully terminate the order processing.

Please see the screen shot of the iPE Fulfillment Procedure below:

Flow of the Fulfillment procedure will be:

Case will move to the feasibility step to validate the feasibility of an order. In IAL, this step will just

set the status of the order as feasible, as we are not performing any validation in this layer.

Order will move to Order plan development step. It will trigger a BW process which in turn will

send a request to BE to send the AOPD request (Fulfillment plan).

This eai BW call is delayed release call; Delayed release will make sure that case will not

proceed further until a complete delayed release instruction is sent from external system.

So once BW will receive the AOPD response from iPC it will sent the complete delayed release

instruction to ipe together with unique plan id generated for the fulfillment plan of the order. This

will also be a signal for iPE to start the execution of the plan.

Case will then move to SETOPE step which will set the status of the order to execution.

Then case will move to STARTOPE which will set the status of the fulfillment plan as Plan

started.

Then case will instantiate the graft step. This is where, iPC again took the control and it will

launch and graft the sub procedures corresponding to each process component. These process

components will be mentioned in the fulfillment plan generated by iPC.

In case of any eaicall fails, it will automatically retry the call for fixed no of intervals based on the

value of SW_RETRYCOUNT. If eai call still fails, a work item to AO is initiated. AO will rectify it

manually and then release the work item. A script is invoked on the release of work item which

will relaunch the case from where it errored out.

1.3.2.2 IPE Subprocedures for Process Components

IPC is in charge of the plan orchestration and iPE will be executing the tasks. The tasks represented in

the fulfillment plan require defining different objects inside IPC and IPE. IPE define sub procedures that

contain all the logic to execute the tasks.

IPC define the process components that references one IPE procedure and have additional information

like the duration of the task, jeopardy conditions relevant for the execution. Finally, IPC defined plan

fragments which are execution plan templates. This plan fragments are assigned to each task in the

fulfillment plan (the AOPDRequest).

In IAL we have defined three iPE sub procedures: General, Dummy and the Last.

For the dummy tasks We defined an IPE subprocedure which represents the dummy task in

the execution plan.It is possible one line item is provisioned inside another so, a dummy task is

created in the AOPD request. The purpose of this procedure is to send a response back to Siebel

by invoking a BW process. Please refer section 1.3.2.2.2 for the dummy task process component

procedure.

For the last task of one order line We defined and IPE subprocedure which represents the

last task for each order line in the execution plan, no matter if it is a Serpa call or not (typically, it

will not be a Serpa call). This procedure will be in charge of sending a message to ADM (by

invoking a BW process) and, as it is the last task for the order line, to send a response back to

Siebel by invoking a BW process. At the end, it will change the status of its order line to

“Complete”. Please refer section 1.3.2.2.3 for the last task process component procedure

For the rest of the tasks We defined an IPE subprocedure for the rest of the task in the

execution plan, no matter if they are Serpa call or not. This procedure will be in charge of sending

a message to ADM by invoking a BW process. Please refer section 1.3.2.2.1 for the generic

process component procedure

Corresponding to these three sub procedures we will have three process components and three

execution plan template.

1.3.2.2.1 iPE Sub procedure for Generic Process Component (PCGEN)

This is the generic IPE sub procedure which is responsible for sending the event message to the

corresponding proxy ADM services (TIBCO/Tuxedo) by invoking the Generic BW Process (refer BW

communication with ADM).

IPE executes the tasks by invoking a BW process which is in charge of sending the message to the ADM

systems. The most important information exchanged between IPE and the Generic BW Process is

XML_UNIQUEID which is the identifier of the XML previously stored in the data base during the Data

Mapping in BE (for further details, see section. Data mapping) With this identifier, the BW process

searches for the XML in the table TBL_MAPPING and also additional information required to send the

event in the table TBL_EVENT_INFO, like the subject to publish, etc. Then, the event is sent to ADM

systems.

Please see the screen shot of the Sub procedure for Generic Process Component below

Flow of the Generic sub procedure will be:

Flow start with the START MILESTONE EAI Orchestrator step used to sequence the process

components in the execution plan. Message type used is Activate Sink which defines a milestone

of the plan and instructs the TIBCO iProcess Conductor to wait for the completion of all activities

upon which this milestone depends before releasing this step.

Next case will move to LINESTAT step, where this step will return its status.

In case the status returned is CANCELLED..

o Case will move to the END orchestration step, where it will end the task.

If the LINE_STATUS is PENDING it will be moved to the condition where it will be checked

whether the event is SERPA call or NON SERPA call.

Serpa Call:

In case of SERPA call it will trigger the BW process. This EAI BW call is delayed release call, it

will make sure that case will not proceed further until a complete delayed release response sent

from external system.

o If a technical error comes in triggering the EAI BW step it will retry for specified number of

time and interval which is configured as SW_QRETRYCOUNT and RETRYINTERVAL in

the condition.

o If the specified number or interval exceeds it will be routed to the manual AO step for

manual intervention. AO will manually rectify the errors and will retry the case from the

same point. A script is invoked on the release of work item which will relaunch the case

from where it errored out.

If there is no any technical error,BW Process is invoked successfully and it will return the

response to iPE layer through complete delayed release instruction.

BW response returned to iPE layer can be either Tech Response KO or Tech response OK and

functional response.

Case will move to the condition where it will be checked whether (TECH_ACK is success (OK)

and functional response ok/ko) OR TECH_ACK is Failure. (KO)

o If TECH_ACK fails (KO)

it will be again routed to manual AO step for manual intervention. AO will manually

rectify the errors and will retry the case from the same point. A script is invoked on

the release of work item which will relaunch the case from where it errored out.

o In case Tech Resp OK and FUN_RES is OK

it will be moved to END MILESTONE EAI Orchestrator step to instructs the TIBCO

iProcess Conductor that the process component has executed and is complete.

o If the FUN_RES is KO

it will be moved to CANCEL OREDER LINE EAI Order step where LINE_STATUS is

set to cancel.

Case will then proceed to GETDEPEN EAI script step which is used to retrieve all the

dependent line items.

These dependent line items will be sent to sub procedure through CANLINE

DYNAMIC sub procedure call. In which these dependent line items will be cancelled.

Then it will be moved to END MILESTONE EAI Orchestrator step to instruct the TIBCO iProcess

Conductor that the process component has executed and is complete

Non Serpa Call:

In case of NON SERPA call it will trigger the BW process .. This EAI BW call is immediate release

call.


time and interval which is configured as SW_QRETRYCOUNT and RETRYINTERVAL in the

condition.

o If the specified number or interval exceeds it will be routed to the manual AO step for manual

intervention. AO will manually rectify the errors and will retry the case from the same point. A

script is invoked on the release of work item which will relaunch the case from where it

errored out.

In case of no technical error, BW process is successful invoked and a response is returned to iPE

layer as TECH_ACK .

If TECH_ACK fails (KO)

it will be again routed to manual AO step for manual intervention. AO will manually

rectify the errors and will retry the case from the same point.

In case TECH_ACK is OK



1.3.2.2.2 iProcess SubProcedure for Dummy process component (PCDUMMY)

This is the IPE subprocedure which represents the "NO FLOW" in the execution plan. This sub procedure

will be executed only when there is a "NO FLOW" for the particular task

Please see the screen shot of the Sub procedure for Dummy Process Component below

Dummy task Sub procedure flow:






In case the status returned is CANCELLED, the task will move to the CANCRESP EAI step

where it will trigger the RM process to send the line item cancelled response to Seibel.

If the LINE_STATUS is PENDING, case will move to ORDER LINE_STATUS COMPLETED step

to set the status of the line item as completed.

Case will move to the COMPRESP EAI step where it will trigger the RM process to send the line

item completed response to Seibel.


Conductor that the process component has executed and is complete.

If some system error is during BW process invocation, eai step will automatically retry using

SW_RETRYCOUNT and RETRYTIMEINTERVAL parameters. These two parameters are

configurable parameters in ipe.

If it is still a failure, then the task will move to the AO step which will check the error manually that

requires manual intervention which will further move to the End orchestration step. A script is

invoked on the release of work item which will relaunch the case from where it errored out.

1.3.2.2.3 iPE Subprocedure for Last Task (PCLAST)

This is the IPE subprocedure which represents the last task in the execution plan, no matter if it is a

Serpa call or not (typically, it will not be a Serpa call).

This sub procedure will be executed only after the completion of all the tasks in an order line. This

procedure will be in charge of communicating to ADM to invoke the end system service for task fulfillment.

Since, it is the last task for the order line,

It will also send a response back to Siebel by invoking a BW process. At the end, it will change the status

of its order line to “Complete”.

Please see the screen shot of the Sub procedure for Last Task Process Component below

Last task Sub procedure flow:






In case the status returned is CANCELLED, the task will.

o An eai step in initiated to send line item cancelled response to seibel

o Case will move to the END orchestration step, where it will end the task.

If the LINE_STATUS is PENDING it will be moved to the condition where it will be checked

whether the event is SERPA call or NON SERPA call.

Serpa Call:

In case of SERPA call it will trigger the BW process. This EAI BW call is delayed release call, it

will make sure that case will not proceed further until a complete delayed release response sent

from external system.

o If a technical error comes in triggering the EAI BW step it will retry for specified number

of time and interval which is configured as SW_QRETRYCOUNT and RETRYINTERVAL

in the condition.





If there is no any technical error, BW Process is invoked successfully and it will return the

response to iPE layer through complete delayed release instruction.

BW response returned to iPE layer can be either Tech Response KO or Tech response OK and

functional response.

Case will move to the condition where it will be checked whether (TECH_ACK is success (OK)

and functional response ok/ko) OR TECH_ACK is Failure. (KO)

o If TECH_ACK fails (KO)

It will be again routed to manual AO step for manual intervention. AO will

manually rectify the errors and will retry the case from the same point.

o In case Tech Resp OK and FUN_RES is OK

Case will be routed to ORDER LINE_STATUS COMPLETED EAI Order step

where LINE_STATUS is set to complete.

EAI BW call is triggered to invoke RM to send the response to the Siebel for

particular line item.

o If the FUN_RES is KO

It will be moved to CANCEL OREDER LINE EAI Order step where

LINE_STATUS is set to cancel.

Case will then proceed to GETDEPEN EAI script step which is used to retrieve

all the dependent line items.

These dependent line items will be sent to sub procedure through CANLINE

DYNAMIC sub procedure call. In which these dependent line items will be

cancelled.

An EAI BW call is triggered to invoke RM to send the response to the Siebel for

particular line item



Non Serpa Call:

In case of NON SERPA call it will trigger the BW process. This EAI BW call is immediate release

call.


time and interval which is configured as SW_QRETRYCOUNT and RETRYINTERVAL in

the condition.





If there is no any technical error and the case is back to IPE layer it will be moved to the condition

where it will be checked whether TECH_ACK is success (OK).

If TECH_ACK fails (KO)

It will be again routed to manual AO step for manual intervention. AO will

manually rectify the errors and will retry the case from the same point.

In case TECH_ACK is OK

Case will be routed to ORDER LINE_STATUS COMPLETED EAI Order step

where LINE_STATUS is set to complete.

EAI BW call is triggered to invoke RM to send the response to the Siebel for

particular line item .

Then it will move to END MILESTONE EAI Orchestrator step to instruct the TIBCO iProcess Conductor

that the process component has executed and is comple

1.3.2.2.4 iProcess Error handling subprocedure(IPERROR)

Procedure Flow:

The case starts when an error occured in IPC during order request submission/plan execution etc.

In triggering the EAI BW step it will retry for specified number of time and interval which is configured as SW_QRETRYCOUNT and RETRYINTERVAL in the condition.

In case if the specified number or interval exceeds it will be routed to Script TASK which will be used to write down the error messages to the file.

In case if the specified number or interval doesnot exceed a BW process will be called to publish the error messages on the JMS queue.

Case will then move to condition error type is Retiable or Non Retriable.

If the error type is Retriable it will be routed to the manual Task for AO management to fix the issue.

The Non Retriable errors are not recoverable. The case is directly get terminated.

1.3.2.2.5 iProcess SubProcedure parameter Template

A predefined input/output parameter template will be defined for iPE subprocedures related to different

process components. These input and output parameters will be used during grafting of different iProcess

sub procedures.

Sub Procedure template for Process components

Name Type Multiple Obligato

ry

Description

SWO_ORDERREF String No Yes Seibel Order id

SWO_ORDERNUMBER String No Yes iPC OrderId

SWO_TASKID String No Yes TaskId for different

events/tasks

ORDER_LINEID String No Yes LineItem Id

SWO_PLANID String No Yes Fulfilment Plan ID

SWO_EXCEPTION String No Yes Order Exception

SWO_ACTION String No Yes Action Code for the

Order

1.3.2.2.6 Plan Fragment Interface – IPE-BW Interface

This is the interface for the communication between IPE sub procedures for Generic Process components and BW. The communication between BW and IPE (and vice versa) makes use of the iProcess BusinessWorks Server Plug-in.

Plan Fragment InterfaceName Type Multiple Obligatory Description

SWO_ORDERREF String No Yes Siebel Order ID

SWO_ORDERNUMBER String No Yes IPC Order ID

SWO_TASKID String No Yes Task ID

ORDER_LINEID String No Yes Order line item ID

XML_UNIQUEID String No Yes XML Unique ID to

fetch the XML for

the event

COMMISSIONABLE Boolean No YES Flag to indicate

whether

commissionable

or not

SERPA_FLAG Boolean No Yes Flag to indicate

whether Serpa or

Non Serpa event

RETRIABLE_INTERFACE Boolean No Yes Flag to indicate

whether retriable

or not

DELAYED_RELEASEID String No No Correlation id

send from iPE to

complete the

delayed release

iProcess Conductor and iProcess Engine Implementation

Documents

description order

order ipe

mapping of ipc order

order reception order

orderref type string

order level element

string value

siebel order message