cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Provisioning to a JDBC Source via an external jar

Provisioning to a JDBC Source via an external jar

Disclaimer: Some information in this article may be outdated, please verify details by referring to latest resources or reach out to our technical teams.

Introduction

In an effort to better enable both partners and customers, we have outlined a process that allows technically savvy customers the ability to make modifications to their JDBC provisioning rule without directly engaging IdentityNow's Expert Services team. We do not recommend this approach if you do not have the correct technical resources on hand with at least an intermediate level knowledge of Java.

 

Prerequisites

  1. A functional JDBC source that is aggregating accounts into IdentityNow successfully.
  2. A JDBC Driver jar attached to the Source Config. (see Required JDBC Driver JAR Files)
  3. Eclipse or another IDE able to import Maven projects.
  4. The 'identityiq.jar' to import into your IDE. (Attached at the bottom).
  5. Intermediate knowledge of Java.
  6. Understanding of Account and Attribute requests within an IdentityNow provisioning plan.

 

Elements of the project

  1. JDBC Rule Adapter- This is the rule that will still be needed to be uploaded to your org by Expert Services or Professional Services. Essentially, this rule calls a 'provision' method in an attached jar and all the logic is built there. Getting passed into the method is the application, the connection to the database, the plan, and an *optional* log file. An example is attached below.
  2. Primary Java class- This is the main class that we will be using in our example. This is essentially the tunneling and logic portion of the code. It is the home of the 'provision' method, receives the account and attribute requests and directs the request to the appropriate calls in the auxiliary class in the project. (In the attached project, this is TestDemo.java)
  3. Auxiliary Java class- This is the class that executes stored procedures or (in this projects case) prepared statements to the target source and contains the methods that are called from the Primary Java class. In this project, it is called database.java

 

Building a project structure

Within Eclipse, or any other IDE, your file structure should be as follows:

 

Project Structure

 

Make sure that you have imported the 'identityiq.jar' and you can see it in your Maven dependencies.

 

Elements of the Primary Java class

This is the foundation that handles our project. Every request initially comes here and then calls other methods.

 

  1. Provision Method- This breaks down the request and calls the appropriate method for the operation:
    Provision Method
  2. Operation methods- These exist for every operation (Create, Modify, Enable, Disable).
    Create Method
  3. Now that a request has come in and we have defined it's type, we need to call the Auxiliary Java class in our project.

 

Elements of the Auxiliary Java class

  1. Static Final strings- We create both public and private final strings in order to streamline interacting with the database. This may include the query string and/or constants in the project.

    Constants
  2. Working methods- These are the working methods in the class. We have received the request, determined where it should go, and now need to execute it. Notice that it's simply a prepared statement that calls a final string

    Create Worker Method

Clean Compile Package

The next step is to compile your Maven package. Upload the jar that is created to the source config.

Upload screen

 

Final Notes:

JDBC Rules can be very complicated depending on the source you are trying to connect to. We STRONGLY recommend that if you have any questions, bring them up to the Expert Services team for assistance.

Labels (1)
Attachments
Comments

What's best practice for handling operations that aren't supported? For example, what should we return for a JDBC Source that doesn't support Disable/Enable Operations?  

The sample code in TestDemo.java and the other doc here seems to imply you can just leave the ProvisioningResult at whatever the constructor defaults to?  Is that correct?

What is right build path for this project?

I'm getting error - Description Resource Path Location Type
The project was not built since its build path is incomplete. Cannot find the class file for org.aspectj.lang.JoinPoint$StaticPart. Fix the build path then try building this project jdbc-template Unknown Java Problem.

Currently i'm using Eclipse IDE to build this project and using Embedded 3.3.9 Maven version.

Do you think there is an issue with Maven version?

 

 

Rahul,

Try adding aspectjrt jar file to your project referenced libraries.

You can find it in the WEB-INF/lib folder of identityiq.

I'm getting error for external jar - java.security.PrivilegedActionException: org.apache.bsf.BSFException: BeanShell script error: bsh.EvalError: Sourced file: inline evaluation of: `` import sailpoint.services.rule.TestDemo; import org.apache.commons.loggin . . . '' : Error in method invocation: Static method provision(sailpoint.object.Application, org.apache.commons.dbcp2.PoolingDataSource$PoolGuardConnectionWrapper, sailpoint.object.ProvisioningPlan, org.apache.logging.log4j.jcl.Log4jLog) not found in class'sailpoint.services.rule.TestDemo'

What would be the possible root cause of this issue?

Is there any issue with import statement in  "JDBC Rule Adapter.xml"?

I think issue may be with import statement - import sailpoint.services.rule.TestDemo.

instead of import specific class, import package might help. 

Please give pointer on this if anyone faced similar issue before.

 

@rahul-bhosale Not sure if you ever got this figured out, but if so, maybe help for future cases: I had the same error and I realized the rule attached to this document is creating a _log variable using Log _log = LogFactory.getLog("customJDBCLog") and then sending that as the log argument in the provision method. However, in the attached jar file, the provision method is expecting the Log parameter to be of the SailPoint Log interface type. I changed my jar file to include org.apache.commons.logging and updated that parameter to an apache log and my rule was then able to call the method.

For general review: is it possible to get documentation on that log and how to access logs created from the jar file? I used System.out.println, which writes to the ccg, but would like to know if/how we can access a log specific to the jar.

@cassidiopia  Yes i have figured out the same. I did bit different changes than what you did, I used -

import openconnector.Log;
Log _log = LogFactory.getLog("customJDBCLog");  

And import the same in jar.  It helps me to print log in ccg.log file.

I am able to print log in ccg using log.info, log.debug etc.

Hope this help

@cassidiopia  @rahul-bhosale  @wimvandijck 

Hi,

Can we use a similar adapter rule (similar to the one which is attached in the main post) for provisioning to multiple JDBC sources? I mean same rule attached to multiple sources and Java class doing the logic to provision to respective jdbc source tables?

 

 

Can we use Stored Procedures instead of quires?

@hafeez_rahman_fb 

you could make that work, yes. I think it would require more complexity within the jar file. As one example, the class that your rule imports could simply contain the provision method that is called by the rule. Then you could have additional methods for account request operations and additional classes for separate sources. Depending on the variance of your source accounts, the attributes, and the entitlement names, the complexity may grow but is certainly manageable that way.

@Sri_Veera 

yes, you can. You can use a CallableStatement in your jar file to achieve that. I have tested it and it works fine. I had some issues with the ResultSet but that might have been our DBAs and the statements still worked so it wasn’t a big deal.

Version history
Revision #:
2 of 2
Last update:
‎Sep 04, 2024 04:29 PM
Updated by:
 
Contributors