...
- In both instances, the PostProcess Plugin Processor sends each PostProcess Plugin the request for processing similar to how the CreateOperations and UpdateOperations processing is currently done.
- Once the processing is complete, the updated Metacard will be passed back to the PostProcess Service updateMetacard() method. This method will then forward the metacard to update over to the OSGI event queue for internal updates. In the case of JMS the response is posted to a JMS update queue that has a JMS listener on the instance running the catalog framework. The Catalog Framework is a subscriber to the OSGI event queue and process the updates without running PostXXXPlugins to avoid data looping.
- Store Updated Metacard - To support user updates that can occur during long-running PostProcess plugins where the metacard has changed since it was handed off to the PostProcess plugins, partial updates of plugin changed data need to be supported. This processing will involve saving an initial metacard and comparing with the resulting metacard to determine the differences generated by the PostProcess plugins. Once the differences are determined, the latest version of the metacard will be fetched and the differences applied before submission back to the Catalog Framework as a metacard update.
Parallel processing of simultaneous conflicting updates
...