Arnab
I'll take a shot at this..
In answer to questions
1: A Workflow ID number is a discrete "run" within the application. It will likely have a "document" and will act on that document. The "code" for that process can be managed in the graphical process modeler. I would also get familiar with the XML representation of the Business Process. You will need to understand that in some cases to be able to interpret the Instance Data of the job.
2a: Yes.. each individual instance will create a new Workflow ID number
2b: Take a look on the administrator's desktop at the menu Business Processes -> Monitor ->Advanced Search->Business Processes. On that search page you can look at an individual workflow ID, or you can select a Business Process from the list. You may wish to adjust the date/time range or other criteria, but if you press Go! in that section you will see all the instances of that business process within the time range.
2c: There is no way I'm aware of to look at a data source (EDI message, ODBC table, Flat File, XML message, idoc, and others) and see what business processes reference it. You would have to look in a variety of places, and it largely depends on how the data is accessed. For instance, if the incoming data is coming from the mailbox subsystem, there are routing rules that can be reviewed to see what mailbox entries are selected, then what business process is called. If it's coming from a file folder, then there is a list of file system adapters, and those will identify the business process called. If it's coming from an HTTP process, then HTTP adapters, etc. If it's standards based EDI there are also partner envelopes and contracts. You can also look at any list of business processes.. The Parent/Child column will be helpful.. keep clicking on the upward pointing arrows to find the process that called this one... where there are no more upward arrows you've reached the origin process.
2d: Yes, it's true. Take an ODBC table for instance... You could have an SQL statement selecting "new" rows in one process, and "updated" rows in another. Again there's no simple answer, and no unified view that I'm aware of.
In my mind naming conventions in SI are everything. I am careful to make sure that process names (adapter names, envelope names, XSLT's and Maps, etc) group like things together. It's the only visible documentation you can create within the system. I tend to use something like OrganizationID_ProcessIdentifier_Direction_Purpose_OptionalOtherInfo... so a BP might be LP_ASN_Outbound_ProcessBootstrap with a File system adapter of LP_ASN_Outbound_FileSystemAdapter_ServerX.myco.net and a Map of LP_ASN_Outbound_X12.856.004010_myPartnerName
Hope some of that helps...
(I'm looking forward to seeing what others say for this as well!)
------------------------------
Philip Catlin
------------------------------