Date post: | 01-Dec-2014 |
Category: |
Documents |
Upload: | itipharma7510 |
View: | 123 times |
Download: | 9 times |
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
Name Type Multiple Obligatory Description
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
Name Type Multiple Obligatory Description
Country String No Yes Country
StateOfProvince String No Yes StateOfProvince
urbanAddress UrbanPropertyAddress
Type
No No urbanAddress
supplementaryLocation String No Yes supplementaryLoca
tion
UrbanpropertyAddress
Name Type Multiple Obligatory Description
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
Name Type Multiple Obligatory Description
Sla SLAType Yes Yes Element
SLA
Name Type Multiple Obligatory Description
Id SLAType Yes Yes SLA id
UDFS
Name Type Multiple Obligatory Description
UDF UDFType Yes Yes Element
UDF
Name Type Multiple Obligatory Description
Name
String No Yes User defined
Field name
Value
String No Yes Value for the
above field
Orderlines
Name Type Multiple Obligatory Description
orderLine
orderLineType No Yes Complex
element
orderLine
Name Type Multiple Obligatory Description
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
Name Type Multiple Obligatory Description
characteristic characteristicType Yes Yes Element
characteristicsType
Name Type Multiple Obligatory Description
characteristicName String No Yes characteristicName
characteristicDesc String No Yes characteristicDesc
characteristicValues characteristicValuesType No Yes characteristicValues
characteristicsValuesType
Name Type Multiple Obligatory Description
characteristicValue characteristicValueType Yes Yes Element
characteristicsValueType
Name Type Multiple Obligatory Description
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"?><!-- 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: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: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 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
Name Type Multiple Obligatory Description
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
Name Type Multiple Obligatory Description
Item AOPDItemType Yes Yes Element for each task
AOPDItem
Name Type Multiple Obligatory Description
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
Name Type Multiple Obligatory Description
Time AOPDTimeType No Yes Complex Element
Point AOPDPointType No Yes Complex Element
AOPDTime
Name Type Multiple Obligatory Description
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
Name Type Multiple Obligatory Description
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
Name Type Multiple Obligatory Description
Def JeopardyDefType Yes No Complex element
containing type and
action element.
JeopardyDefType
Name Type Multiple Obligatory Description
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.
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
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:
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.
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:
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 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.
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.
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
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
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