Hello!
I’m trying to implement a managed system using the script connector, and part of its function is to fetch the group memberships from an user. Can you provide a basic implementation that fetches groups by displayname and managed system id?
Currently, I have something like this:
private List<Group> getUserGroups(User user, UserConnectorObject ucb) {
GroupRabbitMQService grpService = appContext.getBean(GroupRabbitMQService.class)
GroupSearchBean gsb = new GroupSearchBean()
// sets managed system ID
gsb.addManagedSystemId(ucb.getMetaData().getManagedSystemId())
// how to add the group name or a list of group names??
gsb.addAttribute()
def groupList = grpService.findBeans(gsb, 0,50)
if (groupList.isEmpty())
throw new ConnectorException(ConnectorErrorCode.INVALID_SEARCH_QUERY, new NoSuchElementException("No groups found"))
return groupList
}
Thanks in advance!
Cristhian
Hello Cristhian,
Please use the method below:
private List<Group> getUserGroups(User user, UserConnectorObject ucb) {
GroupRabbitMQService grpService = appContext.getBean(GroupRabbitMQService.class)
GroupSearchBean gsb = new GroupSearchBean()
// sets managed system ID
gsb.addManagedSystemId(ucb.getMetaData().getManagedSystemId())
// to add group name in the search bean use the below.
gsb.setNameToken(new SearchParam(groupname, MatchType.EXACT))
def groupList = grpService.findBeans(gsb, 0,50)
if (groupList.isEmpty())
throw new ConnectorException(ConnectorErrorCode.INVALID_SEARCH_QUERY, new NoSuchElementException("No groups found"))
return groupList
}
Please let me know if you have any questions.
Thanks,
Ameet
1 Like
Hello Ameet!
I’m trying to use the provided snippet inside a managed system’s groovy script, and I’m getting the following errors inside the script connector:
2025-06-09 13:39:03.391 ERROR 1 --- [sageListener-20] .s.AbstractGroovyScriptEngineIntegration : Script name :/connector/groovy/siebel/user/TestUserAdd.groovy. Error message : org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
/connector/groovy/siebel/user/TestUserAdd.groovy: 12: unable to resolve class org.openiam.common.beans.mq.UserRabbitMQService
@ line 12, column 1.
import org.openiam.common.beans.mq.UserRabbitMQService
^
/connector/groovy/siebel/user/TestUserAdd.groovy: 11: unable to resolve class org.openiam.common.beans.mq.GroupRabbitMQService
@ line 11, column 1.
import org.openiam.common.beans.mq.GroupRabbitMQService
^
2 errors
I was using the following tutorial as a starting point: Finding Users with Groovy Script in OpenIAM - neilherbertuk
What could be the cause?
Thanks again for your support
Cristhian
Hello Cristhian,
Could you please share the script file (TestUserAdd.groovy
) that is throwing the error? I’d like to have a member of my team to review it to better understand the issue and provide the necessary support.
Thanks.
Hello!
please find the script attached.
Thank you for your help!
SiebelUserAdd_groovy.txt (10.2 KB)
Thanks, Cristhian. One of our team members is reviewing your script and we will update you with feedback.
Hello Cristhian,
I have gotten feedback on the script from my team member which I have shared below:
**
I have reviewed the SiebelUserAdd
class that was shared.
I wanted to point out that the findUser
and getUserGroups
methods are not appropriate within this class. This class is specifically meant for pushing data to the external system (in this case, Siebel). Any user or group validation, search, or filtering logic should not be handled here.
Such pre-checks or conditions should ideally be implemented within the ProvServicePreProcessor
scripts. Alternatively, the data can be restricted and transformed appropriately using policy map scripts during provisioning.
Additionally, the use of the following classes:
import org.openiam.common.beans.mq.GroupRabbitMQService;
import org.openiam.common.beans.mq.UserRabbitMQService;
is not appropriate in this context. These classes belong to a different service layer and are not meant to be called from within connector-related classes. Their use here introduces cross-service dependencies, which may lead to runtime exceptions or service resolution issues during execution.
To maintain a clean architecture and separation of responsibilities, I recommend removing these methods from this class and relocating the logic to a more appropriate layer as discussed.
Please let me know if you need any help restructuring this.
**
Thanks,
Ameet
Hi Ameet!
Thank you and your team for helping me figure out this issue. I’ll review the pre-processor scripts and the policy map configuration.
I’ll update this topic if I have any further questions.
Best regards,
Cristhian