Siebel Integration – Forcing LCM Provisioning via API Instead of OOTB Connector

IdentityIQ (IIQ) IIQ Discussion and Questions
, , ,
1

Hello everyone,

I’m currently working on a Siebel integration in SailPoint IdentityIQ and would appreciate your insights on a design challenge.

Current Setup

  • We are using the OOTB Siebel connector strictly for:

    • Account aggregation

    • Responsibilities aggregation

    • Positions aggregation

  • This approach works well, especially since attempting aggregation via API results in timeouts.

Requirement

We need to provision accounts via API (Web Services connector) to support:

  • Creating users

  • Assigning:

    • Primary Responsibility + Additional Responsibilities

    • Primary Position + Additional Positions

  • The API handles the “primary” designation explicitly, which is not feasible through the OOTB connector.

Issue

When using LCM provisioning, SailPoint continues to generate and execute provisioning plans against the OOTB Siebel application, even though:

  • I have removed/disabled the provisioning configuration from the OOTB connector

  • I configured provisioning on the Web Services application

However, LCM still routes provisioning to the OOTB application instead of the API-based one.

Question

What is the best practice to enforce provisioning through the Web Services connector (API) while still using the OOTB Siebel connector for aggregation only?

Any recommendations on how to:

  • Override LCM provisioning behavior?

  • Force provisioning to a specific application (Web Services)?

  • Or architect this hybrid approach properly?

Thanks in advance!

2

Hi @IslamElkhouly,

I’ve recently developed something similar using an OOTB connector & JDBC application. Where I had the JDBC application do the aggregation (so that we could partition the account aggregation as the OOTB connector didn’t support it) and then use the OOTB connector for the provisioning.

To achieve this you use what’s called a “Dual Channel” connector see this link for an example https://community.sailpoint.com/t5/IdentityIQ-Forum/Mixed-connector-for-in-outbound/m-p/131985#M113866

But really what you would do is add a ProvisioningConfig (see below) to your Web Services app. Therefor all provisioning operations for the Siebel application would instead be done through Web Services app. Let me know if this works or if you run into any issues with this approach.

<ProvisioningConfig>
    <ManagedResource name="Siebel">
      <ApplicationRef>
        <Reference class="sailpoint.object.Application" name="Siebel Application"/>
      </ApplicationRef>
    </ManagedResource>
  </ProvisioningConfig>
3

@IslamElkhouly This is a rare usecase but can be achieved by Dual channel concept as shared by @ronald_davis .

However, I would like to know why can’t you use single connector? Means why your Siebel connector can’t do the provisioning or why can;t you run the aggregation on web services application? Having a single connector simpliified the design.

4

Thanks, that works for me. However, I’d like to highlight one point: the first application name refers to the application you need to provision to, while the second application name refers to the application you aggregated from.

5

There are several requirements, but the customer’s main request is to assign a primary position and responsibility during account creation, ensuring the first is marked as primary and the rest as additional. They also need support for multiple operations, such as changing the primary position and responsibility. When we used the out-of-the-box Siebel connector, it failed in some of these operations, so we decided to use the API instead.

6

@IslamElkhouly Coupa also had a similar setup. where you need to assign the entitlements in the same order, default first and additional second. we achieved this with Webservices connector alone. See if its not too late, convert your app to Webservices connector.

7

Yeah, that was our initial approach. However, when we attempted aggregation using the Web Services connector, we encountered timeouts due to the large volume of accounts on the customer side.

8

Have you tried doing the partitioning or pagination?

9

No, it times out when the application stakeholder tries to retrieve all users via the API; aggregation via SailPoint is not being used.