Integrating Applications
The gadget spec URL could not be found
OrangeScape inherently supports REST style service interface. Both the user interface (AJAX) and other integrating applications use this service interface to communicate with the business tier. Based on your use case, you can choose one of the following approaches for integration:
  • Point-to-Point Integration: This is typically used for integrating 2 modules that belong to a single application. Such modules could have been developed as independent applications initially for modularization or manageability purposes. Later when you want these applications to work together as a single application, you can use Point-to-Point integration.
  • Incremental data integration: This is typically used in scenarios where one application is responsible for the creation and lifecycle (i.e business process) of a certain set of data and all the other applications use that data as reference/master data. In such cases, the owner application maintains modification time stamp of the data and all the other applications query for only incrementally modified data since its last synchronization and updates them into their datastore. This is typically used in batch update scenario.
  • Middleware-based integration: This is used in scenarios where same data is transactional in nature in 2 different applications and both applications have its own business process to govern that data. Usually such applications are already built and has their own architecture and design. Therefore a middleware is used to transform data from one application to another, to queue data for guaranteed delivery and asynchronous execution of the business method exposed as service.

Point-to-point Integration

Point-to-Point integration makes 2 assumptions on the integrating applications:
  • Service invocations are synchronous and distributed transactions are not supported. So both the applications are expected to be available or unavailable at the same time.
  • Protocol and data representation between the integrating application needs to be similar. Hence there is no need for connector or data transformation.
This means that the typical integration for Point-to-Pont integration is intra-application integration i.e. module to module integration of the same application. In such cases, the integration is triggered by executing REST call using Action design in one model, which invokes a REST service of another model. The data that goes out from the calling model is called Inbound message and the data that comes into the receiving model though REST interface is called the Outbound message.

Inbound messages

As explained earlier, OrangeScape uses the same REST service interface for integration as well as user interface. The 2 services that are relevant for integration are:
  • Activity service: Activity service lists all the items that are waiting for the logged in user for that particular activity. You can invoke this to get this list or create an instance, in case of start activity. The REST end point for activity looks like this:
    http://<application>.appspot.com/<primary or secondary>/<model key>/<activity key>
    • Example: http://os-demo.appspot.com/1/Application_c548d211/SheetMetadata_0163dc56/ActivityDefinition_76185608
         The 2 method relevant for this REST service are:
    • GET method - to list all the items waiting for that user in that activity. The data representation can be of html or json. For integration, you would typically use JSON. To get data as JSON, you should use mimetype=text/json
      • Example: http://os-demo.appspot.com/1/Application_c548d211/SheetMetadata_0163dc56/ActivityDefinition_76185608?mimetype=text/json
    • POST method - to create a new instance, is the activity is a start activity.
  • Model service: Model service provides the endpoint of a specific instance in a given activity context. The REST end point for Model/Instance looks like this:
    http://<application>.appspot.com/<primary or secondary>/<model key>/<activity key>/<instance key>
    • Example: http://os-demo.appspot.com/1/Application_c548d211/SheetMetadata_0163dc56/ActivityDefinition_76185608/Invoice_93193?mimetype=text/json
          The methods relevant for this REST service are:
      • GET method - to get the content of the instance and its children based on form design
      • POST method - to create child of the instance
      • PUT method - to update parameter values in the format: <parameter1>=<value1>&<parameter2>=<value2>&
      • DELETE method - to delete the child or the instance itself
      • POST method with invoke=<action> - to invoke the action designed for that model using action design

Outbound messages

Outbound messages are REST call from action design that invokes either the Inbound Activity service or Model service. pls refer to action design for more information.


Incremental Data Integration

Incremental data integration assumes that there is a owner application and multiple subscribing application. The data in the owner application is transactional in nature. The same data is used as mater data in all the subscribing application. This means that the data change can be done by the owner application only. This application will maintain an update time stamp as one of its columns. This application should allow the subscribing application to specify a time stamp and query the data that has been modified after the specified time.

The subscribing applications should find the max timestamp of the update time stamp and use that timestamp to query the incremental data as explained above. The incremental data can be of inserts or updates. So all the applications should maintain a common natural key. This key is generated by the owner application and the other applications maintain that key in their application as well. Depending on whether the natural key exists or not, the application can do inserts or updates.

This synchronization is typically done at the database level. The database scripts can be scheduled to run a batch jobs.


Middleware based Integration

When using a middleware based approach it is important to understand common concepts below:
  • Integration Process - This is a process flow that orchestrates a meaningful integration process involving one or more connectors to hetrogenous systems.
  • Connectors - This a piece of software that participates in a integration process and knows how to interact with a host system
  • Neutral Message Format - A common message format(s) supported by the integration process.
This above description is not expected to be a complete and comprehensive. This has been provided only as a overview. For detailed information of the above, developers are requested to read related middleware documentation as appropriate to their project. Also is very important to understand that middleware based integration approach is used for business processes that cross hetrogenous system boundaries. It should not be used for data sychronization activities like 'Master Data Sync' etc.

OrangeScape will support the following to participate in a integration process.
  • Inbound Connector
  • Outbound Invocation Capability

Inbound Connector

This is a connector supplied by OrangeScape to participate in the integration process. The inbound connector has capability to accept 'inbound' message into OrangeScape. It performs two key functions:
  • Transform data sent in neutral format (typically XML) to the format expected by OrangeScape (JSON)
  • Transporting the message to OrangeScape by invoking a REST service end point. The REST service end point and related parameters for the invoking will be provided by the integraion process developer as configuration to the inbound connector

Outbound Invocation Capability

Whenever OrangeScape needs to send a message to the integration process, it will be implemented via action design. The action design has capability to use various action commands to transform the OrangeScape message format (JSON) to the neutral message format supported by the integration middleware. There will be configuration parameters that specify the end point of the integration server and the required parameters that need to passed while doing the Outbound message invocation. Click here to read about "WebService" action.