Sorry for the belated question, but did you find solution to your issue?

I do not execute long running task as a web application.

My “solution” to any long running task (anything that doesn’t respond in 2-3 sec max) is to “queue” the task to a SDK based code that processes the job.  I tried Active MQ first, but got shot down by local enterprise architects who wanted me to use IBM WebSphere MQ.   My quick and dirty solution was to use a temp file/folder as the “queue” and have a cronjob that checked if any job(s) were already processing or not,  and if not-processed request found, process it.

For parallel “processing”, I am using different credentials to log into A9. Most of the time, this seems to work, but sometimes, it fails without any valid error log. I think it may be the same issue when two A9 users are trying to update same object at the same time.

I don’t know your integration architecture but I am assuming that user action in A9 triggers some code (event based PX ?) which calls REST/SOAP endpoint to send data to external service end point.

If you wish to allow A9 users “check” with one liner showing up in the  Web UI, one suggestion is to create action based PX to trigger another service call into the external end point “asking” “hey do you have this valid data?”  If you need to display more than a one liner, then write a URL_PX ( basically an external web application) to do the same and display more meaningful data.

I am sorry, I don’t know your level of experience with integration methodology, but the suggested best practice is to at least have one “hub/wrapper” layer that manages the two way verification for you with the external system.

High level example only: 
1)A9 has a custom “status” field dedicated to showing integration status.
2) User action or something triggers A9 data to be shared with external system, while the status field get updated
3) The “external system” in our case will be a hub/wrapper that handles the actual interaction with the external system, such that A9 will only have to “talk” to the hub/wrapper
4) the hub does the conversion necessary to interact with the external system, handle request/response and send update back to A9.  Depending on the implementation, the hub may call a custom end point in A9 or just update the data field in A9
5) user can later come and check the status.

One item I forgot to mention… Since we installed RUP 8 (9 will be installed when released), some of the dependency jar files that used to get read correctly now could NOT be found by the PX threw cryptic one liner exception with the “path” to the class name.   I had to save these problematic jar files in to the xxx/agileDomain/lib folder to make sure the jar libraries get found by the PXs

My personal preference only, but it’s A LOT EASIER to develop a RESTful service that sit OUTSIDE of A9 environment and interact with A9 using Java SDK.
High level example only:
1) Create a dummy RESTful API with security and deploy to tomcat and verify that it returns expected dummy content
2) Write a SDK based class that pulls the necessary information (or pushes information) from./into A9 and verify that it works
3) Connect #1 and #2 together and expose that as your REST API ( I hope you are ONLY exposing this within your company firewall)
4) To increase security level, enable HTTPS protocol only.

Have you tried using IE ?  For whatever reason our old 934 instance ONLY allow upload if ran from IE.  File download via “GET” worked using other browsers, but upload ONLY worked with IE.

First, the META-INF/service should be named as IEventAction for event based PXes

Second, try removing cache located at your java tmp folder/*sdk*/

If still doesn’t show up in the drop down, recycle the app servers.

If still doesn’t show up, make sure your dependencies are all available

If all fail, comment out all of your logic and just return a valid  IEventAction string value like “I am running” to check your PX is in a valid format.

Best practice is to move as much of your logic into a separate Java class that you can “test” as a normal SDK code, not having to deploy to extensions folder.  The “main” class with doAction() should only be responsible for instantiating your logic class , execute logic , and then return status back.  That way, it’s pretty easy to verify that 1) your dummy main class with doAction() actually runs with valid expected status message coming back  2) easy to test outside of A9.

in AgilePLM 9.3.6 RUP 9, there is supposed to be Federated SSO feature. File SR with Oracle to learn more.  In RUP 8, we piloted Federated SSO, but not 100% working.

Two ways:

1) deploy to A9 WebLogic instance (but to Admin server only) => not recommended if you are trying to make HTTPS connections to outside of A9 env
2) deploy to a new TomCat instance running on a box different from Agile PLM server.

Pre-req is that you have prepared the URL_PX ( using Eclipse ) with all the required content packaged into the war file.

If you can log into WebLogic console, and know how to deploy war file => easy. If not have done before, find someone to show you
Tomcat => learn how to enable you ( the admin) to view web browser based admin console to deploy (easier than WebLogic)

In fact, when you are developing the URL_PX, if you are using Eclipse, you should be “unit testing” on Tomcat anyway.
How to start simple:

1) write up a simple jsp to display all the GET parameters and cookies
2) configure new URL_PX to point to your development box ( i.e. http://mhbox.some.com/mypx/show ) to display EVERY GET parameters and cookies
3) use the GET parameters and cookie values to: log back into A9 to conduct what the logic should do (caveat, if you can get https to work, you can use the one-time-use only j_usename and j_password to log back into A9 )
4) when all work => package as WAR file and deploy !

move all your logic code into a separate java class. The class containing doAction() should do minimum possible. 
For example, the logic class would execute something given the “IDataObjet” and other parameters

To test from your desktop:
write a “launcher” class that connects to A9 and and instantiates the logic class with the necessary parameters.

If this is too difficult, use the jar file as is, but add a lot of print statements in your code. If you are capturing stdout to a file when you launch A9, then you can “see” the print statements.

A better approach is to create your own logger ( i.e insert new “logger” into existing log4j framework for Agile PLM ), but that may take some time to make it work in the PX environment.

Instead of writing Java app to be launched via PX, why not write a Web app (URL_PX) ?

Even if you created valid JNLP file to be launched (i.e. PX sends this jnlp file back), the user’s desktop may NOT have the pre-requiste Java environment to properly launch the Java code.  In fact, I’ve seen old laptops still running java 1.7 when all the PXs being written are using 1.8. => result failed launching of Java app.

The security setup on the user’s computer may be a different story.