Background
The Apache Open For Business Project is an open source enterprise automation software project licensed under the Apache License Version 2.0. By open source enterprise automation we mean: Open Source ERP, Open Source CRM, Open Source E-Business / E-Commerce, Open Source SCM, Open Source MRP, Open Source CMMS/EAM, and so on.
Suggested architecture
Integration possibilitites: Initial thoughts
There are two basic scenarios
- via an ESME action that posts messages to a OfBiz API. The easiest way may be to have ESME just send an email to the OFBiz environment.
- A bot that follows the ESME message stream and either 1) makes a remote call to the OfBiz API
The fundamental idea is to use OFBiz Event Condition Action (ECAs) as the basis for the integration.
About ECAs:
ECAs are pretty straight forward: when an Event occurs, if the Condition(s) are met then Action(s) are performed. The Events supported currently are Entity (EECA) events which basically correspond to database record CRUD events, Service (SECA) events which correspond the various stages of a given service's invocation (invoke, validate, commit, return, etc.) and Mail (MECA) events which occur when an email is received.
Conditions are defined against whatever context is will be available when the event occurs, the record fields for an EECA, the in/out parameters for a SECA and the email contents for a MECA (from, to, subject, etc.)
Actions are just OFBiz services to be invoked when the conditions are met.
Sending event notifications
ECAs are the way to go for this and we'd just define services to be used as actions which send the message to ESME. You'd probably create a single generic service that is used to send any message and then use that service within other services for sending specific messages e.g. an ECA would invoke sendPurchaseOrderChangeNotification which would prepare the message contents and call sendEsmeMessage to actually send the message.
Receiving messages
For this we could either create a new type of ECA specifically for ESME messages or perhaps even generalize MECAs to support any type of message so that it stands for Message rather then Mail. ECAs would then be defined and evaluated when an ESME message is received and service actions invoked to handle any processing and responses that need to occur.
The receipt of the message in OFBiz can occur via various means. If OFBiz has a RESTAPI for ECAs, then you can create an ESME action to send messages to OFBiz when certain ESME events occur. Or if there some sort of ECA for dealing with email events, then we can also use an action that sends email. If you want a deeper integration, you could have a bot that uses one of our various APIs to read the message queue and then create OFBiz events.
ECAs are only triggered by internal events, as I described above: an OFBiz service invocation, database operation or email receipt. We don't have a REST API for invoking services, there is basic support via SOAP, JMS or HTTPS (but not what you'd call REST). Services can also be invoked using HTTP(S) POSTs via our standard request handler (typically used for serving regular web pages and ajax calls) but that requires a little additional legwork in that you have to define request-event-response mappings in our XML based web app controllers.
Use Cases
Send users status information from OfBiz
- The idea here would be to use ESME to send users status messages based on events in OfBiz (ala SalesForce "Chatter")
- Initial description for simple use case.
Use ESME to provide Chat+ functionality
- The idea here would be to use ESME to provide chat functionality to OfBiz
- Simple Use Case - OFBiz sends message to ESMEInitial description for simple use case.