Verify/Find list of Plug-ins deployed in Appian Using Java API

I looked into this a year ago and didn't have any luck.

I also tried to perform some simple screen scraping ideas after trying to dynamically pull the /admin page, thinking that maybe I could use Appian to request the admin plugins page, grab the html from the response and then scrape it for the list of plugins. I didn't spend long on it, but that didn't work either, partly because the plugin page wasn't a simple URL but instead had a rather complex set of responses that would have made it hard to parse the multiple chunks of data. You might have better luck if you can find a prebuilt screen scraping tool that can pull a whole web page including its underlying CSS, javascript, etc. and then parse it and make it available to Appian via a webservice or a dumped flat file.

Alternatively, I tried looking through the log files and didn't find an obvious list. Sure, newly added plugins are in a log, but existing ones at startup are not logged. I think they might be logged however if you run the Appian supplied health monitoring process (for on site installations), so you could try triggering that and see if one of the files generated that you would send to Appian might contain a list of jar files.

Can you explain the business case in more detail? Specifically, why does this need to be a plugin? Why can't an admin just review the Admin console to verify status?

Alternatively, can you just use Health Check output? One of the files it generates is the plugins associated with a system.

There is an API for this, but I don't know what it is offhand, and I'm also not sure if its private API. I would suggest using one of the tools already available if possible.

Over time I have built a set of process models that we run daily to attempt to determine the system health. It checks for external and internal process to process JMS send/receive, reading from mailboxes, connecting to all of our databases (queries are run), rules/expressions run successfully, the number of active employees in a db table is roughly what is expected, etc.

At one time we were having occasional issues with some of our plugins not loading consistently after a server restart.
I tried building a process that runs a function or smart service from a number of our plugins (including a few internally built ones) to make sure they functioned and returned the expected results. This was tedious because I didn't know how to call all of our 40+ prod plugins with legit calls (that might require matching data in separate systems, etc.). I was hoping that if I could programatically query the Appian system to tell me what plugins were loaded (which the /admin interface essentially does) then I could create a constant or expression to store what plugins (and versions) we expected and what the system returned. Oh, the health check only found 45 plugins as being loaded post reboot/patch, and the script says you should have 46...here is the one not found, send an email to the admins and developers.

Sure, the plugins page on the /admin page shows a count of the # of plugins loaded and their names/versions, but there isn't an easy way to compare the list to a known set, especially between multiple environments. After most every jboss or Appian restart, patch, OS level patch, etc. we have to validate our applications are running and we can connect to other systems. A scheduled daily health check that we can manually trigger to run while not perfect gives a quick success/fail indicator and some debugging info (which of our 11 subprocesses failed and sometimes specific clues in those processes to what didn't work).

I see. I don't know your specific circumstances, but I've generally only had issues with plugin loading when there were infrastructure level issues (i.e. file mount had issues). I would push for monitoring at a more fundamental level (e.g. is my NAS stable?), though your risk tolerance and experiences may not align with that.

Testing expressions from plugins can be handled easily, since you generally readily write test cases for them in Appian and they shouldn't have side effects, so they should be safe to run across environments. There is some good documentation on automating this here: docs.appian.com/.../Automated_Testing_for_Expression_Rules.html. If anything fails, it would be easy enough to notify your distro of the status of all test cases.

Of course, smart services are a different ball game, as you noted. I don't have many ideas on this one. One low-tech thing we've done at many engagements is track plugin deployment is maintain a spreadsheet per environment of what is supposed to be loaded. This could be included as a checklist in any documentation/admin guides that cover validation steps.

One last idea - perhaps you could consider integrating in something like Selenium to use a browser to hit the Admin console and verify the plugins listed against another known list? Appian's FitNesse may work for this, but I'm not sure.

At the time I didn't know why a few plugins were not loading. I think there was something wrong with our configuration and one of the scripts wasn't giving enough time for the plugins to load prior to moving on. We also had some network storage issues that caused transient performance problems. The issue did go away once we found the config timing and lengthened it slightly. Our server admins do have some additional tools including Tivoli, but those generally only track that Appian is up/responsive and that we aren't overloading our cpu/memory/drive space (and not something the developers can trigger to check that all looks sane)

I have a few smart services and expressions tested, but no where near all of our plugins got built out. My peers weren't as enthusiastic in having a system health check that was comprehensive :-) I do have a spreadsheet (slightly dated now) that has all of the plugins for each of our 4-5 environments listed including the version number and some highlighting and notes for where the versions aren't consistent between environments and/or released. I do think you have a point that Selenium or FitNesse might work. We are starting to look into FitNesse for some of our QA/business analyst work. Sadly, we are perpetually a few versions behind what Appian has released (17.1 now when 18.1 was just announced), and we have a number of older Portal apps that we haven't migrated yet too, so the adoption of good tests is behind.

Hi Justin,

We are developing an app which will do deployment of plugins as Plug-ins are part of hot deployment so how do we verify that deployed plug-in got successfully deployed for appian or does it cause some issues while deployment.

We can get the list of plugins got placed for Appian but is there any way to verify that out of all which are successfully deployed or just residing as dead.

hope it should have given you fair idea.

Any new answers on this topic?

Not sure if this helps the discussions or not, but the plug in name, functionality and module type (Smart Service, Function etc) are listed in a healthcheck file on the root directory of the system - hc-plugins.csv.

A further file, hc-process-nodes.csv will then list all the types of nodes in all process models the healthcheck has analysed.

The plug in key and module key combined from the hc-plugins.csv file should match the activity class local id on the hc-process-nodes.csv - that will then tell you which process model UUID is using which smart service.

Not sure if this helps anyone or not.