Hello, since there is very little documentation on this probe I'm under the impression that this probe does the following:
Probe Provisioning Manager (PPM) is something that doesn’t have an interface nor is it configurable except for the log level or log size, memory used by it. PPM is a ‘wrapper’, a mid-way communication gateway that encapsulates the Admin Console request and passes these requests to the probe. It’s a middle man between the AC and the probe. Think of it as an interpreter.
UIM is pushing the move towards Admin Console instead of IM, the PPM probe has to be deployed to the client hubs in order to configure the robots via the AC. Requests from the AC go thru the PPM probe then pass those requests to the probe and the same thing in reverse.
Just want to ask if this is the impresson that everyone else got about this probe?
Yes ppm is required for admin console configuration, no PPM on the robot then you would not be allowed to configure any probes on that robot. Robot will still show in admin console.
Under bugs, there is an important note about a infinite recursion bug if you try to configure ppm via adminconsole.
There has been a lot of back and forth with support trying to get word on the ppm and mpse probe requirements. It's almost entirely undocumented, and when I can get an answer, I don't always believe them.
Word is that you can't run more than one adminconsole, that it's not supported. But the official 8.1 docs recommend deploying it to all of your servers. Apparently support dissagrees with that, and the official word internally is that the ppm/mpse probes were modified to require database access and thusly can't be deployed to remote hubs. This of course seems to be half of the story. Very little is known about it in support because it's not documented and team working on it seem to be locked in a room being flogged for more code, or have some type of social disorder that prevents them from communicating details to their own team which can be then carried to us so their work is actually useful.
This is my best guess based on some picking appart of the probes and looking at older and newer versions.
ppm must be deployed everywhere. it doesn't talk to the database. mpse must be deployed anywhere there is an admin console along with a bunch of other stuff I mentioned somewhere here on the forums. mpse must have access to the database. If a remote admin console is run, it probably needs a vpn back to the core network to hit the db, and will follow the data_engine if your forced to promote a replicated database to being active under a DR scenario.
Now what happens when the database is down isn't something I've tested yet. I suspect they may have made mpse a kind of gateway where it will try to get the data from the database when it can, and delegate retrieving it in real time via remote-ppm when it can't. That's just a guess though based on a graphic for mpse. So far though, my guesses have been more accurate than official word from support, or the documentation that contradicts them and itself when you are lucky enough to find any detail documented at all. In general, the design seems smart but unfinished when I can get details, and I can't imagine them replacing Infrastructure Manager with a admin interface that is a single point of failure with no option for addressing it.
On other ppm annoyance is the massive 1G memory reservation request in the config for the java process. It seems to run fine with less than half of that on edge hubs, so if your upgrade plan didn't include adding another Gig of memory to all of your edge hubs, you can try throttling it down via the -Xmx1024m flag in ppm.cfg:/startup/options. I suspect the dev team pulled that number out of their butt as young persons default since we're all walking around with phones that have twice as much memory these days. It may have also been a decision based on an older version of ppm, or a response to the memory leak caused by the recursion bug.