| Author |
Message
|
| SandeepLathi |
 Posted: Mon Jun 19, 2006 10:07 pm Post subject: Reporting Based on Workflow Process Data |
 |
|
Newbie
Joined: 19 Jun 2006
Posts: 6
|
We have requirements to let users produce real time reports for in-progress and completed workflow processes. User inputs typically would be type of report, date range, Product Type etc. The reports needs to display information based on one or more work items like when was a work item created, when was it assigned, when was it checked out, how long did it take the user to complete the work etc. The users would want information to be presented like a typical report in UI and not like Monitor Business Measure report and want options like export to Xls/PDF, Printing, pagination etc.
We are using :
MQ Workflow 3.6
WBI Modeler 4.2.4
WBI Monitor 4.2.4 Fix Pack 3
What kind of solution would be most suitable to meet this? |
|
| Back to top |
|
 |
| SandeepLathi |
| Posted: Mon Jun 26, 2006 2:44 pm Post subject: Re: Reporting Based on Workflow Process Data |
|
|
Newbie
Joined: 19 Jun 2006
Posts: 6
|
| Has no one ever faces such requirements? |
|
| Back to top |
|
|
| jmac |
| Posted: Mon Jun 26, 2006 2:52 pm Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
From MQWF point of view (i.e NOT monitor) The information you need is in the audit trail which is documented in the Admin guide.
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| SandeepLathi |
| Posted: Mon Jun 26, 2006 4:14 pm Post subject: |
|
|
Newbie
Joined: 19 Jun 2006
Posts: 6
|
We thought about using AuditTrail. But there are following problems:
1. AuditTrail doesn't write container values. Only way to get container values would be to map them to GDC. But even GDC is written in BLOB format so parsing out intelligence would be need to built.
2. If I need to build my own UI using AuditTrail information I would need to set it to AuditToQueue and then start processing the messages through a custom message broker flow. This would be like trying to write Monitor.
3. I can't use #2, as other than these reports, default WBI monotor metric capturing cabaility is still required. So I'll have to set the AuditToDB only.
Given these updates, what are the solution options we have? |
|
| Back to top |
|
|
| vennela |
| Posted: Tue Jun 27, 2006 6:22 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| You don't have any solution because you need audit trail even for WBI Monitor |
|
| Back to top |
|
|
| sarasu |
| Posted: Tue Jun 27, 2006 6:36 am Post subject: |
|
|
Master
Joined: 02 Feb 2006
Posts: 229
|
| Hey..did you try anything in Modeler? There are few options for generating reports in Workbench 4.2.4 fixpack 3. We can also use modeler for generationg reports. |
|
| Back to top |
|
|
| koko |
| Posted: Tue Jun 27, 2006 10:13 am Post subject: |
|
|
Master
Joined: 26 Sep 2003
Posts: 206
|
| Quote: |
| Hey..did you try anything in Modeler? There are few options for generating reports in Workbench 4.2.4 fixpack 3. We can also use modeler for generationg reports. |
The reports you are speaking about are not the same as what the person here is looking for.
_________________
Thanks
Koko |
|
| Back to top |
|
|
| SandeepLathi |
| Posted: Tue Jun 27, 2006 12:17 pm Post subject: |
|
|
Newbie
Joined: 19 Jun 2006
Posts: 6
|
There are two options that options that we are looking at. If you have any suggestions/comments or another options, please respond:
1. Capture and Manage Reporting Data Outside Monitor:
In this solution option the process models would be updated to send a UPES message out at certain points during the process to an MQ enabled service that would take this data and write records to a database. A reporting application would use Actuate as its reports generator. Once the user selects the reporting options the Actuate server would make the necessary calls to the new database.
2. Use Actuate in combination with Monitor API calls:
In this approach a standard J2EE application will be developed that will give the user a UI to select their reporting options. Once the user selects their reporting options the application will post the request URL to Actuate to create the reports. The Report will execute query that a service layer will service. The service will make Java API calls to WBI Monitor to retrieve the monitor data and will also do any additional data manipulation necessary and return the result set back to Actuate.
For making the data go to monitor, we would set business measures in the process models. |
|
| Back to top |
|
|
| koko |
| Posted: Tue Jun 27, 2006 12:56 pm Post subject: |
|
|
Master
Joined: 26 Sep 2003
Posts: 206
|
I personally did not like WBI monitor. There are a lot of limitations to it and its like trying to make an elephant squat trying to *customizing* WBI monitor for specific needs.
I would rather back your first approach where you drop messages to mq at critical points in your Business Process and have a UPES program store these milestones in an appliation database. Once you have the data at a place where you have complete control on, you can do what ever u want with it.
The downside to this is that you have to decide the key mile stones way up in the design phase and you cannot keep changing it on the fly.
Thats my 2 cents.
_________________
Thanks
Koko |
|
| Back to top |
|
|
| vennela |
| Posted: Tue Jun 27, 2006 4:51 pm Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
Why use workflow at all?
Why not use process server?
I know that's a costly proposition, but maybe that will help you in achieving what you are trying to do by you not having to do anything. This kind of things are built in process server. Moreover, you will get lot of help and support from IBM.
For all the activities, how can you put UPES activities. That doesn't make sense to me. |
|
| Back to top |
|
|
| jmac |
| Posted: Wed Jun 28, 2006 4:57 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
| vennela wrote: |
Why use workflow at all?
Why not use process server?
|
I assume you mean why use MQWF. Use the workflow capabilities of Process Server.... We wouldn't want to give people the idea that WPS does not do workflow 
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| vennela |
| Posted: Wed Jun 28, 2006 6:22 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| jmac wrote: |
| vennela wrote: |
Why use workflow at all?
Why not use process server?
|
I assume you mean why use MQWF. Use the workflow capabilities of Process Server.... We wouldn't want to give people the idea that WPS does not do workflow |
Thank John
That's exactly what I meant. |
|
| Back to top |
|
|
| SandeepLathi |
| Posted: Wed Jun 28, 2006 11:42 am Post subject: |
|
|
Newbie
Joined: 19 Jun 2006
Posts: 6
|
It makes a lot of sense to go to WPS but unfortunately at this point we are not ready to use Process Server.
Give that, if we have to use the Monitor APIs, is the following right way to get the data out:
1. A report of all processes’ data would require a combination of the Workflow Dashboard and Business Dashboard result sets.
2. To obtain historical data (Business Dashboard) we should use -
public double[] getMesureDetailsData(java.lang.String displayName,
long fromDate,
long toDate,
int range,
ProcessId processId,
OrgUnitId orgUnitId)
throws APIException
Important Point - Reports would require a query for each business measure required
3. To obtain runtime data (Workflow Dashboard we should use -
RecordSet queryActivityInstances
OR
queryProcessInstances
Here all business measures are returned as part of the RecordSet object
--------
Any insights from people who has tries this would be helpful. |
|
| Back to top |
|
|
| SandeepLathi |
| Posted: Thu Jul 06, 2006 8:04 am Post subject: |
|
|
Newbie
Joined: 19 Jun 2006
Posts: 6
|
| Does anyone have any additional inputs on this? |
|
| Back to top |
|
|
|
|
