uimapi does not run on main hub since 20.4.

[Olaf Pape]

Hi,

I upgraded my test servers to 20.4. I have a main hub, oc server and a cabi server.
As usual I deployed all other components (like uimapi) manually. After installing the uimapi package on the main hub I noticed that I only receive 500 - server error messages. While troubleshooting, I noticed a note in the uimapi documentation in the techdocs: "For UIM 20.3 or later, deploy the uimapi package to the OC robot in your UIM environment to access the uimapi REST APIs."
OK - 20.3.2 still worked on the Main Hub.
I installed the uimapi on the OC server and - what a surprise - the uimapi works on the OC server as expected.

In my opinion, this is a conceptual error. I prefer to locate the uimapi functionally on the primary server (main hub) rather than on the " second priority" GU server.
The main hub has to be processed with the highest priority in order to ensure a functioning monitoring with automatic alarm workflow and alerting, e.g. via SMS in case of a failure (even on weekends). The " second priority" GUI server can also be offline for some time.
I know there are other scenarios where the operators do the whole job in front of the OC, but at my customers a lot (some almost everything) is handled by alarm workflow and various types of alerting. Only in rare cases do they look at the OC.

Or does anyone know what component needs to run on the main hub for uimapi to run there even now?

Thanks,

[David Michel]

The backend is related to this.
To complete all of the calls some of the additional jar files found at the OC robot are needed.

[Andrew Cooper]

Because of this we have had to raise the "priority" of one of the OC's to ensure continuity of service for the monitoring environment.

Regards, Andrew

------------------------------
Knows a little about UIM/DXim, AE, Automic
------------------------------

[Luc Christiaens]

With following packages/apps on your main/ha_hub uimapi should work: (9.20 upgraded to 20.4.2)

[Christopher Pearson]

Per what David noted, this needs to be on the OC server. If you would like to upvote the following:

https://community.broadcom.com/participate/ideation-home/viewidea?IdeationKey=4cb0a87a-5542-4bbd-86a3-d4d945450e34

[Andrew Cooper]

Hi

It seems @David Michel and @Luc Christiaens are both correct (just Luc is more correct)

If you install 20.4 on OC it works except for the /hubs/<domain>/<hub>/robots call (more on that in a moment)
If you install 20.4 on PRIMARY HUB it fails with authentication issue due to OCAuth jars not being present

If you install 20.3.3-HF1 on OC it works except for the /hubs/<domain>/<hub>/robots call (same as 20.4 not sure at which version it stopped working)
If you install 20.3.3-HF1 on PRIMARY HUB it works (full functionality as far as I can workout)

Upgrading 20.3.3-HF1 to 20.4 on either node keeps the same functionality, so on PRIMARY HUB if 20.4 is an upgrade from a previous version as Luc pointed out you you get full functionality (So I have up voted the Idea but I believe uimapi should work on other robots (like OC) as this allows us to spread the "load" to other CPU and other hubs robots) so have opened an issue with the functionality on OC.

The reason that 20.3.3-HF1 and 20.4 do not do offer full functionality is that when they start up they try to determine the local hub (but OC is not running on hub by design/recommendation) and fails so if a hub call is made that is not the OC robots hub then the hubs call will fail.

I hope this provides some guidance about how to deal/work-around the current uimapi functionality

Regards, Andrew


​​​

------------------------------
Knows a little about UIM/DXim, AE, Automic
------------------------------

[Andrew Cooper]

OOPs,  Have found that after a restart of the PRIMARY robot (rather than just the wasp) the uimapi no longer works and we get the authentication error about missing OC jar files.  Seems for Luc's upgrade option you need to go further back as he has done 9.20 -> 20.4

------------------------------
Knows a little about UIM/DXim, AE, Automic
------------------------------

[Olaf Pape]

I decided to rebuild the wasp with all the required components from scratch on the Main Hub. For this I removed all webapps, deleted the probe wasp and removed the remaining files. Afterwards deployed the following packages:

• wasp  20.42
• uimhome 20.4.0
• mps 20.40
• uimesdplatelemetry 20.40
• adminconsolapp 20.40
• uimapi 20.40

Result when accessing uimapi - disappointing:

I have already upvoted Christopher's idea.

[David Michel]

/hubs/{domain}/{hub}/robots does work at my OC robot.

[Andrew Cooper]

@Olaf Pape This is exactly the error I get with 20.4 (20.3.3-HF1 works fine)

@David Michel my issue is when I do /hubs/{domain}/{hub not local to OC}/robots as /hubs/{domain}/{primary hub}/robots works as expected and other paths also work like /robots and /robots/{id}

uimapi.log shows unable to connect to :48007 (which would normally be a hub port)

Regards, Andrew
​​

------------------------------
Knows a little about UIM/DXim, AE, Automic
------------------------------

[David Michel]

Andrew, 
confirmed, please open a support case for it.

[Andrew Cooper]

@David Michel Would you open an issue on this as currently we have an "entitlement" issue (our product has be assigned to the supplier/distributor so I can no longer open issues on UIM.  It happens every 2 years or so and after a couple of months of discussion it gets "resolved"​, but in the meantime cannot open new issues :)

Thanks, Andrew

------------------------------
Knows a little about UIM/DXim, AE, Automic
------------------------------

[Andrew Cooper]

David

The Issue with this not working is when the OC server does not have access to the hub directly (blocked by firewall) and only tunnel port (hub-2-hub) is allowed.  In our test environment we had configured tunnels (hub-hub) but direct OC to any hub was not blocked the api calls worked when we then blocked (at the firewall level) the api failed with the above error.

I hope this clears up the use case as we have seen it.

Thanks, Andrew

------------------------------
Knows a little about UIM/DXim, AE, Automic
------------------------------

[Luc Christiaens]

I have several Perl (both supported Perl versions) probes running with UIMAPI, and there we remarked last week that running with uimapi 20.40 or higher gave an "unauthorized" error. 
Support found that from uimapi 20.40 uimapi dit not use realm: NimJAAS anymore, but: wasp-engine
Not sure if that can be related?

[Matthias Gruber]

Since the feature to run uimapi on the primary hub, was working till 20.4 lots of our scripts and incomming webhook-Implementation use this,  there is no need for a OC in that case, just pushing alarms into it, reading/pushing configs etc...
How about the praised API-Feature to implement such solutions and now it only works with a running OC? Strange architecture decission, hopefully this will be turned back.
Naturally I upvoted, but it is another bad example how decissionmaking at Broadcom is done.... at the end you have to raise an idea for features they are once working.... and if I remember right, there was once a time where we told that "uimapi" is designed to run the mainhub not on "ump"-Host... and now... but I will doublecheck that... hopefully I mixed things in this case...:-) 

cheers

Matthias

[Nico Mueller]

You can install UIMAPI on any server you want ...we e.g. built a complete seperate API Server. You just have to place a reverse proxy in front of your UMP/OC address and sent everything with path /uimapi to this api server.
Works as a charme and support was also fine with it.

[Andrew Cooper]

@Nico Mueller This is a good solution for separating the installation, BUT OC is not recommended to (or cannot) be installed on a hub server but uimapi does not work properly/completely if it is not installed on a hub (ie some of the rest calls fail if it is nut running with a local hub).  So what we have now is a situation where either we install OC in an "unsupported" config and get full |uimapi functionality or install OC "correctly" and get reduced uimapi functionality.

Neither situation is desirable, when previously we had a choice where both products worked.  Another example of the product breaking because of an architecture/design change, is it bad design or poor testing, or both?

Regards, Andrew
​

------------------------------
Knows a little about UIM/DXim, AE, Automic
------------------------------

[Matthias Gruber]

Nice workaround, but no solution in my point of view.
Sure putting a F5-Cluster in front of it to do my reverse proxy-Stuff should be solid. I 'll dont mention the network-design I have to honor in that case, but the whole charme of a small, minimalistic running monitoring-software is further gone with that step
Prior to  20.4 the Mainhub was enough to push alarms into the system and do automatic actions out of it...
But thanks for the hint, nice Idea

cheers
Matthias

[Luc Christiaens]

I use as a temporary workaround uimapi 20.31 on the main hub (sorry that I was not clear on this in the beginning)
I will also opening a case for uimapi 20.42 on OC
​

[Nijin K]

I had same issue with API not working on primary hub after 20.42 upgrade as all our scripts are pointing towards primary hub so opened a case the solution i got was a KB saying that this won't work in 20.42 so had to go back to backed up wasp 20.1 folder it is working now
Now API is working on both primary hub and OC

[Nijin K]

Correcting and elaborating my earlier statement
My API page pointing towards primary hub was working after we upgraded from 20.1 to 20.4 then we applied 20.42 patches on OC,CABI and primary hub the api calls started give error about missing packages so when checked API link started working on OC.
So as a test i went back to 20.40 instead of 20.1 wasp which i had backed up only in primary hub not OC or CABI so both are working now 
Hope this clears out any confusion my earlier statement could have caused

[Nico Mueller]

I can confirm that 20.42 uimapi is killing our reverse proxy separated /uimapi server setup aswell.

Need to downgrad to 20.41 to get it functional again.

What happened with 20.42 uimapi that its causing that problems?

[Olaf Pape]

Hi,

I started a new test today with the CU3 version, hoping that something has changed.

On the main hub I deinstalled all webapps and delete the wasp folder on the server.
Then I deployed the wasp first and then these webapps.

• uimhome
• mps
• adminconsoleapp
• uimapi 

UIM home redirect works, Admin Console work, uimapi unfortunately not. The same situation as before.

But I had already found a workaround on my previous installation (20.4.2). I deploy the webapp "" and - Surprise - the uimapi now works as usual.

My explanation: Deploying the ump webapp installs the missing authentication class.

Maybe this helps one or the other

@Matthias Gruber @Luc Christiaens @Nijin K @Nico Mueller



​​​​​

[Andrew Cooper]

@Olaf Pape It seems that the situation is the same with CU4, some things are fixed and uimapi updated but the issues described here are still present.
1.  The deploy "ump" trick still is the only workaround for the authorization errors on on the Primary hub
2. OC still cannot communicate to hubs which are connected by tunnels
​​

------------------------------
Knows a little about UIM/DXim, AE, Automic
------------------------------

[Andrew Cooper]

CU6 (ie 20.4.6) has an updated uimapi (v20.46) package but it is still dependent on OC authentication libraries and hence is still dependent on ump package being on the server where it is deployed too.

Cheers, Andrew

------------------------------
Knows a little about UIM/DXim, AE, Automic
------------------------------