TFS and SCSM integration, how can I do this better?

Tim_VottaTim_Votta Customer IT Monkey ✭
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.

Best Answer

Answers

  • Tim_VottaTim_Votta Customer IT Monkey ✭
    I like your idea and I think that sounds like it will fix our current problems.

    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?
  • Brett_MoffettBrett_Moffett Cireson PACE Super IT Monkey ✭✭✭✭✭
    Sounds like you are getting close to a final solution there @Tim_Votta
    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
  • Tim_VottaTim_Votta Customer IT Monkey ✭
    So I got this going now with Brett's suggestion and a bit of trial and error.
    • I have a dedicated Boolean (srExt_Bool03 or irExt_Bool03) that I am using just for this purpose.
    • I have 2 runbooks that are always started with a monitor task that is triggering on update and a filter for sr/irExt_Bool03 = True.
    • Then have a Get Object step to retrieve SR/IR Details
    • Next, my TFS Script is run.  It is based off of this blog posting which was super helpful when first setting this up. http://www.systemcentercentral.com/day-33storing-tfs-work-item-id-back-service-manager/
    • The last step, I update the description of the ticket with the TFS ID and change srExt_Bool03 to False.

    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.
  • Marek_LefekMarek_Lefek Customer Advanced IT Monkey ✭✭✭
    edited November 2017
    Has anyone tries the codeplex IP for Orchestrator. It is dedicated for TFS 2010 and I was wondering does it can work with newes TFS 2017. LInk to IP http://orchestrator.codeplex.com/releases/view/86333

    Tim_Votta have you try or think about using the TFS Rest API or use Orchestrator than Authoring tool wokrflow?


Sign In or Register to comment.