Objects to be used with Sailpoint.Utils.objects.AccountRequest

[jnymeyer (Jim Nymeyer)]

Hello,

We are attempting to build a ConnectorBeforeModify rule but are unclear as to the available attributes/objects that can be used with it in Powershell.

In the below example New-Object Sailpoint.Utils.objects.AccountRequest($xmlReader) is assigned to $requestObject. We would like to subsequently leverage $requestObject.<some account attributes/objects> but are unsure of what attributes and objects we can utilize. We could not locate in the documentation, but are perhaps missing something. Any assistance would be appreciated.

Thanks.

Example:

""

if($enableDebug) {
    LogToFile("Entering beforeScript")
}

try {

    ##########################
    # Begin SailPoint protected code -- do not modify this code block
    #
        $sReader = New-Object System.IO.StringReader([System.String]$requestString);
        $xmlReader = [System.xml.XmlTextReader]([sailpoint.utils.xml.XmlUtil]::getReader($sReader));
        $requestObject = New-Object Sailpoint.Utils.objects.AccountRequest($xmlReader);

        #debug line for testing
        if($enableDebug) {
            LogToFile("Request object contents:")
            LogToFile($requestObject | Out-String)
        }
    #
    # End SailPoint protected code
    ##########################


    ##########################
    # Begin Client-provided code

    #get the necessary info we need from the accountRequest object
    #as an example: $nativeIdentity = $requestObject.nativeIdentity

    #do whatever work needs to be done here

    #
    # End Client-provided code
}
catch {
    $ErrorMessage = $_.Exception.Message
   $ErrorItem = $_.Exception.ItemName
   LogToFile("Error: Item = $ErrorItem -> Message = $ErrorMessage")
}

if($enableDebug) {
    LogToFile("Exiting beforeScript")
}

""

[sushant1 (Sushant Kulkarni)]

Hi @jnymeyer

Have you reviewed this architectural best practices document here?

Before and After Operations on Source Account Rule | SailPoint Developer...

An easier way to develop is decouple your entire logic from the native rule, by just calling a powershell script that can be somewhere on the IQService Host. That way, you can easily update your script if needed, without having to re-deploy the connector rule.

Why that also helps with your query, is because you can open this powershell in Windows Powershell ISE, and have autocomplete suggestions! The Utils.dll which is used for most of these methods gets loaded in memory after one manual script run, and then you should see autocompletes for variables like $requestObject.

Like this:

[jnymeyer (Jim Nymeyer)]

Thank you Sushant. I had previously reviewed the documents and am building the logic in Powershell, but I was unaware of the ISE auto-completion of the methods via the Utils.dll–which was the missing piece. I appreciate the clarification.