Custom Connectors - ISC's Poor Handling of Custom JARs

Hello all,

This is related to this thread that has been closed - Custom Connector JAR Loading. It seems that ISC handles custom connector JARs very poorly, and what’s worse, without any visible pattern. I am having issues with VA’s recognizing the custom connector jar and other dependency libraries. For example, I will create a custom connector source and upload the connector jar and a couple of dependency libraries that the connector needs. If I am lucky, it will recognize the custom class and tell me that there is a missing library. I upload the missing library to the source, wait forever for the changes to propagate, and instead of recognizing my uploaded library, it invalidates my custom connector class, saying that it cannot be found. At this point, nothing works - removing the jar, saving, adding the jar, saving, waiting, waiting, timing out. Sometimes recreating the source makes it work briefly until the next error is encountered, and eventually the source will die saying that the custom connector class cannot be found.

This is a pretty poor alternative to what IIQ had, where changes would have been instantaneous and there were no multiple hops, like S3 buckets, VAs, etc, and it was way easier to do incremental development on a custom connector. Just doesn’t seem to be any sort of consistency or pattern to how these JARs are handled in ISC. It’s all quite unstable. What’s worse, we have no way of knowing which versions VA is using or why it cannot find custom classes that have been uploaded and have worked previously. Once I make changes to the jar, it’s a toss-up whether the VA is going to pick them up.

Can SailPoint provide any recommendations here? How do we ensure that the source is using the latest and greatest versions of jars? How do we tell which version is available to the source at any given time?

EDIT: it also does not seem to propagate custom jars between all VAs in the cluster. I am looking at the docker location for these custom libs, and one VA has them and the other one does not. Could explain why all of a sudden it throws class not found exception.

@hari_patel @menno_pieters

2 Likes

Hi @Rockmus ,

Yes, I feel your frustration. I know the pain. I’ve been through it. Many libraries are available, like Gson and some XML parsers, but there is no documented list. In my experience, it is a bit of going back and forth. Try to limit your external dependencies.

– Menno

Regarding the jars, they should eventually be available on all VAs, but it may take a few minutes. The CCG needs to be restarted, which happens automatically once in a while to download new configurations, but you can log into the VA to do it yourself, to speed up your testing and development… Of course only in your sandbox environment :stuck_out_tongue:

1 Like

When CCG service is manually restarted, it seems to wipe out all custom connector libraries altogether, except for one library that is related to different OOTB connector, not the custom one. And I cannot get the 2 VAs to ever match in terms of the custom jars. The replication process is not working as expected, and I have a feeling it’s not an isolated incident. SailPoint is looking into this.

Regarding limiting external dependencies, unfortunately, I don’t think that’s possible as I am merely trying to make a SOAP based connector previously written for IIQ work in ISC. As you probably know, SOAP interfaces in Java are extremely heavy and require numerous dependencies to facilitate communication. All these dependencies are loaded by the default class loader in IIQ as other web services-based connectors already use them, but there is no such luxury in ISC.

For SOAP, you could also try the OOTB Web Services connector.

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.