BPM Failure

[Dan Munns]

Hi all,

i have added an Info only change to our change process and it always fails when setting the sub-status but I cant see why. Upon looking into the log I also noticed some other worrying errors (attached) 

Any ideas? 

 

[Guest Chaz]

We're working on a fix for this and hope to have something shortly. A workaround for it as described in this thread:

 

[Guest Ehsan]

Hi @Dan Munns,

We have identified the root cause of the reported behaviour. This is now available in Build 1042 of the Service Manager App (Available in the App Store).

Thanks,

Ehsan

[Dan Munns]

Hi @Ehsan

After installation of the new update the change process described above still fails with the attached errors

[Victor]

@Dan Munns could be because you have the change subs status on update setting enabled but you don't have sub statuses for change request catalog items?

[Guest Ehsan]

@Dan Munns,

Status is a required option for this Automated Task. In your screenshot, this option is set to Auto. Please update it to Manual, as per the following screenshot.

Thanks,

Ehsan

[Dan Munns]

@Victor I have set the sub statuses up against the change process (they show up in the list should you do them manually). I couldn't set them in the global list against change as they didn't show up at all.

Both app.email.allowRequestSubStatusUpdates and app.email.routing.rules.allowRequestSubStatusUpdates settings are set to on.

All sub statuses are set to published.

Any help would be appreceiated as I am on annual leave for the next week and we have a CAB on Tuesday...

 

[Victor]

@Ehsan might be on to something on why the error occurs

[Dan Munns]

@Victor and @Ehsan Ok so I have change all sub status changes to include the main status as well.

The question I have now is will the calls raised with the setting being incorrect still fail as they were logged on a failed BPM or will they carry on and use the new one from where ever they in the process? 

Thanks

Dan

[Guest Ehsan]

@Dan Munns

That's great to hear.

The change that you have made to your Business Process will only take affect going forward. As you know, Business Processes are versioned and older Requests will run against the previous version of your Business Process, whereas new Requests will run against the new version of your Business Process. You will have to manually set the Sub-status in each Request, unfortunately.

Thanks,

Ehsan

[Dan Munns]

@Ehsan Manually setting the sub status is fine, however will the BPM fail completely or will it fail, we set the sub status correctly and restart and it will carry on?

Just wondering if I need to recreate the 8 or so changes in the list at the moment.  

[Guest Ehsan]

@Dan Munns,

Since the configuration for the Automated Task has been modified, restarting the Business Process will not correct and resume the Request. Restarting a Business Process re-runs the last Automated Task with the configuration that was known to it when the Request was raised. You may have to recreate those Change Requests.

Thanks,

Ehsan

[Dan Munns]

Ok I have re raised the effected changes (lucky for me only 3)

Now however I am getting a weird issue with logging a request via the raise new drop down where it doesn't show the service list.

I have added the 'select service' node in the PC (which even though was missing still showed the service list when selecting a change this way) but now it shows all services.

The same node under Incidents shows a lot less services (both attached)

Any idea why the sudden change (I must have raised 30 plus changes and been able to select the service and have not changed the PC until today after if stopped working) and why they both show different lists?

The settings app.itsm.progressiveCapture.newChange and app.requests.defaultBPMProcess.change are set and have not been changed either.

Thanks

[James Ainsworth]

Hi Dan,

There are a couple of things that can influence the number of Services that are displayed on the Progressive Capture Services form.  One of those is the Service Subscription.  If you are specifying a customer prior to the list of Services, the Services will be filtered to only show the Services that the customer is subscribed to.  There is also a Service Manager Application Setting  (servicemanager.progressiveCapture.servicedetails.enableSupportVisibility) that can take this a step further and also hide Services that the support person is not supporting.

If you are not specifying a customer for a change, the likelihood is that all the services will be displayed.  When raising an incident, if you are specifying a customer prior to the services list is likely to have less services listed as it is based on customer's subscription.

I hope this helps.

Regards,

James