CA Service Management

 View Only
  • 1.  Blocking a parent ticket while a PAM process runs

    Posted May 15, 2018 03:16 PM

    Good afternoon!

    We have a process in PAM that updates children tickets in SDM.
    It propagates the status update and comments (this could be a native feature of SDM).
    We need to block editing on the parent while this process is running to prevent someone from closing the parent ticket before replicating the data.
    How can we create the block by the PAM process? Is there any way via webservice or operator?

    We even created a script on SPEL, but we do not know if it has any side effects.


    Thank you!

     

    IDEA: Update child tickets according to parent automatically 



  • 2.  Re: Blocking a parent ticket while a PAM process runs

    Posted May 15, 2018 03:36 PM

    Here's one way to do it.  When PAM picks up the parent ticket for processing, have it set a value such as "PAM Processing" in "external_system_ticket".  Then define a Pre Update data partition on Call_Req restricting edit when external_system_ticket = "PAM Processing".  Once the process is finished, set clear the value from "external_system_ticket".  Keep in mind, the user you are using for web services can't have the same data partition as the analysts.



  • 3.  Re: Blocking a parent ticket while a PAM process runs
    Best Answer

    Posted May 15, 2018 03:48 PM

    Just tested this in our QA environment, works fine.



  • 4.  Re: Blocking a parent ticket while a PAM process runs

    Posted May 16, 2018 01:09 PM

    Great suggestion.
    Thank you very much!



  • 5.  Re: Blocking a parent ticket while a PAM process runs

    Broadcom Employee
    Posted May 16, 2018 11:35 AM

    Rodrigo.........

     

    Does the information provided by gbruneau help achieve your requirement?



  • 6.  Re: Blocking a parent ticket while a PAM process runs

    Posted May 16, 2018 01:08 PM

    Yes, help. We were testing this morning.

    But due to the limitation of the number of records to be updated via webservice, we have made a process that updates the tickets via userload.
    The problem is that this update does not trigger notifications when the status of child tickets is updated.
    Via webservice, updating a ticket with 2000+ children took almost half an hour. By userload, 2 minutes.

    We are thinking of another solution. And in addition, we will create an IDEIA suggesting this functionality we are trying to create.

     

     

    Thank you!



  • 7.  Re: Blocking a parent ticket while a PAM process runs

    Posted May 16, 2018 07:47 PM

    Just curious, what issues did you run into when updating the 2000+ children and how often would that many records need to be updated? I’ve updated similar amounts of records in PAM and found as long as the process is broken up into batches it should be fine.



  • 8.  Re: Blocking a parent ticket while a PAM process runs

    Posted May 17, 2018 07:34 AM

    In our organization, we have a monitoring over 200K CIs via Spectrum and sometimes massive downs occur and are generated many tickets in the SDM.

    For our implementation, we used a sample of 2000+ children considering a worst case scenario that could happen (and it already happened). A reasonable average is around 200-500 children.

    In the fastest process we did in PAM, via pdm_userload (updating status in table Call_Req) and pdm_load (inserting solution in table Act_Log) when inserting an activity in a child (example solution) the notification was not triggered. With this, we return the implementation via webservice that takes about 10 times more, but triggers the notification.



  • 9.  Re: Blocking a parent ticket while a PAM process runs

    Posted May 17, 2018 08:17 AM

    I had the same path, from pdm_userload to webservices tool but then I switched to frg macros.

    Take the time to check this example: https://communities.ca.com/message/242040691-re-close-bulk-tickets-with-comments-in-ca-service-desk-r127?commentID=24204… 

    the fastest legal way to update tickets

     

    my 2 cents.