Question
Log Error: Library X has inconsistent Rule-Utility-Function key / implementation issues
I saw this error in our dev logs, earlier today (v6.2/sp2 app)... not quite sure if this is a real error, or how I need to solve it. I'm just short of time to dig into this stuff.
One of our developers was working on a separate function in library X. This appears to save fine, and compiles fine, but this error appears to be thrown at runtime executing another function in X.
I'm aware that you can do different signatures for a function, and surely these can exist in different versions.
I'm just missing where the snag is here. I guess here that the first version is different, so we could probably delete it... we might have to unlock the ruleset though.
Level: ERROR
Category: com.pega.pegarules.generation.internal.library.LibLibraryDef
Message: Library X has inconsistent Rule-Utility-Function key / implementation issues.
These may be the result of merging the Function from another ruleset.
Please resave all prototypes into a higher ruleset and remove the bad functions. Duplicate function signatures for one pxInsName: X!SCANFORVIRUS
selecting: ScanForVirus--(String,String,PublicAPI) : RULE-UTILITY-FUNCTION X SCANFORVIRUS #20141224T102207.481 GMT (X:01-10-47)
selecting: ScanForVirus--(String,String,String,PublicAPI) : RULE-UTILITY-FUNCTION X SCANFORVIRUS #20150109T140607.673 GMT (X:01-10-48)
selecting: ScanForVirus--(String,String,String,PublicAPI) : RULE-UTILITY-FUNCTION X SCANFORVIRUS #20150128T060825.665 GMT (X:01-11-01)
selecting: ScanForVirus--(String,String,String,PublicAPI) : RULE-UTILITY-FUNCTION X SCANFORVIRUS #20150306T194011.081 GMT (X:01-12-01)Questions -
- What are the ramifications of this problem?
- How can we catch this error at design time (or even library-compilation time)?
- Is this problem the same in v7?
see also https://pdn.pega.com/support-articles/duplicate-library-function-errors-in-the-pegarules-log
***Updated by moderator: Marissa to close post***
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Hello Jon,
I did find this analysis about this issue in PRPC 6.3.
"... due to design problems/bugs in the way Function Overloads were handled at creation/Save time. We have fixed this completely in ML8 as part of EPIC-9142. So if the customer is considering updating to ML8, that would be great.
Basically, we need to check all the callers to that function! Which signature are they using? If only the 6-3-15 one, then we're good.
Withdrawn availability does not work for functions. It was never implemented really. the Withdrawn concept, came after RUFs were done. Yet in ML8 , as part of EPIC-9142, we also added support for withdrawn to functions. So in 7.1.8, it's much better
For 6.3, withdrawing the function won't help. But you can make it Availability = NO. --- do NOT use availability = Blocked. that will cause run time errors for any rule that attempts to all the function. That would be a good way to overcome their problems, However those rulesets are locked , so it may be a challenge to mark them Availability = No"