BPM not working since update

[Jeremy]

We have updated hornbill (build 1364) and found that our bpm's that have decisions are not working as the default and customer display have swapped around as they are now looking and the wrong value meaning that our bpm's are not functioning correctly and are breaking.

Please, can this be looked at asap?

e.g. customer display is Windows 10 (temporary) and the default value is Windows 10 the bpm decisions are taking the customer display rather than the previous default values.

[Guest Chaz]

@Jeremy would it be possible to get the error message and a screenshot of the area you think is causing the issue? Thanks

[Jeremy]

@Chaz there is no error message, we have some BPM decisions that use pcf answers to dictate the flow.

Our example is in one of our pcf's we used the default value which was Windows 10 in the decision, we found a few examples today where this decision was now looking at the customer display which was Windows 10 (temporary) and the bpm decisions are taking the customer display rather than the previous default values. We know this as when it failed we have messages that we put in the descriptions to show the path that the request takes.

We have just updated this PCF and changed both values to be the same, to stop further issues but we do have others that use different values.

Questions completed:

Fail safe message

BPM Decision:

[Hornbill Staff DR]

@Jeremy I think I understand what you're saying. I assume the progressive capture question is using a select box being driven by either a static list (configured in the pro cap field) or a dynamic list (located in Service Manager simple lists). Is that right?

So you're suggesting that the decision was once using the "value" in its evaluation but now is using the "display name" in the evaluation and therefore failing to match the string "Windows 10"?

Can you send a screen shot of the simple list or static list you're using and confirm my interpretation above?

Thanks
Dan

[Martyn Houghton]

@DanielRi, @Chaz

This seem very similar to the issue @DeadMeatGF has raised also with SM 1364. 

Cheers

Martyn

[Jeremy]

Yes this the same as @DeadMeatGF's issue we have adjusted our main BPM's so can't show you the original decision that we had.

[Martyn Houghton]

@DanielRi , @Chaz

Is this a known problem with SM 1364 or a planned change? 

At the moment we are hanging fire applying this build, as we will need to check all our BPM decision nodes to make them cope with both value and display value if this is the permanent change in behaviour.

Cheers

Martyn

[HHH]

Please fix this ASAP. Nodes should compare value rather than display name we have nodes that look for team and having to display /companyid/departmentid/teamid/ as display in progcap to be able to compare in BPM flow is not very intuitive.

[Guest Ehsan]

We are looking into this and we will update this post as soon as we have a new update.

[Guest Ehsan]

All,

We have identified the cause of this problem. We're currently preparing a fix. I will update this post as soon as this is updated on all Hornbill instances.

Ehsan

[Guest Ehsan]

All,

There was an issue with branching on values within a Progressive Capture form. We've patched this problem and automatically applied to all Hornbill instances through the Hornbill Collaboration App.

We are still looking into the issue with branching on values within a BPM. It appears that the engine used to always branch on Display Value?

Could I ask if you could please give it another try and let us know whether this is resolved, with the automatic update to Hornbill Collaboration App? Please refresh and clear your browser cache, prior to giving it another try. @HHH @Martyn Houghton @Jeremy

[Martyn Houghton]

@Ehsan

Thanks for the update. We are holding off applying SM 1364 at the moment as it is the the BPM impact is our concern, where the BPM has always previously use the Display Value rather than the actual value.

Cheers

Martyn

[Guest Ehsan]

@Martyn Houghton @HHH @Jeremy

I'm unclear about what is being reported here. Could you please help me understand, so that I can liaise with the development teams at Hornbill to progress this.

The previous posts claim that branching in a BPM uses the Display Value. 

In the example below, I have configured a field to use a drop-down select box. The options are:

• Yes as the Display Value, value.yes as the Value
• No as the Display Value, value.no as the Value

In the BPM, I'm branching on this field. My expression is set up to branch on when the value is Yes rather than value.yes. This is correctly evaluating for me and my BPM is progressing to the correct node as expected.

Are you suggesting that this is not how you expect it to work?

 

[HHH]

@Ehsan

I would expect it to look for value.yes rather than Yes.

The reason for this would be that in my case I have a custom form in the Progressive Capture for creating new users where one of the questions is "Which team should the new user be attached to?".

The value here would look like (anonymized) /companyid/departmentid/teamid/ and the display would be "Team 1"

 

In the business process using this I cannot pass "Team 1" as a parameter to the integration bridge and assign this person to Team 1 since the parameter in this case would need to be /companyid/departmentid/teamid/

Of course I could do a check for the response and a lot of branching after that so if the form holds team 1 pass /companyid/departmentid/teamid/ but that's a very clumsy way of handling things.

[Steve Giller]

As @HHH says, I would expect it to branch on value.yes - as the display could be (in an exaggerated example) "I would prefer a laptop for this position, and can you provide a full business justification." whereas the value would be "laptop"

[Guest Ehsan]

@DeadMeatGF @HHH  - Requests > Get Request Information > Progressive Capture Answers automated task currently returns the Display Value of a field.

As per the forum post below, we raised a change with the product team to store the Actual Value  as well as the Display Value, and make both these values available through the automated task. This enhancement is not available, yet.

My question was in relation to suggestions in this post that this behaviour has changed? 

[Guest Ehsan]

@Jeremy

Could you please provide us with a screenshot of your field configuration in your Progressive Capture? Does it look like below?

Looking at the data in h_itsm_questions table, it suggests that the Display Value used to be Windows 10 but has been changed to Windows 10 (temporary) at some point recently. Doing so will require you to update your BPM decision nodes to evaluate on the updated value. We're working on an enhancement to allow you to evaluate on the Actual Value (i.e. in my screenshot, the value in the left box for each item) but until then, you'll have to continue to evaluate on the Display Value (i.e. the value in the right box for each item).

[Victor]

@Jeremy @Martyn Houghton @HHH @DeadMeatGF -  Seems like I got back at a right time so just to clarify things a bit here. This is the statement I made in August which is still valid and should represent current behaviour:

When the PCF has custom forms and custom fields that are configured as lists (drop-down lists, checkboxes or radio buttons) when a user goes through the PCF (to raise a request), the answers provided will store the display of the selected item in the custom field list. It would make more sense or at least there should be a configurable option for Hornbill to store the value configured for that item of the list instead of display. But this is being discussed internally at the moment. (https://community.hornbill.com/topic/13756-mathematics-within-service-manager/

The system always stored the display value and used it in the business process, this is how it currently works. We do agree that this can be improved and it will be. There is a change in progress (I think is complete actually) and will be deployed in a build soon which will allow both values of an answer to be stored (display and raw) and used in a business process.

 

[HHH]

Just to provide with a second example. I'm currently creating a BPM to automatically update service subscriptions for customers. Progcap is a custom form with a drop down of services.

Problem now is that integration tool expects ID and the only thing I can catch from the ProgCap is the Name so I cannot use it without a lot of overhead matching names to ID's.

We are very much looking forward to this fix.

[Victor]

8 minutes ago, HHH said:

Problem now is that integration tool expects ID and the only thing I can catch from the ProgCap is the Name

Yes. It is how it always was I'm afraid. As mentioned in my above reply, when the PCF has custom forms and custom fields that are configured as lists (drop-down lists, checkboxes or radio buttons) when a user goes through the PCF (to raise a request), the answers provided will store the display of the selected item in the custom field list.

9 minutes ago, HHH said:

We are very much looking forward to this fix.

Just to make things a bit clear, there is nothing broken here so there is no fix for this. What it is being done and was done (soon to come)  is an improvement to allow more functionality in this area so it will be more useful and easier to use. But nothing needs to be fixed. I know, technicalities, but they are important because now our devs are heartbroken thinking they wrote bad code that needs fixing...