Question
On creation, Pega renames Rule-Utility-Function with generated hex string
Summary
I am creating a couple of Rule-Utility-Functions. In some instances, Pega is renaming my functions in a ghastly fashion (see below). I don't see a workaround.
The plea for help
- Has anyone dealt with this?
- Is there a hotfix?
- Moderators, please let me know if I should be opening an SR instead.
Details
When I first create a Rule-Utility-Function, if it has a long name and some parameters, Pega renames it with what appears to be an automatically generated Hex string. For example:
- create a new Function
- for label, enter "this is a long function name with some parameters"
- add three string parameters
- p1, String
- p2, String
- p3, String
- click to create the rule
Result: the function is created with the name
ThisIsALongFunctionNameWithSom--70c85b9d0d10cb9ff641f6221070cf00
Egads!
The apparent cause
On creation, Pega ordinarily attempts to generate a helpful label by concatenating
- the value I supply
- two hyphens as a separator
- a comma-separated list of parameter types
For the example above, Pega would generate the following label:
ThisIsALongFunctionNameWithSomeParameters--(String,String,String)
Summary
I am creating a couple of Rule-Utility-Functions. In some instances, Pega is renaming my functions in a ghastly fashion (see below). I don't see a workaround.
The plea for help
- Has anyone dealt with this?
- Is there a hotfix?
- Moderators, please let me know if I should be opening an SR instead.
Details
When I first create a Rule-Utility-Function, if it has a long name and some parameters, Pega renames it with what appears to be an automatically generated Hex string. For example:
- create a new Function
- for label, enter "this is a long function name with some parameters"
- add three string parameters
- p1, String
- p2, String
- p3, String
- click to create the rule
Result: the function is created with the name
ThisIsALongFunctionNameWithSom--70c85b9d0d10cb9ff641f6221070cf00
Egads!
The apparent cause
On creation, Pega ordinarily attempts to generate a helpful label by concatenating
- the value I supply
- two hyphens as a separator
- a comma-separated list of parameter types
For the example above, Pega would generate the following label:
ThisIsALongFunctionNameWithSomeParameters--(String,String,String)
However, that would exceed the max length of pyLabel by one character, so Pega cannot modify the label as intended. To use a technical term, it barfs - Pega does something completely unexpected: it modifies both the label and the name of the rule like this:
ThisIsALongFunctionNameWithSom--70c85b9d0d10cb9ff641f6221070cf00
- The label problem is this is annoying but has a workaround: change the label value and save again
- The rulename problem has no workaround other than to shorten the name of the function. For a function with a longer list of parameters, there is no workaround. To demonstrate this, I attempted to create a function with a one-character name, A, and enough parameters to exceed the length limit of pyLabel. Pega created this:
A--(ClipboardProperty,ClipboardPa6aa01df9cbc99c5e6dc4397862b6de7
Disclaimer: although I could hypothetically use such a function, I could not live with myself if I introduced one into the application. <insert whimsical emoji here>
Accepted Solution
Pegasystems Inc.
GB
Hi Elliot,
So I think I know what you mean; and I'm not sure what the purpose of this naming convention.
I tend to agree with your 'Egads!' reaction !
*but*...just to be clear this is the 'ID' of the function...(right?)
Using the Function is still sane and humanlike (right?).
So in a PRPC expression, you use the nice, human version like this:
@LibraryName.FunctionName(arg1, arg2... argn)
Or in a Java Step; like this:
myinventory_sort.CardType("Gold")
So ; I guess this is more of an atheistic BUG ? - us Humans probably don't need to know that big hex monstrosity even exists (we're not going to use it...I don't think?)....
I note that even OOTB functions show up like this:
For instance (I'm testing here on 7.3.1) : Default.SendEmail-(String, String, String) shows up as
Default.SendEmail-(String, String, String3a26e467947bb3f7024329bd64901040).
Maybe somebody else here knows whether this ID *is* somehow important to know....
If it isn't important (for Humans) to know - then I would say we log a Feedback Item, and basically show something simpler instead....(Curious mammals can always do a View XML if they really want to see the gory details I guess...)
Hi Elliot,
So I think I know what you mean; and I'm not sure what the purpose of this naming convention.
I tend to agree with your 'Egads!' reaction !
*but*...just to be clear this is the 'ID' of the function...(right?)
Using the Function is still sane and humanlike (right?).
So in a PRPC expression, you use the nice, human version like this:
@LibraryName.FunctionName(arg1, arg2... argn)
Or in a Java Step; like this:
myinventory_sort.CardType("Gold")
So ; I guess this is more of an atheistic BUG ? - us Humans probably don't need to know that big hex monstrosity even exists (we're not going to use it...I don't think?)....
I note that even OOTB functions show up like this:
For instance (I'm testing here on 7.3.1) : Default.SendEmail-(String, String, String) shows up as
Default.SendEmail-(String, String, String3a26e467947bb3f7024329bd64901040).
Maybe somebody else here knows whether this ID *is* somehow important to know....
If it isn't important (for Humans) to know - then I would say we log a Feedback Item, and basically show something simpler instead....(Curious mammals can always do a View XML if they really want to see the gory details I guess...)
Citations: (7.4 Help, but similar in 7.3.1 etc).
Accepted Solution
Pegasystems Inc.
GB
Hi Elliot,
So I think I know what you mean; and I'm not sure what the purpose of this naming convention.
I tend to agree with your 'Egads!' reaction !
*but*...just to be clear this is the 'ID' of the function...(right?)
Using the Function is still sane and humanlike (right?).
So in a PRPC expression, you use the nice, human version like this:
@LibraryName.FunctionName(arg1, arg2... argn)
Or in a Java Step; like this:
myinventory_sort.CardType("Gold")
So ; I guess this is more of an atheistic BUG ? - us Humans probably don't need to know that big hex monstrosity even exists (we're not going to use it...I don't think?)....
I note that even OOTB functions show up like this:
For instance (I'm testing here on 7.3.1) : Default.SendEmail-(String, String, String) shows up as
Default.SendEmail-(String, String, String3a26e467947bb3f7024329bd64901040).
Maybe somebody else here knows whether this ID *is* somehow important to know....
If it isn't important (for Humans) to know - then I would say we log a Feedback Item, and basically show something simpler instead....(Curious mammals can always do a View XML if they really want to see the gory details I guess...)
Hi Elliot,
So I think I know what you mean; and I'm not sure what the purpose of this naming convention.
I tend to agree with your 'Egads!' reaction !
*but*...just to be clear this is the 'ID' of the function...(right?)
Using the Function is still sane and humanlike (right?).
So in a PRPC expression, you use the nice, human version like this:
@LibraryName.FunctionName(arg1, arg2... argn)
Or in a Java Step; like this:
myinventory_sort.CardType("Gold")
So ; I guess this is more of an atheistic BUG ? - us Humans probably don't need to know that big hex monstrosity even exists (we're not going to use it...I don't think?)....
I note that even OOTB functions show up like this:
For instance (I'm testing here on 7.3.1) : Default.SendEmail-(String, String, String) shows up as
Default.SendEmail-(String, String, String3a26e467947bb3f7024329bd64901040).
Maybe somebody else here knows whether this ID *is* somehow important to know....
If it isn't important (for Humans) to know - then I would say we log a Feedback Item, and basically show something simpler instead....(Curious mammals can always do a View XML if they really want to see the gory details I guess...)
Citations: (7.4 Help, but similar in 7.3.1 etc).
Crestone Technology
MX
Hi John,
I don't actually know whether I could call the function with the "normal" name when it is saved with the hex name. I guess I got spooked and ran off without trying that. I'll give that a go tomorrow and report back here.
Stay tuned,
Elliott
Crestone Technology
MX
Hello Again, John,
1) You are right: despite the function appearing to be named with the hex id, I can call it with the "normal" name I expected
2) that means there is a workaround for calling functions with long parameter lists: ignore the hex text and call the function as I intended it to be named
3) thanks!
Details
- I created a function Test.Foo(...) that took five ClipboardPage parameters - enough to provoke Pega to give it a name that included the hex ID of the function
- I called it with this syntax: "@Test.Foo(tmpPage,tmpPage,tmpPage,tmpPage,tmpPage)"
- It worked
Behind the Scenes
Out of curiosity, I checked the XML for the function. pyRuleName, pxInsName and several other properties show the hex stuff: The lone dissenter is
pyRuleName: Test Foo--(ClipboardPage,ClipboardPagb83658a368d569a6176236c526a2808b
pxInsName: TEST!FOO--(CLIPBOARDPAGE,CLIPBOARDPAGB83658A368D569A6176236C526A2808B
One property shows the name as it was intended
Hello Again, John,
1) You are right: despite the function appearing to be named with the hex id, I can call it with the "normal" name I expected
2) that means there is a workaround for calling functions with long parameter lists: ignore the hex text and call the function as I intended it to be named
3) thanks!
Details
- I created a function Test.Foo(...) that took five ClipboardPage parameters - enough to provoke Pega to give it a name that included the hex ID of the function
- I called it with this syntax: "@Test.Foo(tmpPage,tmpPage,tmpPage,tmpPage,tmpPage)"
- It worked
Behind the Scenes
Out of curiosity, I checked the XML for the function. pyRuleName, pxInsName and several other properties show the hex stuff: The lone dissenter is
pyRuleName: Test Foo--(ClipboardPage,ClipboardPagb83658a368d569a6176236c526a2808b
pxInsName: TEST!FOO--(CLIPBOARDPAGE,CLIPBOARDPAGB83658A368D569A6176236C526A2808B
One property shows the name as it was intended
So, thanks again. Cheers,
Elliott