2014/01/16
16 Jan, 2014

Cloud integration with the use of WSO2 ESB Connector framework

  • Dushan Abeyruwan
  • Direcror - WSO2

Applies to

WSO2 ESB 4.8.0
WSO2 Developer Studio 3.5.0

Table of contents

 

What is a connector?

A connector refers to a way to connect to an API that is provided by a third party, e.g. we can write a cloud connector to connect to Twitter, Salesforce or Google Spreadsheet APIs from WSO2 Enterprise Service Bus (ESB).

In a previous article titled WSO2 ESB 4.8.0: Introducing Cloud Connector Samisa Abeysinghe briefly explained the features and why connectors plays a major part in cloud API integration.

In this article, we focus more on the technical aspects; it will provide a guide with different use cases that include code snippets, and will explain how exactly we can write a real cloud integration by connecting different connector APIs using the newly implemented WSO2 ESB Connector framework.

Usecase 1: Salesforce Account Lead Creation (Salesforce + Twillio)

Scenario 1 basically describes how Salesforce and Twilio connectors can be used for a simple scenario as depicted in [image-1] for account leads creation; it shows how you can create possible leads in Salesforce and thereafter send an email to the leads that was created to their respective mobile devices. Nevertheless, in terms of tooling, this can easily be carried out with WSO2 Developer studio 3.5.0 onwards. Refer to the following Synapse configuration for the scenario.

[image -1]

As explained earlier, this article mainly focuses on the technical aspects; the easiest the way to model a process is to use Developer Studio, which has a very good tooling capability that's in built, but in general, once you create the respective logic via Developer Studio, the source view can be seen as shown in [source -1].


	
		
			
			
			
				
					
						
							$4
							$3
							$1
							$2
						
					
				
				
					
					
					
					
				
			
			
				0
				0
				{//sfdc:sObjects}
			
			
			
				{$ctx:smsContent}
				{get-property('phone')}
				12245854573
			
			
		
		
		
	

[source -1]

Setup Usecase 1

  • To start, we need go through different steps in order to model the process defined in [image -1]; therefore, first right click on the ESB Project then select “Import Cloud Connector” from the context menu; download connectors from here.

    [image -2]

  • Once you import the connector, you will find a list of operations that Salesforce supports, and before we call any operation, we need to prepare the payload to insert data into the Salesforce Accounts table; you can refer to API definitions at WSO2 ESB Connector Reference for more information.
  • Working with sObjects

    A sObject refers to any object that can be stored in the Force.com platform database. sObjects include all the standard and custom objects in your organization. With the Salesforce connector operations, you can define a sObject structure in the message payload, which you can send directly from the caller or generate using the PayloadFactory mediator. Examples of the Salesforce connector use the PayloadFactory mediator approach, e.g.


	
		
			
				$1
				$2
				WSO2-TwitterFeed
				$3
			
		
	
	
		
		
		
	

         

[source-2]

  • Once you create the respective payload (a Salesforce object), you then need to invoke the respective API. For this, navigate Salesforce connector operations and then select operation. Thereafter, drag and drop to the working palette. If you haven't configured [see image 3] any Salesforce specific generic initialization configuration, there will be a prompt as shown in [image-4]; here you would be required to provide credentials such as email address, password, and the respective URL supported by Salesforce to access its APIs (Note: providing passwords can be further enhanced by adding secure Vault, which will be discussed in a separate article).

    [source-3 will be automatically generated if you click new configuration under local entry]

          
    	
    		[email protected]
    		xxxx
    		https://login.salesforce.com/services/Soap/u/29.0
    		
    	
         
        

    [source -3]

    Above [source-3] will be automatically generated once you do the configuration as shown in [image-4]

    [image -4]

    Refer to [image-5], which shows the location of the global configurations generated.

    [image -5]

  • Next step - you would need to call the operation; if you refer to the [Account] table under Salesforce, it has the email address, name of the lead, and the description, and the below code segment [source -4] is a sample of how you can call the respective operation to insert the payload created at [source-3]
    
    	0
    	0
    	{//sfdc:sObjects}
    
     

    [source -4]

  • If the Account creation is successful, we would need to send an email; for this, we need to import the Twilio connector in the exact same way as Salesfore connector, and then it will show up respective operations. Thereafter, you should invoke where it asks to provide twilio API credentials, and it will create the respective Twilio credentials under localEntry as a generic configuration to refer to. Based on your requirements, you can use the shared configuration, or else you can define your own configuration just before invoking the respective operation as was discussed earlier.
    
    	{$ctx:smsContent}
    	{get-property('phone')}
    	12245854573
    
    

    [source -5]

  •  

    The following image shows a sample model view captured from DevStudio

    [image -4]

     

    Usecase 2: Account service management (Salesforce+JIRA+Twilio)

    [image -5]

    As shown in [image-5], this scenario demonstrate how organizations can manage its customer account services. We know that many organizations ideally keep their customer base in Salesforce CRM, and each customer account is mapped to a relevant JIRA account to discuss their internal matters (especially product-based organizations follow this form of communication). The above diagram shows how simply an organization can manage the account iterates in a pre-determined manner and automatically generate a JIRA issue and send an email to the respective customers if their accounts have not been upgraded (yearly/monthly, etc.), in accordance with the SLA agreements. Refer to the configuration and sample snapshot view shown in [source-5] and [image-6], respectively; the emphasis here is that different APIs (such as Salesforce, Jira, Twilio) can be combined in a simple way with zero coding, thereby enabling rapid developments.

    
    
    	
    		
    			
    				200
    				select Id, Name, SLAExpirationDate__c,
    					Account_Manager__c,Phone from Account WHERE Parent.Name =
    					'Production_Support' AND Active__c = 'Yes'
    			
    			
    				
    					
    						
    						
    						
    							
    								
    								
    								
    								
    								
    									
    								
    								
    									{ "fields": { "description":
    										"Thanks for using our Production Support.$2 or
    										[email protected].", "issuetype": { "name":
    										"Announcement" }, "project": {
    										"key": "$1" }, "summary":
    										"Notice of Closure " }}
    									
    										
    										
    									
    								
    								
    									
    										{ "categorisedActors": {
    											"atlassian-group-role-actor":["jira-administrators"]
    											}}
    										
    									
    									
    										{$ctx:ACCOUNT_NAME}
    										10000
    									
    									
    										
    											
    												
    													No
    													$1
    												
    											
    										
    										
    											
    										
    									
    									
    									
    									
    										0
    										0
    										Id
    										{//sfdc:sObjects}
    									
    									                                      
    										{get-property('phone')}
    										12245854573
    									
    									
    								
    							
    						
    					
    				
    			
    		
    		
    		
    	
    
    
    

    [source -1]

    Setup Usecase 2

    • Ideally, modeling the process via developer studio is pretty much similar as explained in [scenario 1], where the difference is that it would be required to model the process the way it has been described in the synapse configuration (which explains the logic); [image 4] shows a sample configuration view from Developer Studio 3.5.

    • [image -4]

       

      Running scenarios

      Once the configuration is completed and before uploading the Composite application, you need to upload the respective connectors to the ESB instance; to do this, refer to [image-6]. Once connectors are successfully uploaded, it's required to “enable” the connector in order to activate.

      Summary

      The underlining factor with regard to the WSO2 ESB framework is that different APIs (such as Salesforce, Jira, Twilio) can be combined in a simple way with zero coding, thereby enabling rapid developments. This would instantly meet an organization’s business requirements of having to align with rapidly changing enterprise IT needs. We illustrated this with two basic scenarios and explained how to model such cases with a few clicks by using Tooling aspects. Moreover, in a developer’s perspective, if someone is interested to know how this works, we have also provided some examples of a few codes it actually generates.

     

    About Author

    • Dushan Abeyruwan
    • Direcror
    • WSO2 Inc