4 Replies Latest reply on Aug 30, 2018 2:05 PM by AlasdairRobertson

    Migration of Request Offerings between Environments

    pappast Apprentice

      I am interested in getting some feedback on how various organizations are handling the life cycle management of Request Offerings (ROs) that are updated/enhanced.

      • Which of you are using the Export/Import functions of ROs to migrate updates between environments (e.g. STG->PRD)? What operational issues (if any) do you have?
      • Which of you are using release packages to capture RO updates? Are you having any operational issues with this approach?

       

      We were previously using an Export/Import approach, but we recently discovered that our Service Level Package and SLA relationship to the ROs was being broken because a newly imported RO has a new RecID (even though the RO name remained the same). Has anyone experienced the same issue?

       

      Thanks.

        • 1. Re: Migration of Request Offerings between Environments
          vee Apprentice

          We just use the Import/Export feature unless the RO required some modifications to business objects then we'd have those changes in a project/package. We never create ROs in a project/package. Actually wasn't even aware you could do that. We do know that if you have a project enabled, even a single change to an RO generates a tonne of transactions.

           

          I'm interested by your comment that your SLA is looking for a RO recid? Are you not using the "delivery by" field when creating ROs?

          • 2. Re: Migration of Request Offerings between Environments
            AlasdairRobertson ITSMMVPGroup

            When I create RO in staging I will export the ROF file and then import to prod in the first instance.  this is due to the  number of transaction update one tends t make adding multiple fields and amending workflows etc.  this is mainly a decision for speed of adding the RO.  The packaging engine will create it but take longer.

             

            Once an RO is in place I use packages to update it so it maintains all the SLA links in the system.

             

            When adding a RO there are 2 methods for the SLA/escalation engine.  The first is the delivery time based escalation that all service requests use.  Importing a new RO will/should create a new entry in the delivery escalation schedule.  If however you have RO added to SLA's then they are linked by RecId's so if you have delivery overrides controlled by the SLA these will not run import a request offering as it will have a new RecId. Therefore use packages.

             

            Import for new creations, update via packages in my experience.  The only impact updating a request offering via a package is time I try to not push the save button to often as every click of save generates a lot of transactions.

            1 of 1 people found this helpful
            • 3. Re: Migration of Request Offerings between Environments
              pappast Apprentice

              Thanks Vee and Alasdair for your responses. I will try to elaborate my current operational challenges with the following example:

               

              1. I create and publish a new RO = New Employee under Service = HR with a delivery target = 3 days. Note that the publishing of the RO in itself does not add a new entry to the ServiceReq Delivery Escalation Schedule (at least in our environment).

              2. I create an SLP =HR_SLP for the HR Service and link this New Employee RO to it. There is still no ServiceReq Delivery Escalation Schedule built for this RO at this time.

              3. I create an SLA subscription for the HR Service using the SLP created previously. It is at this point in time when the ServiceReq Delivery Escalation Schedule is updated to include 2 new entries under ServiceReq - Delivery:

              • ServiceReq - Delivery
                • HR (HR_SLP) Request Delivery Target
                  • Request Offering = New Employee (time = 3 days)

              4. Now any New Employee RO submitted will generate SRs that adhere to the above ServiceReq Delivery Escalation Schedule.

               

              5. I now need to make modifications to the New Employee RO. This includes workflow changes as well as a change to the delivery target (from 3 days to 2 days).

              6. I rename the existing RO in Production from New Employee to New Employee_Old, and place it In Design status.

              7. I import the new RO into Production and give it the same name of New Employee.

              8. If I look at the HR_SLP at this time, the linked RO is New_Employee_Old. I now need to unlink the old RO and re-link the new version. I also need to specify the delivery target of 2 days as part of this link.

              9. If I look at the SLA subscription, the updated RO New Employee is within the subscription with 2 day delivery target.

              10. Unfortunately, the ServiceReq Delivery Escalation Schedule is not updated to reflect the new delivery time of 2 days.

              11. I now need to delete the SLA subscription for the HR service. This deletes the 2 entries listed in step (3) above.

              12. I recreate the SLA subscription using the updated SLP. Now the ServiceReq Delivery Escalation Schedule is updated with:

              • ServiceReq - Delivery
                • HR (HR_SLP) Request Delivery Target
                  • Request Offering = New Employee (time = 2 days)

               

              Summarizing:

              • We so far have been using the Export/Import approach to update ROs. This approach though requires that SLPs be updated and SLAs recreated every time to get the Escalation Schedules properly defined.
              • We will now explore the use of packages for updates to existing ROs within SLPs. It's unclear though if an update to a delivery time for an existing RO will be properly reflected in the SLP and SLA by using packages. It may still require manual updates to the SLP.
              • 4. Re: Migration of Request Offerings between Environments
                AlasdairRobertson ITSMMVPGroup

                So once a RO is created use packages to update this will keep the original RecId's and service level agreements, essentially it allows for the RO workflow to be re-visioned up (in the same way normal workflows increment in version number) and the new fields be displayed, remember if you remove or hide fields then you remove/hide fields on all requests already in progress or closed.

                 

                On this point:

                Unfortunately, the ServiceReq Delivery Escalation Schedule is not updated to reflect the new delivery time of 2 days.

                11. I now need to delete the SLA subscription for the HR service. This deletes the 2 entries listed in step (3) above.

                12. I recreate the SLA subscription using the updated SLP. Now the ServiceReq Delivery Escalation Schedule is updated with:

                • ServiceReq - Delivery
                  • HR (HR_SLP) Request Delivery Target
                    • Request Offering = New Employee (time = 2 days)

                 

                The system is enforcing the SLA, you cannot just change the delivery window on an SLA, it copies the SLP settings over.  the correct way of doing this is to obsolete the current agreement and publish a new SLA including the updates SLP to your customer.  I would not advise deleting SLA agreements in the past it has done interesting things.

                 

                I hope this makes sense.