Hi all,

We had a detailed discussion on the architecture and the design of the new
'Recipe' concepts for ESB. This is a summary of what we have discussed.

*Recipe* : The concept behind Recipe is about providing high level
abstraction for  connectors interactions.  The well known and commonly used
integration scenarios between any publicly available services/cloud apis
such as Salesforce->Google Spreadsheet will  be provide as recipes.

The deliverable of a Recipe is a Recipe archive (residing in a Recipe
store) which comprises of some descriptor files and available recipes as
templates.

For instance, the recipe for integrating Salesforce->Google Spread Sheet
will have the following structure. There can be multiple operations
associated with that recipe such as syncContacts, syncLeads etc.

Recipe Archive (SalesforceToGoogleSpreadSheet.zip)

- recipe.xml (contains recipe name, available operations etc)

- components

 - component.xml

- syncContacts.xml [Templates]

- syncLeads.xml  [Templates]

...

- repository

- salesforce-connector-1.0.0.zip

- googlespreadsheet-connector-1.0.0.zip

- icon

eg: *syncContacts.xml* will have the following structure. All the required
parameters are externalized so that the Recipe invocation can pass them
dynamically.


<salesforce.init>

<username>{sfdc:username}</username>

<password>{sfdc:password}</password>

</salesforce.init>

<salesforce.query>...

<datamapper/> | <xslt/> | <payloadfactory/>...

<googlespreadsheet.init>

<oauth2Credentials>{googlespreadsheet:oauth_key}</oauth2Credentials>

</googlespreadsheet.init>

<googlespreadsheet.importCSV>

<spreadsheetName>{googlespreadsheet:spreadsheetName}</spreadsheetName>

<worksheetName>{googlespreadsheet:worksheetName}</worksheetName>

</googlespreadsheet.importCSV>



Recipe Executor

A given Recipe can be executed with the use of a recipe executor(might need
better naming). This is a deployable archive which is similar to a
sequence, proxy service or rest api. The recipe executor can be triggered
from an external agent such as Task Server. (When we deploy a Recipe
executor, it will create a task in the task server.

Recipe executor is the artifact where a given user will get directly
interact  with. For instance when a user wants to periodically sync his
Salesforce contacts with a Google Spread Sheet, he should be able to create
the following recipe executor from the developer studio and deploy that in
to ESB.

<recipe name="SalesforceToGoogleSpreadSheet" operation="syncContacts">

   <interval>10</interval> | <cron>0 0 12 * * ?</cron>

   <sfdc:username>user123</sfdc:username>

   <sfdc:password>vault-lookup('kasun_sfdc')</sfdc:password>

   <googlespreadsheet:oauth_key>DF9d99dFD</googlespreadsheet:oauth_key>

   <googlespreadsheet:spreadsheetName>SFDC</googlespreadsheet:spreadsheetName>

   
<googlespreadsheet:worksheetName>My_Contacts</googlespreadsheet:worksheetName>

</recipe>

As we did with the connectors, we will concentrate on end to end story for
recipes (ie: implementation, deployment, storing and tooling aspects).

We are planning to do a poc around the above mentioned design and then we
can do a review.

Please correct me if I miss any thing related to this topic and please
share your thoughts on this too.

-- 
Kasun Indrasiri
Software Architect
WSO2, Inc.; http://wso2.com
lean.enterprise.middleware

cell: +94 77 556 5206
Blog : http://kasunpanorama.blogspot.com/
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to