Use Case
During implementation using AD/LDAP connector's provisioning use-cases and if the business requirement is complex in nature, for example, if there are 100's of conditioning required to provision AD groups based on specific user attributes, the integrators typically configure multiple if-else conditions for every unique user attribute based on which an AD group needs to be assigned. When the number of if-else conditions stacks up and the size of JSON exceeds ~
65535 bytes, we start to run into the runtime error: “Method code too large”.
This is seen when we do the binding for a provisioning JSON(EnableAccountJSON in this case) and the entire JSON is used for creating the template for binding the parameters, since the entire JOSN is being used for binding, we will not be able to split the JSON into multiple JSON’s and bind it separately(which is typically the resolution steps).
Below is the JSON Syntax(with multiple if-else) where one if-else looks like the below(Sample If Else Snip) which could possibly lead to a "Method code too large" exception. In the "JSON Structure(with multiple if-else)" sample, the "ENABLEACCOUNTOU" variable has the entire JSON with multiple nested If-else conditions which will then have to bind and transform out to ${} to a value. Due to this nature, we will not be able to split the JSON into multiple JSONs and bind it separately.
Sample If Else Snip
if(null!=task.accountKey.customproperty14?task.accountKey.customproperty14.toLowerCase().contains('Contractor or Vendor'.toLowerCase()):'' || null!=task.accountKey.customproperty14?task.accountKey.customproperty14.toLowerCase().contains('Contractor or Vendor - No Mailbox'.toLowerCase()):''){
if(null!=task.accountKey.customproperty25?task.accountKey.customproperty25.equalsIgnoreCase('A'):''){
'OU=A,OU=AA,OU=AAA'
}
else if(null!=task.accountKey.customproperty25?task.accountKey.customproperty25.equalsIgnoreCase('B'):''){
'OU=B,OU=AA,OU=AAA'
}
###Assuming that there was 100s of similar nested if-else conditions###
else{
'OU=C,OU=AA,OU=AAA'
}
}
JSON Structure(with multiple if-else)
{
"USEDNFROMACCOUNT": "YES",
"MOVEDN": "YES",
"REMOVEGROUPS": "NO",
"ENABLEACCOUNTOU":"${
if(){
if(){''}
else if(){''}
###Assuming that there was 100s of similar nested if-else conditions###
else{''}
}
else if(){
if(){
if(){''}
else if(){''}
###Assuming that there was 100s of similar nested if-else conditions###
else{''}
}
###Assuming that there was 100s of similar nested if-else conditions###
else if(){
if(){
if(){''}
else if(){''}
###Assuming that there was 100s of similar nested if-else conditions###
else{''}
}
else{
if(){''}
else if(){''}
###Assuming that there was 100s of similar nested if-else conditions###
else{''}
}}}
else {
if(){''}
else if(){''}
###Assuming that there was 100s of similar nested if-else conditions###
else{''}
}
},DC=X,DC=XX,DC=XXX",
"AFTERMOVEACTIONS": {
"userAccountControl": "512"
}
}
Pre-requisites
Must have AD connection set up and primary use-case around provisioning use case must be validated.
Applicable Version(s)
All
Solution
Option 1
Modify the JSON to eliminate as many "if else" blocks as possible by clubbing similar conditions with 'or' operations that assign the same group.
Example:
If(null!=task.accountKey.customproperty25 && (task.accountKey.customproperty25.equalsIgnoreCase('ABC')
|| task.accountKey.customproperty25.equalsIgnoreCase('DEF')
|| task.accountKey.customproperty25.equalsIgnoreCase('GHI') ) ){
'OU=' + task.accountKey.customproperty25 + ',OU=AA,OU=AAA'
}
Option 2
Alternatively, you can also explore options to create a map with keys and values that can be iterated based on the keys/condition. The values can then be substituted.
You can refer to example 3 of the "RemoveAccessJSON" section in the document below...
