TFS and SCSM integration, how can I do this better?
Tim_Votta
Customer Adept IT Monkey ✭✭
in Orchestrator
So our dev team uses SCSM and Cireson Portal for users to submit dev tickets. Our Scrum Masters assign the tickets to themselves, and all of the developers work on the items from within TFS. For the most part, most of our dev team doesn't interact with the tickets in SCSM all that often.
I have an RBA on all of our dev teamplates that is the first activity and it goes out and creates a TFS item for the ticket. After creating the TFS item, it dumps out the TFS Item number and puts it in a custom field on the ticket. This works fine for the most part, but it does cause some headaches.
If a user selects the wrong RO it might create the TFS item for a ticket unnecessarily, then our Scrum Masters have to go in and clean up the item in TFS.
In the event that an end user submits a ticket to the wrong group, our analysts have an "Apply Template" task on the portal to apply the Development IR/SR template to get the TFS item created.
Invariably, an end user will submit a ticket to the dev team that should go to Operations, or they submit a ticket to Operations that should go to dev. In the first situation, a TFS item is created when it shouldn't be so someone needs to clean up the TFS Item. In the second situation, no TFS item is created so I have to go into the console and add the RBA to the ticket to get the TFS item created.
All of our staff only use the portal, it is just admins that use the SCSM Console. We didn't want to install it or train staff on how to use it because the interface is awful and we didn't want to frighten them while moving to SCSM.
Any ideas how I can handle this better?
The only other option I've really been able to come up with so far is using SMLets and querying for tickets on some interval that are assigned to a Dev support group and the TFS Item field is blank. We would still have some unwanted TFS items created, but at least if something is re-assigned to the dev team we don't need ananalysts to remember to apply a specific template.
I have an RBA on all of our dev teamplates that is the first activity and it goes out and creates a TFS item for the ticket. After creating the TFS item, it dumps out the TFS Item number and puts it in a custom field on the ticket. This works fine for the most part, but it does cause some headaches.
If a user selects the wrong RO it might create the TFS item for a ticket unnecessarily, then our Scrum Masters have to go in and clean up the item in TFS.
In the event that an end user submits a ticket to the wrong group, our analysts have an "Apply Template" task on the portal to apply the Development IR/SR template to get the TFS item created.
Invariably, an end user will submit a ticket to the dev team that should go to Operations, or they submit a ticket to Operations that should go to dev. In the first situation, a TFS item is created when it shouldn't be so someone needs to clean up the TFS Item. In the second situation, no TFS item is created so I have to go into the console and add the RBA to the ticket to get the TFS item created.
All of our staff only use the portal, it is just admins that use the SCSM Console. We didn't want to install it or train staff on how to use it because the interface is awful and we didn't want to frighten them while moving to SCSM.
Any ideas how I can handle this better?
The only other option I've really been able to come up with so far is using SMLets and querying for tickets on some interval that are assigned to a Dev support group and the TFS Item field is blank. We would still have some unwanted TFS items created, but at least if something is re-assigned to the dev team we don't need ananalysts to remember to apply a specific template.
0
Best Answer
-
Brett_Moffett
Cireson PACE Super IT Monkey ✭✭✭✭✭
It sounds like you need a new Boolean field on your Incidents that, when selected, triggers your Runbook to created the TFS record.
This way it would not matter what type of Incident is created, where it goes or the life cycle it has if it ends up in the Dev teams bucket and the Scrum Master believes it should be logged in to TFS, they just have to tick the box and it will be created.
This could be on a tab that is ONLY displayed for Scum Masters so no one else can trigger this to happen.
Your existing Runbook would just need to change the first activity from an Initialize activity to a Monitoring activity that is looking for Active Incidents that have their TFS Boolean field change from False to True.
Hope this makes sense and is a viable option for you.6
Answers
This way it would not matter what type of Incident is created, where it goes or the life cycle it has if it ends up in the Dev teams bucket and the Scrum Master believes it should be logged in to TFS, they just have to tick the box and it will be created.
This could be on a tab that is ONLY displayed for Scum Masters so no one else can trigger this to happen.
Your existing Runbook would just need to change the first activity from an Initialize activity to a Monitoring activity that is looking for Active Incidents that have their TFS Boolean field change from False to True.
Hope this makes sense and is a viable option for you.
I set it up in my lab, but it is triggering on every update to a work item after I first set my new boolean field to true. At first it was looping on itself when I would save the TFS Item back into the ticket. It looks like any update to the ticket is triggering the monitor to hit again.
To stop the loop, I made another boolean field. Then the first time the runbook runs against a ticket, I change that value on that additional boolean. I then have an exclude on the first link in my runbook to stop anything with that second boolean set to true. It is effective, but I would hesitate to move into production setup like this. It seems like it would be creating some unncessary overhead with the monitor triggering on tons of tickets unnecessarily and stopping itself after the first step.
Is there some way that I can set a more robust trigger on the monitor step that I am missing? It just dawned on me while writing this, I suppose that I could just change the value of my original boolean I am using to trigger the entire thing... Maybe that is the best solution?
You could have 2 Boolean fields like you suggest, but you could also have just the one Boolean and a text property. The test property could contain the TFS bug number for simple tracking from either direction (SCSM to TFS or TFS to SCSM)
This way you could setup the monitoring to only look for IR's that have Boolean = True and TFSNum (Text Field) = ""
You could also change from using a monitoring activity in Orchestrator for a scheduled task that runs every 30 minutes (or any time-frame) that retrieves the same sort of SQL query looking for just those IR's that fit the criteria.
I hope this helps in building your solution and I hope you can share it with the community when you have tested and completed your solution.
Regards.
Brett
Blanking out the boolean cleans it up a bit so my monitor step won't trigger the next time that the ticket is updated. I don't need the value to remain set to true for any reason. Someone could check it off again and create another TFS entry unnecessarily, but that isn't too problematic and realistically should be pretty rare.
I kind of lucked out that I already had a boolean that was not used on any RO's or tempaltes, so that made it a bit quicker to get setup with no class extension or anything needed.
Tim_Votta have you try or think about using the TFS Rest API or use Orchestrator than Authoring tool wokrflow?