1) Call out a couple issues I've run into with the use of custom events in the hopes that it spares someone else a mind-numbing experience of debugging.
2) Solicit some feedback from Adobe and/or any other very knowledgeable individuals
First, allow me state that I'm using LiveCycle ES2.5 on a turnkey JBoss installation backed by MySql.
Now on to the issues. They are as follows:
1) Deployment of an application that makes use of start points that listen for custom events takes an obscene amount of time - so much so that I had to increase the transaction timeout from 5 minutes to 10 minutes because my application was failing to deploy right around the 5 minute mark with a nice Arjuna "the transaction is not active!" error.
2) Custom events are available for use as start points prior to the given event being deployed into the runtime. This is in contrast to processes where they must be deployed into the runtime before Workbench can "find" them for use as subprocesses in your orchestrations. However, if you add an event start point that listens for a custom event that has not yet been deployed to the runtime, your deployment will probably fail (after you just waited 5-10 minutes for it to take place).
My workaround for issue 1) isn't much of a workaround but rather more of a deference tactic. I wait until I'm as far along as I can possibly get before needing to test out all my changes prior to adding in any start points for custom events. Deploying my application without custom event start points takes about 1 -2 minutes. Deploying my application WITH custom event start points takes upwards of 8 minutes.
My workaround for issue 2) is simple in that I always ensure I've deployed my application with any custom events I've created prior to adding any custom event start points. There is a situation here, however, that is hard to avoid. Take the following flow as an example of this:
Step 1: Create a custom event
Step 2: Check in changes
Step 3: Deploy your application
Step 4: Add an event start point for the custom event created in Step 1
Step 5: Check in changes
Step 6: Deploy your application
Step 7: Attempt to delete an asset (such as a form or process) that is deployed to the runtime
Step 8: Check in changes
You will fail at Step 8 as Workbench will complain that you are attempting to delete an asset that is deployed to the runtime. It will instruct you to undeploy your application first to get the given asset out of the runtime and then to check in your changes. There's just one problem with this: when you undeploy your application you may now experience issue 2) above because when you go to deploy the application again, the custom event may not be deployed to the runtime prior to the start point that is listening for it being deployed to the runtime.
While it is certainly possible this could be unique to my environment or the LCES installatiopn I'm using, I'm inclined to think that's not the case. Is there anyone with deep knowledge of custom events that could shed some light on all this? The application I'm working on is going to end up having 21 custom events each with an associated start point that listens for its associated event type.