Big news! The community will be moving to a new platform April 21. Read more.
Big news! The community will be moving to a new platform April 21. Read more.
Commodore
Commodore
404 views

Timeouts on concurrent calls to Web Service

Has anyone ran into issues with web service calls timing out when calling UA web services.

Here's what we have, we're not sure it's actually the UA but want some input.

We have a 3rd party application that calls one of our drivers and makes a call to an event service bus driver that then calls on the UA through a soap call using web services. It seems concurrent calls possibly fail along the path. I'm curious if anyone has seen anything similar or has some advice on how to track this issue. We've opened a high level request with MF support but honestly their support is paltry most times. If anyone would like a deeper explanation I can offer that, but this is the simplified issue.
Labels (1)
0 Likes
1 Reply
Absent Member.
Absent Member.

On 2018-08-23 20:36, jburns80 wrote:
>
> Has anyone ran into issues with web service calls timing out when
> calling UA web services.
>
> Here's what we have, we're not sure it's actually the UA but want some
> input.
>
> We have a 3rd party application that calls one of our drivers and makes
> a call to an event service bus driver that then calls on the UA through
> a soap call using web services. It seems concurrent calls possibly fail
> along the path. I'm curious if anyone has seen anything similar or has
> some advice on how to track this issue. We've opened a high level
> request with MF support but honestly their support is paltry most times.
> If anyone would like a deeper explanation I can offer that, but this is
> the simplified issue.
>
>

Regardless of which service or API you use, fault tolerance at the client side is a requirement.

Many of our customers use organization information (can be geographic, economic or business organization) for different
authorizations in AD, GSuite, Azure etc. Most of these are represented as roles and resources on IDM and on large organization
changes thousands of roles and resources are created, thousands removed, and assignments changed. To handle this in a good way
we use the following approach:

All REST and SOAP integrations are done using workflows. In the workflow we always verify the result to make sure we retry if
required. In most cases the workflow is initiated from the policy builder and we always use the error variable available to make
sure we retry events that fail. This can be done by either setting status to retry or by creating a loop that retries.
In the workflow I would suggest a short sleep between retries. For policies that sets status to retry there should be an
automatic retry but for those were you create a loop you will have to implement a sleep.

The true reason for why these fails is quite hard to track. Some might fail even before they hit the REST/SOAP interface
(network related, lost IP connections etc.), some might fail at the application server (session and thread limitations) and some
may fail at the REST or SOAP endpoints.

Best regards,
Tobias
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.