Cat,
bad conditions for a successful MQWF project!
All experies tell that workflow projects will fail if designed by
unskilled persons.
I can't provide you with the required skill, I can only give you
references where to
look for further information. It definitely helps to use the MQWF
terminology so that
all persons are talking about the same things.
This is what I would translate from your business requirements into MQWF
terminology:
- You have persons (customers) that need to create an start an instance
(new order) of your new process template (project).
This can be done in a (C, C++, Java, COBOL) client program via API calls
or via the MQWF XML interface.
Either case allows you to pass data (orderID/userID) to the process.
I guess your existing project does it via the XML interface - not
because the data that are passed to the
process instance are in XML format, but because the XML interface does
not require an MQWF account.
- Your process needs to start activities automatically (Siebel backend)
and pass correlationIDs (customer business data) to it.
This can be done by automatic UPES activities. Basically the program
logic of an UPES it is up to you. MQWF provides the
framework for message handling and container (data) passing and
returning.
UPES activities are based on XML messages, too.
In my statements above I used all the keywords, you should use for further
investigations:
MQWF XML client interface, automatic activities, UPES framework
(SupportPac in 3.5, part of the product in 3.6),
process context (correlationID).
Use the MQWF Programming Guide, Redbooks and the SupportPacs available for
information retrieving.
You may also contact workflow@de.ibm.com for specific questions how things
work.
Good Luck!
Volker Hoss
IBM WebSphere WPS Development