BPM v9 Dynamic Roles & Actions

Brian Echard

I am trying to finalize a v9 Procedure.  It's actually quite simple but I can't get an action to work if I use a dynamic role.  The stage works and it appears on my to do list but the action buttons do not show up.  I attached the details.

Tony Lam

Did you make sure to flip the switch in the registry to "DisableStaticRoleResolution"?

 

If not you can check,

 

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Metastorm\e-work\Engine

 

Change:

DisableStaticRoleResolution = 0     to DisableStaticRoleResolution = 1

 

Give that a shot.

Jerome_Pearce

Firstly to answer one question in the PDF file: "I’m not sure why the role only sees SAP_Asset_CapitalizationData and the form shows SAP_Asset_CapitalizationData1 but it appears to be correct. "

 

I am assuming you have eliminated the possibility that the 'to do list' role is not available when the form reopens immediately after the first action, and after subsequent actions will not be updated if the form reopens automatically.

 

On the form you are seeing an 'instance' of the process business object. As such it is named after the object with a '1' added. A second instance would have a '2' added, etc. In the role calculation, as anywhere else in the process itself, you will refer to the process business object by the object name itself. I'll not try to explain exactly why as it gets too far into OO for this issue.

 

I myself would examine the actual data for the folder. We have a form in our library (see link below) that shows all variables and their values for a Folder. It is only visible to admin, so we add it to every stage in every process. We also add a form showing the current status and another showing Designer Log errors. Together, I suspect these may help with the issue.

 

Given these forms, I would check the To Do list values on the status form, the actual variable values in the Variables form, and then see if there are any Designer Log entries on the Designer Log form. Something gone awry, that is clear, because this works all the time for us.

Jerome_Pearce

 

---

TKLam wrote:

Did you make sure to flip the switch in the registry to "DisableStaticRoleResolution"?

 

If not you can check,

 

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Metastorm\e-work\Engine

 

Change:

DisableStaticRoleResolution = 0     to DisableStaticRoleResolution = 1

 

Give that a shot.

---

I would be very wary of doing this unless you know exactly what the effects are. It will also have no effect in this situation in any case.

 

Brian Echard

The consultant we use found that when it was evalulating dynamic roles it was forcing the username to lower case but the username in the eUser table was upper case.  He switched it to force uppercase and all is now well.  Not sure that's the best solution but it worked.

Jerome_Pearce

We have had a very similar issue.

 

It seems that, contrary to expectations, role evaluation is sometimes case sensitive. This is 'new' to version 9, but can cause issues in legacy systems where case has been 'variable', shall we say. We have a few going back up to 10 years and to version 5, so we will need to be sure we standardise the user information case now that we are 'semi-colonists'.

achopra

I have run into this issue as well, albeit only when using SSO.  I had to modify the SSO script to force the case to be the same as what was in the eUser table.

Mark Nichols

Just had the same issue here. I set the dynamic role expression to return LOWER case and it worked. Strange thing is that in DEV it worked without conversion. Does anyone know if there is a case sensitivity setting somewhere?

Daniel_Michael

@Mark, is there a difference in versions between Dev and the other system? What Version are you running on?

Robert Vignerot

I have run into this issue a few times now using 9.1.2.  I'm not sure if it was the same way previously.  It seems like dynamic role evaluations are case sesitive.  If the username assigned at login from eUser or SSO and the username the dynamic role returns are a different case (e.g. 'username' vs 'Username'), the user will not be granted access.

 

I believe this should be considered a defect as there is not workaround other than to make sure the user source and the dynamic role source have the same case.

Tony Wheeler

The strange thing is that the Admin Guide (Engine Registry Settings) describes a registry key whose description sounds like it would affect this behavior:

 

Force Case Sensitive Role Evaluation
Key:       HKLM\Software\Metastorm\e-work\Engine\
Name:     Force Case sensitive role evaluation
Type:      DWORD
 
If this is set to:
 
•  0 (default), the Engine does not perform case-sensitive role evaluations.
•  1, the Engine performs case-sensitive role evaluations.
The value defaults to 0. 

 

I wonder if the systems that see this behavior have this registry key defined and what that value is set to. If it doesn't exist, it might be worth creating this DWORD in the proper hive (WOW6432 is appropriate) and testing it with the value of 0.

Robert Vignerot

My DB is a case insensitive DB and the evaluation was case sensitive.  I did not have the key.  I added it and set it to 0 and 1 and tested both settings.  Neither seemed to have an effect.

Paul Lawrence

I reported this behaviour to Metastorm in 2011 but I never got a response to the issue. We managed to get around it by changing the role definition to force a case-insensitive comparison but this may not be an option in all situations.

Mark Nichols

@Dan...the versions are the same. The difference is the production using SSO and dev uses basic authentication. I've forced the eUser and eAssignment table username to lower case and everything is working. I actually resolved all of the dynamic roles via the role evaluation code, but the built in Originator role was more trouble as I could not alter that evaluation. Only changing the DB to lowercase took care of that.