AFAIU, these are main steps of the recipe use case : - Recipes will be stored in a recipe store. - User can download and install the required recipes in to Dev Studio ( same as connectors) - Once a user import a recipe in to DevS, he can start creating recipe executors/triggers. We can populate a graphical representation (with icons and all) in the developer studio. - Then the recipe executor can be deployed in to an ESB (as a .car).
On Tue, Mar 4, 2014 at 10:58 AM, Afkham Azeez <az...@wso2.com> wrote: > What would user experience be like? Surely, users will not be editing XML > files, I presume. > > Azeez > > > On Tue, Mar 4, 2014 at 10:55 AM, Kasun Indrasiri <ka...@wso2.com> wrote: > >> 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/ >> > > > > -- > *Afkham Azeez* > Director of Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > * <http://www.apache.org/>* > *email: **az...@wso2.com* <az...@wso2.com> > * cell: +94 77 3320919 <%2B94%2077%203320919> blog: * > *http://blog.afkham.org* <http://blog.afkham.org> > *twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> > * linked-in: **http://lk.linkedin.com/in/afkhamazeez > <http://lk.linkedin.com/in/afkhamazeez>* > > *Lean . Enterprise . Middleware* > -- 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