Hi All.
We have a requirement where we need to write a common Audit component,
This will capture the details about the interface run, like start time, end time, status, some other operational data etc.
The operational data is to be written to a Message Queue in the form of XML message and the data is to be written to queue at the end of interface.
Our interfaces are like
Sq-> Parallel -> end.
Where and how can i fit this common audit component, I know we can connect to MQ through parallel jobs, but as the sequencer is controlling the flow, is there a way i can connect to MQ through Sequence job?
Also as i need to share this across all the interfaces, shall i write it as a shared container and parameterize??
Common Audit Component
Moderators: chulett, rschirm, roy
-
ray.wurlod
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Re: Common Audit Component
Yes.s_avneet wrote:Also as i need to share this across all the interfaces, shall i write it as a shared container and parameterize??
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Your auditing would happen either after the job ends, or at a given time in the day.
Like an hourly job updating stats on your MQ...
Not sure why you have a question on the Sequencer as it will not be the entity doing the SQl extract from the DSODB tables, nor the MQ connection stage to push messages out. It could/would be the part to initiate that.
Really depends on how you want your auditing to happen.
I would recommend added a "DSODBRPT" user id with Read Only access to all of the tables. You do not want someone thinking they are smart messing with those tables with the default user id that has full access (drop even) to those tables.
Like an hourly job updating stats on your MQ...
Not sure why you have a question on the Sequencer as it will not be the entity doing the SQl extract from the DSODB tables, nor the MQ connection stage to push messages out. It could/would be the part to initiate that.
Really depends on how you want your auditing to happen.
I would recommend added a "DSODBRPT" user id with Read Only access to all of the tables. You do not want someone thinking they are smart messing with those tables with the default user id that has full access (drop even) to those tables.