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
- 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.
Incremental Data Integration
Point-to-Point integration makes 2 assumptions on the integrating applications:
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.
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
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:
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
- 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
method - to update parameter values in the format:
- 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
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 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.
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
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:
Process - This is a process flow that orchestrates a meaningful
integration process involving one or more connectors to hetrogenous
- 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.
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
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)
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
Outbound Invocation Capability
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