Jump to content

BPM not working since update


Jeremy
 Share

Recommended Posts

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.

Link to comment
Share on other sites

@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:

image.png.627931da3968e7c0afec70d8dd8203f1.png

Fail safe message

image.png.151f5f52be37b7c5089348966aedf517.png

BPM Decision:

image.png.8b1b28e89c4dd3b4c8f3aa281c480b38.png

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

@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

Screen Shot 2018-10-22 at 12.12.47.png

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.

Screen Shot 2018-10-22 at 12.14.39.png

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

 

Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

@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? 

Link to comment
Share on other sites

@Jeremy

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

Screen Shot 2018-10-22 at 13.58.58.png

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).

Link to comment
Share on other sites

@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.

 

  • Thanks 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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...

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...