In this last part in the series, I’m going to look at some other common errors which you might hit when creating an adhoc role using the WF_DIRECTORY APIs. The first part of the series can be read here, and the second part is here.
The table below lists the error numbers and messages which can be returned by the WF_DIRECTORY package – the SQLCODE returned by the error will always be -20002, with the error number included in the text of the SQLERRM.
|Error Name||Number||Error Message|
|WF_DUP_ROLE||395||Duplicate role &DISPNAME (‘&ROLENAME’)|
|WF_INVALID_ROLE||396||Invalid role name ‘&ROLENAME’|
|WF_DUP_USER||397||Duplicate user &DISPNAME (‘&USERNAME’)|
|WF_INVALID_USER||398||Invalid user name ‘&USERNAME’|
|WF_NO_LANG_TERR||399||Could not resolve NLS language and territory|
|WF_INVALID_NTF_PREF||4004||‘&NTF_PREF’ is not an allowed notification preference.|
|WF_INVAL_CONCAT_NAME||4001||‘&NAME’ is an invalid internal name because it contains a colon. For this particular role, if the name contains a colon, it has to be ‘&ORIG_SYSTEM:&ORIG_SYS_ID’ .|
|WF_ROLENAME_TOO_LONG||4002||‘&NAME’ exceeds the maximimum length of &LENGTH characters.|
|WF_INVALID_ROLE_STATUS||4003||‘&STATUS’ is not an allowed status.|
|WF_DUP_USER_ROLE||4016||User/Role relationship for user ‘&UNAME’ and role ‘&RNAME’ already exists.|
This list of errors is not a definitive list of every error which may be thrown by the API, this is a list of the most likely ones which can occur when using adhoc roles.
If you need to look for any of these errors in your code, then include the error codes within the exception handler – one thing to be careful of (and it’s caught me in the past!) is that if you are working in multiple languages, ensure that you only look for the error number rather than the error message as well. For example, check for “%4016%” within SQLERRM rather than looking for “%4016%already exists”, since the text will vary depending on the Workflow language!