Under review

HPRM Trim associations connector failing to import

Hayden Gray 1 year ago in UNIFYBroker/Micro Focus Content Manager updated 1 year ago 9

I am currently experiencing issues importing with a trim associations connector, I believe its the same as https://voice.unifysolutions.net/knowledge-bases/7/articles/3145-micro-focus-content-manager-associations-connector. The issue in particular is a timeout issue generating the below error. I don't recall a time when this connector was ever working as it has been misconfigured in the past. Please note other location connectors work fine and the agent connector successfully.

Image 6374

Some issue we had in the past, were this connector appeared to be mapped to the "location" connector and has since been update to the "associations".

Image 6375

Thinking something that was possibly incorrect with this config, I tried creating a new connector from scratch and the xml generated is the following, which appears to be the wrong connector type.

Image 6376

Apologies for the images instead of copy/paste, I cannot easily get the config out of the environment. Let me know if you need more information.

Currently running UNIFYBroker 5.3.3

HP TRIM connector

Under review

Hi Hayden,

The timeout is handled by the underlying connection, which means a response isn't being received inside the configured timeframe. This could be due to the system not being able to process the request in a timely manner, or a misconfigured connection. Given other connectors are working fine and the agent test is fine, I suspect the application just isn't handling the size of the request. 

Have you tried increasing the agent timeout, or adding an API filter to see if you can query a single record and determine if a response is received? See Filtering Connectors with an API Query / UNIFYBroker knowledge / UNIFY Solutions for more information on the filtering.

In the meantime I'll investigate the creation configuration issue you've outlined.

Thanks Matt,

I've attempted to increase the timeout to 10 minutes on the agent, however the connector seems to failing around the 1 minute mark or sooner. I have also tried decreasing the collection size on the connector to 50 records hoping that might improve things too, though it still seems to fail around the same point.

Hi Hayden,

Have you had a chance to try with the API filter? I've had a quick look, and both the timeout and the page size are passed through to the outgoing request. However there may still be too many records for the initial page to return a response. The actual request being made is in the control of the HPRM SDK, so I can't easily check how it's handling the timeout. Are you able to provide a screenshot of the agent configuration with the timeout configured?

In regards to your configuration issue, is this something you can reliably replicate? If so, it'd be good to jump on a screen sharing session or something - as I ran some testing and was unable to reproduce the problem. 

For further investigations, it'd be great to share the log file - particularly with the higher timeout. You mention it failed around the 1 minute mark, which is twice as long as the screenshot above - I'd be curious to know if it failed with the same error.

Hi Matt,

I'll try with a few different filters today and see how things go. There was an old filter remaining in the configuration so potentially this was causing the error, but yet to confirm. For reference though here is the below configured timeout:

Image 6377

For the configuration issue I've been able to replicate the issue many times, simply by selecting the following connector from the list creates the unexpected configuration.

Image 6378

Image 6379

Image 6380

Happy to jump in a screen share session to demonstrate this one if needed.

I'll try produce a few more errors for the logs as the connector has been turned off an get them to you, depending on how the filter testing goes today. Thanks

Thanks Hayden. Does the configuration issue replicate in a lower environment? And can you confirm that the installed version is 5.3.0 RTM? There was a newer version of the connector released (5.3.1 RTM) 5 months after 5.3.0, which may have the issue fixed. If the customer is truly on 5.3.0, can you try the update to 5.3.1 and see if the issue persists?

Yes I can replicate the configuration issue in test environment, and can confirm the version for the connector is 5.3.0 RTM in all environments.

What is interesting is the manual change to the association connector configuration does actually seem to import without timeout with the same connector filter in the test environment.

Image 6381

So probably an API issue im guessing for the timeout errors?

How much data gets returned in the test environment? It's likely that the filter being run in production is too large to get data returned in a time that the SDK is expecting. Strange the timeout isn't being respected, we can look into that a bit more but might be limited on solutions as we don't have an environment for ourselves to test against.

Sure. The import process for associations connector involves get all the relevant locations, then making a separate request for each one to get its associations. What I noticed is that all the association requests, regardless of how many locations, were being done in parallel. Limitations on threads and connections available to Broker would prevent all of the association requests from actually being run in parallel, but I suspect enough still were to bog down/overload CM, or at least something between Broker and CM.

The patch I provided limits the max number of parallel association requests to 10. This number is hard coded for now; it can be made configuration later on, if this approach helps.

Sorry for the delay in testing/implementing the patch.

Though the good news is I can now confirm the patch fixed the issues we were seeing in production.

Thanks for your help!