Wednesday, 29 January 2019
The Siebel State Model allows us to control value transitions for certain fields. While it is focused on ‘State’ fields, we can use it for any other field.
If it is important to keep in mind that a simple syntax error can cause the entire State Model (not just the transition in which the typo was) to stop working correctly, so it is highly recommended to apply it only for fields that use Value Lists, and thoroughly test any changes that are made.
It should also be remembered that it is based on a Business Component, so if in our application users had access to the same functionality from views that use different BC, it would be necessary to maintain an independent State Model for each BC. The most advisable thing in these cases is to try to maintain the minimum number of BC’s for each functionality. If your application contains code that works on that same BC, the State Model will also affect you.
And finally let’s get into flour, how is the State Model configured? Well, it is done in 3 phases, the first is to create the State Model itself. From ‘Application Configuration’/’State Models’, we will create our Model indicating for which BC and specific field we want it, as well as the effective dates of it.
Once created, the 2nd phase will be to define the States with which we are going to work from the ‘Regions’ tab. Since as we mentioned it should be applied to a field that uses List of Values, we will only have to select those values from the list that are valid. We will set one of them as default and check ‘Restrict transition’ for all, so that we can control the transitions for which each of them can be used.
To conclude, from the Transitions tab we will define all valid transitions (original state and destination state). Once we have concluded, it is time to define who and under what circumstances can use each transition. If we define the transition as Public, any user can use it, while if on the contrary we do not, only users with one of the positions that we list in the Authorized Positions applet will have visibility of that transition when displaying the list of values in the field (the rest of users will not even see that destination transition). To define under what circumstances the transition is allowed, we can introduce a conditional expression that regulates it. This does not prevent the user from seeing the transition when the conditions are not met, but in that case the system will return an error message preventing them from changing the value of the field. As an example, if our State Model regulates changes to the Activity Status field, we can prevent a specific transition from being used for Activities of a particular type by using the expression:
[Type] <> “<type not accepted>”
If the type of activity is the one indicated in the expression, the message will jump indicating that the condition is not met. It is advisable to simplify these expressions as much as possible for proper maintenance of the State Model, as indicated above a syntax error in these expressions would cause the complete State Model to stop working.
When we have our State Model ready (as well as every time changes are made to it) it will be necessary to restart the Object Manager for the changes to take effect.
