Event frameworks are popular in the industry for many use cases, particularly when an action occurring in the source system should trigger a real time response to an external system that wants to passively wait to be told that an action can take place. To this end, in the ERP world, Oracle had provided the business events framework in Oracle EBS, and now also in Cloud ERP there's a similar, although quite different alternative.
The event framework in Oracle EBS allowed you to create custom business events that could be invoked by a stored procedure, or trigger after a custom concurrent program executed, etc. and you had complete control around what the logic in the event was, and so much more.
However, in my experience, business events in ERP are nowhere near as useful as they were in Oracle EBS, yet, as they are not very flexible and you cannot customize them in any way. I personally haven't found a use case where with enough scale the events worked as I wanted them to exactly, but the framework continues to grow and evolve, so it will eventually become more viable. For example, I had several use cases around AP payment acks and acks in AR for various reasons, as well as projects when the workflow changes the status of a project, etc., but the events didn't include all the fields the downstream systems wanted to be in the payload (and you can't just add fields, you would have to make a lookahead call after catching the event to an API and merge the additional data into the payload, assuming the API's had those fields), and also if you want source specific data, sometimes you couldnt filter the payload enough with the event wizard in OIC, and you have to parse through a lot of data to get it to what the downstream system wants and not other systems data. We did successfully use events to build an email ack framework to let downstream systems know about the status of their FBDI files, once uploaded to ERP.
The other challenge is that you can only utilize Oracle Integration Cloud (OIC) to subscribe to business events from FA, so if you use another middleware solution like Biztalk or MuleSoft, etc. you won't be able to subscribe to the events framework without using OIC. This does force clients that have invested in Enterprise tools that would otherwise not want to utilize OIC, to jump on it. However, OIC is pretty inexpensive when compared to other competitors, and if you just want to use it for events, you can have OIC catch your event and pass the payload to your middleware of choice and do what you want there, it's not ideal but it's an option, and it doesn't require complex knowledge of OIC. Also, even if event listening was exposed to other consumers, OIC has a competitive advantage because the wizard to configure an integration that listens to an event, and the options it provides, would still be superior than just listening to a raw event.
If using OIC is completely out of the question, then consider building a message aggregation service with your middleware of choice that calls the REST or SOAP API's in FA in some near real time fashion, which are likely to have far more fields in their payloads than the events themselves anyway, allowing for more flexibility. You can have the middleware send the payloads to a topic using Oracle OCI streaming or your own implementation of Kafka, and then have whoever wants the information consume the topic.
No comments:
Post a Comment