Question
Ordina
NL
Last activity: 10 Oct 2016 3:40 EDT
Available properties (within NBA strategy)
In our NBA project we have a requirement where the strategy designers have to fill certain properties, which will be used to do a soap connect later in the process. These properties are defined as name/value pairs in the soap interface. The requirement stated that the designers need to be able to start using new properties without the need of a new deploy, nor a change in the soap request/response interface.
We already created a working process where the strategy designers can fill the name/value pairs with the values they want, and they are added in the final soap request. Working as intended...
The downside of this approach, is that different strategy designers can come up with different names for the same properties. For example strategy designer A creates the name/value pair : MaximumAge / 18, where strat designer B came up with : MaxAge / 18. Ofcourse this can be solved by making good procedures and documentation about the used names... but...
What I would really like is to limit the options for the strategy designer.
Im trying to come up with a way to...
* Have 1 place where the strategy designers can create and maintain the values that can be used for 'name' in the name value pairs (name/age/birthplace/etc.).
* Somehow use that data as only possible valid values for the name property in the name/value pair.
In our NBA project we have a requirement where the strategy designers have to fill certain properties, which will be used to do a soap connect later in the process. These properties are defined as name/value pairs in the soap interface. The requirement stated that the designers need to be able to start using new properties without the need of a new deploy, nor a change in the soap request/response interface.
We already created a working process where the strategy designers can fill the name/value pairs with the values they want, and they are added in the final soap request. Working as intended...
The downside of this approach, is that different strategy designers can come up with different names for the same properties. For example strategy designer A creates the name/value pair : MaximumAge / 18, where strat designer B came up with : MaxAge / 18. Ofcourse this can be solved by making good procedures and documentation about the used names... but...
What I would really like is to limit the options for the strategy designer.
Im trying to come up with a way to...
* Have 1 place where the strategy designers can create and maintain the values that can be used for 'name' in the name value pairs (name/age/birthplace/etc.).
* Somehow use that data as only possible valid values for the name property in the name/value pair.
Is there a clever way to archieve this without customizing/specializing out of the box functionality? Ideally all needed rules to maintain this should be available to the strategy designer (therefor in the overlay). How would you approach this?
Many thanks in advance,
Jamäl
***Updated by moderator: Lochan to add Category***
Pegasystems Inc.
GB
There's no simple way to enforce this at design time, as by using a list of name/value pairs, the platform has no insight as to what a valid name is.
Options could be
- Check the list of names against a reference list ( you could do this in the strategy ) and produce an error status if a name is not in the list
- Provide a function (rule-utility-function) to insert the name value pairs but use an index number instead of the name which the function would replace with the name appropriate to that index by using a look up to a previously setup list of names.
Both of these would only work at runtime, but would prevent erroneous names being emitted.
One option for a design time approach would be to reference the name via an index into a prevoiulsy provided page list ( e.g. .ListOfNames(3).Value, "Value to be inserted" ), in this case .ListOfNames(3) represents the name in index postiion 3 of a previously imported list, it would reqiure your strategy designer to know which index to use but that could be provided via documentation.
Just some ideas.