Test Environment

[yelyah.nodrog]

Morning all,

I really need a test environment, I am working on rebuilding our Hornbill flows as they are not working as well as we would like and i know we can make them better. However needless to say our users are using the flows all day and i cant be messing around with them in case it causes issues.

I'm all of my previous experiences with systems. Their is always a test system when a copy of the live environment is put into the test system and i can do my work and make sure everything is 100% working before putting it into the live environment.

If this isn't something you already cater for can it please be done? as its nuts not having one as standard?

Thanks as always!

Hayley.

[Steven Boardman]

Hi @yelyah.nodrog

An approach we recommend for testing your business processes and progressive captures is to create a test service - you can then create copies of your live BPM's and PC's and link these to your test service / catalog items.  If you subscribe yourself to the service as a customer, and only you support that service (supporting teams) then no one else on your instance will be aware that this service exists, and you will be able to make changes to the copied BPM's and PC's for testing purposes and run these against the test service.

Once you are happy with the changes you have made to your BPM's / PC's you can use the download option for their definitions, and upload these to your live BPM's and PC's to have them take effect going forward. 

Once downloaded you can go into the 'live' version and then use the upload option to apply the updated version of the process

Hope this helps

Steve

[yelyah.nodrog]

Se we have 17 soon to be 20 services, are you advising I create duplicates of all of these but have them not showing...?

[Steven Boardman]

@yelyah.nodrog

You should just be able to create one test service and use this for any BPM's or PC's which you are using on existing services.  The key here is that the test service is a container, and you associate and un-associate the BPM's and PC's you want to test, and you can change these / swap them out going forward.  I would not advocate having duplicate test services for each service, as at 20 this is not practical and at 100 even worse.

The Service (container) is more or less static, save for the name of catalog items, it is the BPM's and PC's which are fluid and where the testing is really performed. 

One consideration you may want to bear in mind is excluding any test requests which are logged against this test service when it comes to reporting.  you could just add an exclusion in your reports to not show requests logged against your test service. 

Steve

Edited March 27, 2017 by Steven Boardman

[yelyah.nodrog]

Thats good for the catalog items but i need to recreate the pro cap that is being picked up in app.itsm.progressiveCapture.newServiceRequest

and if i change that its obviously going to break all the links for the current structure. which i cant do while people are online....

[Steve Giller]

If you create the test ProCap and raise it directly as part of your test service it will act in exactly the same way as if it were triggered from the "Raise New" button, so you dont' need to change the app.itsm.progressiveCapture.newServiceRequest value until it's ready to release.

[yelyah.nodrog]

Hey @DeadMeatGF and @Steven Boardman

Unless I'm being thick, I still need to change the Pro cap in app.itsm.progressiveCapture.newServiceRequest

Because our process for all calls runs like this - the 'new service request (Service Desk)' - Pro cap is in the app.itsm.progressiveCapture.newServiceRequest

so it is the first Progressive capture that we use - Depending on the catalog item it then switches captures. However the bulk of out nodes requesting info etc are in this pro cap.

We want to adjust this so that it literally shows as Customer Search-Select site-select service - then it branches for every service and switch captures to separate Pro caps for each service so that we can tailor each service to a better level

Then under the test user service we have the bpm - 'Test - Audio Visual Catalog BPM'

And under each catalog item we have the tailored Pro cap - 'Test - Audio Visual Catalog Pro Cap'

This is because we have multiple catalog items under every service. 

So in this instance unless i change the  app.itsm.progressiveCapture.newServiceRequest from  'new service request (Service Desk)' to 'Test - Pro Cap for everything compatible with Quick Logging'

This isnt going to work? and changing the app.itsm.progressiveCapture.newServiceRequest while users are on the system (Which is all day and night) is going to break the current services and catalog items?

am i missing something here? because i cannot see how i can change it and it still work considering the amount i'm changing it by...

 

[Steve Giller]

On the standard ProCap you will see the Test Service when you get to the Select Service node - no-one else will because no-one else supports/is subscribed to it.

[Steven Boardman]

Hi @yelyah.nodrog

I think what @DeadMeatGF was saying, is the same as i was trying to suggest (obviously not very well sorry )

You are right there is a single PC which is invoked when your analysts select ' Raise New' so we are not suggesting you need to alter this, until such a time as you are ready to switch from the existing PC to the new one you are trying to create. 

What is being suggested is you in fact via a test service and a test catalog item to mimic what would happen when your analysts press the 'Raise New' option. 

So under a custom expression in your existing PC, when you get to the Services form,  one of your decisions is to see if the test PC linked to your test catalog item in your test service is selected - if so, switch and use this pc - as @DeadMeatGF says.  No one else will see this option as they are not subscribed to the test service nor support it. 

You can then create all the different PC's which you need for the different catalog item's, and for test purposes simply add them to your test catalog item, under the test service and run them through - once you have done one, switch the PC linked to the test catalog item to the next PC you want to test and so on and so on.

This would allow you to validate that each PC for the catalog items are functional, and these can then sit under the catalog items which are in Draft status, until the time you want to promote these to live. 

This does leave the question of making some changes to the primary PC which is used under the Raise New button, and in order to do this hopefully there are some quick changes (again which you may want to test under a PC linked to your test service / catalog item), but you can use :

A decision node after the Services form in the primary PC, which simply checks if an analyst has chosen a Catalog item or not - we don't need to know which one, as we can pass in and just check this using a variable as shown below.

in this case checking if Service Details > catalogProgressiveCaptureID Is Set (has a catlog item been chosen) followed by the Switch Process node which is set to:

Variable - Service details->catalogProgressiveCaptureId - which will switch to the PC linked to the Catalog Item chosen.

Now if you have this off the Service PC Form, there is also the possibility that your analysts may choose the Parent Service, or you may want them to, in which case you would need to add in additional branches and logic to cater for this (as it looks like you currently do), however if you wanted to keep straight forward in your primary PC, and ensure that a Catalog Item is always selected (rather than a parent service), then you can enforce this through the following setting when you are ready:

Now with this enabled, you would not need to build in extended branching into the primary PC used on Raise New as the analysts would have to select a catalog item to progress from the Services Form, and moving forward it would make the testing of PC flows easier, as you could as suggested just create a test Service with a Test Catlog Item which only you would see and use this to test all new or revised PC's before switching them on the catalog item themselves, which the default PC would just pick up on through the Switch Process node in your primary PC after the Service Form.

I apologises as this is a bit long winded but i hope that helps

Steve

[yelyah.nodrog]

Thanks guys the both of you put together finally got through my total blank moment! 

That makes perfect sense

..Still want a test system though....not budging on that opinion 

[David Longley]

Hello @yelyah.nodrog can i ask how you got on with the above? I am new to Hornbill and was equally surprised that there was no out of the box UAT environment, I was given this thread as an example to follow. 

I am curious if this did what you needed as my only other alternative is a new instance.

Thanks

[JanS2000]

Hi, this topic is of interest to me as we're quite new to Hornbill ourselves, and currently setting up a few initial BPs to automate some elements for the Service Desk, and also amend some existing BPs that were set up originally. I've created a test service already, so could I create a config item using existing BPs and progressive captures, without any changes to them affecting the original flow, or do I need to save/copy the original processes and paste/upload into new processes in my test service?