1.

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.

BE OrderRequest

BW OrderRequest

iPC

iPE

OrderRequest sent internally Internal messages

Internal messages

OrderId

OrderId

AOPDRequest

AOPDRequest AOPDResponse Unique Plan Id

StartPlan

The communication between BE and BW is The communication between BW and done through JMS queues is done through JMS queues iPC The communication between BW and iPE viceversa (and ) make use of the iProcess BusinessWorks Server Plug -in

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.

OrderRequest Name OrderHeader Type OrderHeaderType Multiple No Obligatory Yes Description Element defined on order level Element defined for orderline in the order each

OrderLines

OrderLines

No

Yes

OrderHeader Name OrderRef Type String Multiple No Obligatory Yes Description Reference of the Siebel Order. Siebel Order id

customerRef requiredByDate

String DateTime

No No

Yes No

Customer id Date by which order is expected to be completed Address for generation invoice

invoiceAddress

GeographicAddressType

No

No

deliveryAddress Notes Slas UDFs

GeographicAddressType String SlasType UDFsType

No No No No

No No No No

Address for order deliver ATTRIBUTE Service level aggrement User defined field

GeographicAddress Name Country StateOfProvince urbanAddress Type String String UrbanPropertyAddress Type String Multiple No No No Obligatory Yes Yes No Description Country StateOfProvince urbanAddress

supplementaryLocation

No

Yes

supplementaryLoca tion

UrbanpropertyAddress Name streetNr streetName streetType Locality Postcode Type String String String String String Multiple No No No No No Obligatory No No No No No Description streetNumber streetName streetType Locality Postcode

SLAS Name Sla Type SLAType Multiple Yes Obligatory Yes Description Element

SLA Name Id Type SLAType Multiple Yes Obligatory Yes Description SLA id

UDFS Name UDF UDF Name Type String Name String Value No Yes Multiple No Obligatory Yes Description User defined Field name Value for above field the Type UDFType Multiple Yes Obligatory Yes Description Element

Orderlines Name Type orderLineType orderLine Multiple No Obligatory Yes Description Complex element

orderLine Name lineNumber Type String Multiple No Obligatory Yes Description Line Item id

productId Quantity UOM orderLineAction

String String String NMTOKEN dateTime

No No No No No

Yes Yes Yes Yes No

Clarify ProductId Quantity UOM LineItem Action Date by which lineitem is to be delivered Added message User fields defined

requiredByDate Notes String UDFsType UDFs slasType Slas GeographicAddressType deliveryAddress customerItemId String characteristicsType characteristics No No No No No No No No No No No No

Service level aggrement Address deliver for

CustomerItem Id Extra specification for line item

Characteristics Name characteristic Type characteristicType Multiple Yes Obligatory Yes Description Element

characteristicsType Name characteristicName characteristicDesc characteristicValues Type String String characteristicValuesType Multiple No No No Obligatory Yes Yes Yes Description characteristicName characteristicDesc characteristicValues

characteristicsValuesType Name characteristicValue Type characteristicValueType Multiple Yes Obligatory Yes Description Element

characteristicsValueType Name charValueName charValueType charValue charValueFrom charValueTo Type String String String String String Multiple No No No No No Obligatory Yes Yes No No No Description charValueName charValueType charValue charValueFrom charValueTo

Sample Order XML:

<?xml version="1.0" encoding="UTF-8"?> <!-- This order has 3 order lines for PRODUCT_VSRA, SERVICE_VSRA, VSRA_A1 --> <jsx2:Order xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAPENV="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:UDF> <jsx2:UDF> <jsx2:Name>MSISDN</jsx2:Name> <jsx2:Value>677838383</jsx2:Value> </jsx2:UDF> <jsx2:UDF> <jsx2:Name>RECORD_STATUS</jsx2:Name> <jsx2:Value>ACTIVE</jsx2:Value> </jsx2:UDF> <jsx2:UDF> <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:UDF> </jsx2:UDFs> </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:UDF> </jsx2:UDFs> </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:UDF> </jsx2:UDFs> </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 exceptions amendDisabledException.className=com.staffware.frameworks.base.exception.handler.Staffware ExceptionHandler amendDisabledException.sw.procName=IADOERR amendDisabledException.sw.description=Duplicate Order Warning amendDisabledException.sw.userName=ipeadmin amendDisabledException.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 Processcomponent 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 withfield 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 todays 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 Component ID Description of Process component Originator AssociatedI_PE subprocedure Description of subprocedure Major version IPE

PC_GENERIC PC_GENERIC Generic Component TBD PCGEN Process

PC_LAST PC_LAST Last Task Component TBD PCLAST Process

PC_DUMMY PC_DUMMY Dummy Task Process Component TBD PCDUMMY

Generic PC component procedure TBD

Last Task procedure TBD

PC

Dummy Task procedure TBD

PC

Minor version Exception Handler Process Milestone Overall schedule Start End Typical duration Max allowed duration

TBD IPERROR Start Milestone End Milestone TBD

TBD IPERROR Start Milestone End Milestone TBD

TBD IPERROR Start Milestone End Milestone TBD

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

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 Description

IAL_GEN_EP_01 Generic Plan fragment

IAL_LAST_EP_02 Last Task Plan fragment

IAL_DUMMY_EP_03 Dummy Task Fragment PC_DUMMY Plan

Process ID

Component

PC_GENERIC

PC_LAST

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 Name OrderID Type String Multiple No Obligatory Yes Description This is the primary key of the order for which the AOPD request is generated. Originator of the AOPD request Complex Element containg tasks

Originator Items

String AOPDItemsType

No No

Yes Yes

AOPDItems Name Item Type AOPDItemType Multiple Yes Obligatory Yes Description Element for each task

AOPDItem Name TaskID Type String Multiple No Obligatory Yes Description 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. 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.

planFragmentUniqueId

String

No

Yes

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. Line Item Id to which this task belongs to. Complex element dpendency element. containing

orderLineIds

orderLine IdsType AOPDDe pendenci esType

No

No

Dependencies

No

No

Dependency Name Time Point Type AOPDTimeType AOPDPointType Multiple No No Obligatory Yes Yes Description Complex Element Complex Element

AOPDTime Name Type Type String Multiple No Obligatory Yes Description Type of dependencies eg. Must Start On dependencies , Start No Earlier Than dependencies The time in milliseconds, measured from plan activation, that the milestone or summary

timeDelta

Long

No

No

group should start execution. absoluteTime dateTime No No The absolute time when the milestone or summary group should begin executing Complex element

consequentialActions

JeopardySuperType

No

No

Point Name timeDelta Type Long Multiple No Obligatory No Description 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 Name Def Type JeopardyDefType Multiple Yes Obligatory No Description Complex element containing type and action element.

JeopardyDefType Name type Type String Multiple No Obligatory Yes Description 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 Action Type String Multiple Yes Obligatory No Description 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.

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.

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. 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. 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.

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 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

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:

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, 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. 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.

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.

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: 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, the task will. o o An eai step in initiated to send line item cancelled response to seibel 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. 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.

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

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. 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 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

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.

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 Yes Yes Yes Description

SWO_ORDERREF SWO_ORDERNUMBER SWO_TASKID

String String String

No No No

Seibel Order id iPC OrderId TaskId for different events/tasks LineItem Id Fulfilment Plan ID Order Exception Action Code for the Order

ORDER_LINEID SWO_PLANID SWO_EXCEPTION SWO_ACTION

String String String String

No No No No

Yes Yes Yes Yes

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 Plugin. Plan Fragment Interface Name Type Multiple Obligatory Description SWO_ORDERREF SWO_ORDERNUMBER SWO_TASKID ORDER_LINEID XML_UNIQUEID String String String String String No No No No No Yes Yes Yes Yes Yes Siebel Order ID IPC Order ID Task ID Order line item ID XML Unique ID to fetch the XML for the event Flag to indicate whether

COMMISSIONABLE

Boolean

No

YES

commissionable or not SERPA_FLAG Boolean No Yes Flag to indicate whether Serpa or Non Serpa event Flag to indicate whether retriable or not Correlation id send from iPE to complete the delayed release

RETRIABLE_INTERFACE

Boolean

No

Yes

DELAYED_RELEASEID

String

No

No