Well this is the last scenario (of the series for 7.1 Ehp1 at least). This 10th scenario is probably the top FAQ out of 10. By going through this one, you won’t hit the common technical pitfall!
(I suggest to take a closer look at the 1 hour recorded session if you are interested in the demo.)
Remark: The contents require beginner level knowledge of NW BPM on 7.1 Ehp1.
Scenario 10: Frequent update for role assignment
As a big picture, you have two possible ways:
Dynamic assignment by Expression for Potential Owners
UME configuration by the user administrator
The option 2 is nothing interesting and I won’t talk about it. BPM folks will find the option 1 is very valuable and one of the must knowledge in most cases.
So you can find the Potential Owners field and this is the place you can assign the predefined expression for the dynamic assignment at runtime.
A couple of remark – these are the common pitfall for this expression.
Two predefined expression functions are offered – “getPrincipal(string principalID)” and “getPrincipalByUniqueName(string uniqueName, string identityType)”.
The difference of the two is “getPrincipal()” function expects the value which UME understands as “technical name”. The easy example is like this – you can find it in the user info of UME.
In most cases you would like to use the other function “getPrincipalByUniqueName()”, as this accepts the straightforward UserID, GroupID, or RoleName in UME. The second parameter expect the string value of “user”, “group” or “role”.
For the getPrincipalByUniqueName(), the first parameter usually should come from Principal type. You can find the predefined data structure.
In this way the Potential Owner can be overwritten at runtime. But please be careful of the interesting behavior of the Principal overwritten – as of 7.1 Ehp1, “Lane” is strongest. So if you define any Potential Owners on the Lane, this setting won’t be changed at the runtime! This behavior is changed in 720.
So, by making use of these simple tips, you can dynamically assign the specific users at runtime.
Well that’s the last 10th scenario. I am wrapping up all the 10 common typical workflow in this blog.
Like I wrote before, the idea of this blog series is to collect your idea and experiences of
– “Very common workflow use cases” but you don’t know how to implement them with NW BPM.
So please feel free to drop your common use case if you have any. The main reason of this blogging is I am sure that you will find these are all very useful when you start any real NetWeaver BPM project later on – those are all common use cases and you don’t have to invent the wheel from a scratch. As you move into the BPM implementation, you would face other common use cases which are not covered in these blog series. If you hit such moment, you can feel free to drop what you face. I am looking forward to your real experience with NetWeaver BPM.
As you could imagine, upcoming NetWeaver BPM 720 provides more and more useful and important feature – stay tuned!