Web Service Account Aggregation producting arrays instead of individual values

IdentityIQ (IIQ) IIQ Discussion and Questions
, ,
1

Which IIQ version are you inquiring about?

8.3

I have a web service connector is not correctly parsing the SOAP XML response that it receives into individual field values. Instead of seeing something like UserID=abc123 in the processed response object for a single record, I see UserID=[abc123,def456…n] where the list includes all UserID values in the XML document.

Below is an example of the XML response that I am getting back. I have no control over the response schema unfortunately.

<soap:Envelope>
  <soap:Body>
    <RetrieveResponseMsg>
      <Results>
                <Properties>
                    <Property>
                        <Name>AccountUserID</Name>
                        <Value>735453334</Value>
                    </Property>
                    <Property>
                        <Name>UserID</Name>
                        <Value>[email protected]</Value>
                    </Property>
                    <Property>
                        <Name>EmailAddress</Name>
                        <Value>[email protected]</Value>
                    </Property>
                    <Property>
                        <Name>CustomerKey</Name>
                        <Value>3c493b86-13ed-4f42-a70c-622c9a1db3d3</Value>
                    </Property>
                    <Property>
                        <Name>ActiveFlag</Name>
                        <Value>True</Value>
                    </Property>
                    <Property>
                        <Name>LastSuccessfulLogin</Name>
                        <Value>10/31/2024 10:28:49 AM</Value>
                    </Property>
                </Properties>
            </Results>
            <Results>
                <Properties>
                    <Property>
                        <Name>AccountUserID</Name>
                        <Value>735454281</Value>
                    </Property>
                    <Property>
                        <Name>UserID</Name>
                        <Value>[email protected]</Value>
                    </Property>
                    <Property>
                        <Name>EmailAddress</Name>
                        <Value>[email protected]</Value>
                    </Property>
                    <Property>
                        <Name>CustomerKey</Name>
                        <Value>2a7d9103-d278-4c11-8237-70dbda8d8798</Value>
                    </Property>
                    <Property>
                        <Name>ActiveFlag</Name>
                        <Value>True</Value>
                    </Property>
                    <Property>
                        <Name>LastSuccessfulLogin</Name>
                        <Value>9/17/2024 1:53:57 PM</Value>
                    </Property>
                </Properties>
            </Results>
      </RetrieveResponseMsg>
    </soap:Body>
</soap:Envelope>

Root path: //soap:Envelope/soap:Body/RetrieveResponseMsg (although I have tried other variations with no difference)

Response Mapping Example
Schema Attribute - UserID
Attribute Path - //Results/Properties/Property/Name[text()=“UserID”]/following-sibling::Value/text()

When I enter the above XML and XPath expression
//RetrieveResponseMsg/Results/Properties/Property/Name[text()="UserID"]/following-sibling::Value/text()
into an online XPath tester, I do get both UserID values returned. If I change the XPath expression to
//RetrieveResponseMsg/Results[1]/Properties/Property/Name[text()="UserID"]/following-sibling::Value/text(),
I only get the first UserID.

How can I get my account aggregation task to essentially iterate over the Results blocks and only get the field values for the nth instance each time so that I do not get a list of all possible values for each field for every record? That is what I am seeing now. If I change the path to include Results[1], I get a single record that has all possible values for every field, which still does not do me any good.

I really am hoping that I don’t need to manually process the SOAP response to figure out which results map to identity cubes in our system and would appreciate some guidance. Thanks in advance.

2

Hi @src125,

To address the issue of the Web Service Connector in SailPoint IdentityIQ, you can adjust your XPath expressions to ensure that each ‘Results’ block is processed individually.

Set your root path to

//soap:Envelope/soap:Body/RetrieveResponseMsg/Results`l’. This allows you to focus on each ‘Results’ element separately.

Modify your XPath expression for the UserID attribute to iterate through each Results block:
   Xpath
  
//soap:Envelope/soap:Body/RetrieveResponseMsg/Results[1]/Properties/Property[Name=UserID]/Value/text()

To fetch the second record, change [1] to [2], and so forth.

In your aggregation task, you may need to implement a loop or a rule that iterates over the Results nodes. This can be done using a custom aggregation rule or script that processes each node individually.

If necessary, create a Before Aggregation Rule that processes the raw XML response and extracts individual records into a suitable format before they are mapped to attributes in IdentityIQ.

By doing these steps, you should be able to parse the SOAP XML response correctly and avoid getting a list of all possible values for each field across all records. If further customisations is needed, consider implementing a custom rule to handle more complex parsing logic.

1 Like
3

Thank you very much for the information! I will put together a custom aggregation rule as you suggested.

1 Like
4

Hi @src125 actually, @vinnysail provided valuable insights, and here you are some thoughts as well:

  1. Set the Root Path to:

//soap:Envelope/soap:Body/RetrieveResponseMsg/Results

  1. Use relative XPath for attributes:
  • UserID: Properties/Property[Name=“UserID”]/Value/text()
  • AccountUserID: Properties/Property[Name=“AccountUserID”]/Value/text()
  • Repeat for other fields.
  1. If transformations are required:
  • Implement a Before Aggregation Rule to manipulate the XML before aggregation.
  • Use a Custom Aggregation Rule for advanced processing.

By following these steps, you should be able to achieve efficient and accurate parsing of the SOAP XML response.

2 Likes