Create a text file instead of sending an email on Work Item state changes
I have a client who wants to integrate their Help Desk product with their existing RTC/RQM Defects and Enhancement Requests work items - the idea being that their support staff can raise Defects and ERs directly from their help desk tool, and then track the status of the fix.
Despite the help desk tool being quite limited, we were able to quickly and easily set up Work Item creation in RTC. The tool has a small set of predefined actions that can be chained together and attached to a toolbar icon. We chained an action that dumped the entire Incident report to a text file with one that ran an external executable and used it to call a perl script that parsed the relevant information from the text file and used the REST API to create a new WI. All done in a few hours and client was very happy!
However, getting information back into the help desk tool is proving a little more problematic. There are two types of listeners available - an email listener and a file listener. The email listener simply listens on an email account and looks for specific format subject lines containing the Incident ID. It then parses the Incident ID, and appends the entire contents of the email to the Incident as a journal entry. The file listener looks for files in a directory, and when it finds one, it parses the content via an XSLT transform of your choosing and based on the data updates the fields in the Incident record.
The client is very excited about being able to control what journal entries are added by using the RTC email customisation and are going to set that up straight away, but they explicitly want to update several custom fields on the Incident record so that they can be used on reports and dashboards. The required information is simple - the work item ID, the WI URL, the current WI state, and the Fix Release. The problem is in getting that information into a file, and generating that file on each WI state change.
Has anybody ever done this before, or can anybody suggest a way this could be done?
Thanks!
Despite the help desk tool being quite limited, we were able to quickly and easily set up Work Item creation in RTC. The tool has a small set of predefined actions that can be chained together and attached to a toolbar icon. We chained an action that dumped the entire Incident report to a text file with one that ran an external executable and used it to call a perl script that parsed the relevant information from the text file and used the REST API to create a new WI. All done in a few hours and client was very happy!
However, getting information back into the help desk tool is proving a little more problematic. There are two types of listeners available - an email listener and a file listener. The email listener simply listens on an email account and looks for specific format subject lines containing the Incident ID. It then parses the Incident ID, and appends the entire contents of the email to the Incident as a journal entry. The file listener looks for files in a directory, and when it finds one, it parses the content via an XSLT transform of your choosing and based on the data updates the fields in the Incident record.
The client is very excited about being able to control what journal entries are added by using the RTC email customisation and are going to set that up straight away, but they explicitly want to update several custom fields on the Incident record so that they can be used on reports and dashboards. The required information is simple - the work item ID, the WI URL, the current WI state, and the Fix Release. The problem is in getting that information into a file, and generating that file on each WI state change.
Has anybody ever done this before, or can anybody suggest a way this could be done?
Thanks!
One answer
you will have to write a java 'participant' that watches for specific workitem state changes and sends the info to some other process to save the data. this shouldn't be more than 50 lines of code give or take.
you don't want an 'advisor' cause the transaction is not committed at the time the Advisor chain runs.
the participant plugins, like the advisors, run on every workitem save. you will have to look at the old workitem context vs new context to determine what fields changed, and specifically to see if its a state change.
these plugins as packaged as java jar files and loaded into the web server config space for the ccm application.
I posted a complete advisor (participant is just a different parent class and extension point).
here https://jazz.net/forum/questions/64268/operation-advisor-custom-precondition-for-work-items
you don't want an 'advisor' cause the transaction is not committed at the time the Advisor chain runs.
the participant plugins, like the advisors, run on every workitem save. you will have to look at the old workitem context vs new context to determine what fields changed, and specifically to see if its a state change.
these plugins as packaged as java jar files and loaded into the web server config space for the ccm application.
I posted a complete advisor (participant is just a different parent class and extension point).
here https://jazz.net/forum/questions/64268/operation-advisor-custom-precondition-for-work-items