Extra Info: As part of this setup I also uninstalled the default packages that SFDC sample site contains just to keep things simpler. These can be uninstalled from Setup screen under App Setup –> View Installed Packages. They also contain a number of APEX web classes and I removed these as I was trying to get the proper test coverage for my own web services and make these simpler.
SALESFORCE.COM CONFIGURATION
ACCOUNT CREATION AND HOME PAGE CUSTOMIZATION
1. First thing to do is go and sign up for a free force.com account at http://www.salesforce.com/platform/platform-edition/. After signing up, you can customize your account.
2. Since we are going to work with contacts, go ahead and add a Contacts and Account tab to your home page. Click on the + sign next to “Get Started” to take you to the “All Tabs” page.
3. From the “All Tabs” page, select “Customize My Tabs.” This navigates to a screen where you can add contacts and accounts so it appears on the home page tabs.
4. Click on the Accounts tab and select All Accounts.
5. Create a new account by clicking on the New Account button and give the Account a name of ‘Synthesis Consulting Inc.’ We will need this account later on when testing our web services operations.
ADDING CUSTOM FIELDS AND UNINSTALLING PACKAGES
In this next, Contacts will be customized, by adding a Global Id field. Again kudos to Richard for having a blog on this. He does a few more columns; here are similar steps for adding Global Id to the Contact object.
1. From Salesforce.com, go to the Setup section.
Tip: For quite a while I went there through a convoluted manner until I found out that I could just click the arrow next to my user name in the upper right and select ‘Setup.’ From the setup screen you will be able to do a number of activities that are necessary to get the Web Services up and running on SFDC. This includes, adding custom fields, creating a Sandbox environment, creating the APEX API class and related Test methods, deploying those to ‘production,’ and generating a WSDL.
2. Navigate to to App Setup –> Customize –> Contacts –> Fields
3. Scroll to the bottom of the fields page to see Custom Fields and select New.
4. Select ‘Text’ for the Data Type. Click Next.
5. Enter the following information for Global Id and click Next.
Field Label
Global Id
Length
10
Field Name
GlobalId
Required
Checked
Unique
Checked, case insensitive
External ID
Checked
6. For field-level security, click Next.
7. For page layouts, click Save.
CREATE A SANDBOX ENVIRONMENT
Now that a Global Id for Contacts has been added the web services can be created. SFDC does not allow you to create web services directly in the ‘production’ environment. Instead, they are created in a sandbox environment and then promoted into the production environment. These steps will show how to create the sand box environment.
1. On the left side of the screen navigate to Administration Setup –> Data Management –> Sandbox.
2. Click on “New Sandbox.”
3. Enter a name for the Sandbox environment, leave other defaults and click “Start Copy.” At this point SFDC will begin creating a copy of the SFDC environment.
4. Once it is complete, click on the ‘Sandbox’ link again. Click on the login link to be taken to a new login screen. It will have your existing login with a suffix of ‘.
Tip: Opening this login window in a new tab will allow you to stay logged into both environments which will come in handy when you go to create a connection between the environments.
5. Login Into SandBox using your existing password.
CREATE APEX API CLASS AND TEST METHODS
Now that we have a sandbox, we can go create our APEX API Classes. APEX is SalesForce own programming language, but resembles C#. To create web services we can call from BizTalk, a APEX class and methods will be created corresponding to a web service and related operations.
1. Assuming you’re a logged into your Sandbox environment, create a new APEX Class by navigating to App Setup –> Develop –> Apex Classes. Then click New.
2. The brings you to a window where you can type in your new Apex Class. It you are used to an IDE like Visual Studio or Eclipse, this is a far cry from anything like that. SFDC does provide a Force.com IDE that you can download and install from here. This does give you a much richer environment, but if you want to debug your code you have to have it in the cloud. Similar experience to what you might find with BizTalk Orchestrations.
global class BtsWebService
{
webService static Contact GetContact(String globalId)
{
Contact c1 = [ SELECT c.GlobalId__c, c.FirstName, c.LastName,
c.MailingCity, c.MailingPostalCode, c.MailingState
FROM Contact c
WHERE c.GlobalId__c = :globalId LIMIT 1];
return c1;
}
webService static Id InsertContact(String lName, String acctId, String globalId)
{
Contact c = new Contact(lastName = lName, AccountId = acctId,
GlobalId__c = globalId);
insert c;
return c.Id;
}
webService static Contact UpdateContact(String globalId, String lName)
{
Contact c = [SELECT account.name FROM contact
WHERE globalId__c = :globalId limit 1];
c.lastName = lName;
update c;
return c;
}
webService static Id GetAccountId(String accountName)
{
Account a = [SELECT Id FROM Account WHERE Name = :accountName limit 1];
return a.Id;
}
}
This will provide a web service with four very simple methods that we can call.
3. Click Save. This will validate the service and provide you a page to work with the new service, BtsWebService.
4. Click on “Apex Classes” where we will add another class to test our Web Service. Click New and add cut and paste the following code:
@isTest
private class BtsWebServiceTest {
static testMethod void testGetContact()
{
Account a = [Select a.Name, a.Id From Account a WHERE a.Name = 'Synthesis Consulting, Inc' LIMIT 1];
String lName = 'Smith';
String globalId = 'Bts1002';
Id aId = BtsWebService.GetAccountId(a.Name);
Id cId = BtsWebService.InsertContact(lName, aId, globalId);
Contact myContact= BtsWebService.GetContact(globalId);
Contact myContact2 = BtsWebService.UpdateContact(myContact.GlobalId__c, lName + 's');
System.debug('***** id1:' + myContact.Id);
System.debug('***** id2:' + myContact2.Id);
System.debug('***** Name1:' + myContact.LastName);
System.debug('***** Name2:' + myContact2.LastName);
String id1 = myContact.Id;
String id2 = myContact2.Id;
System.assertEquals(id1, id2);
System.assertEquals(lName + 's', myContact2.LastName);
}
}
There are lots of improvements that can be made with this class, but this gets the job done providing a method that exercises all of our classes. SFDC requires that we have certain amount of test coverage over the Apex classes. If you have improvements to this test class, feel free to let me know.
5. Click Save and then click Run to test the web service. It should run successfully. At this point the changes to the Sandbox can be promoted to the production environment.
PUBLISH THE CLASSES TO SFDC PRODUCTION
In order to promote these APEX classes into production the relationship needs to be created between the two environments and then the changes need to be published into the production environment.
1. Go to the production environment, either another browser tab, or if you closed it, log into your production environment again. Keep the Sandbox environment browser window open as we will go back to that shortly.
2. In the production environment go to Setup and navigate to App Setup –> Deploy –> Deployment Connections.
3. Click Edit and check the box to allow Inbound connection from BlogExampl (my Sandbox instance) and click Save. This will allow changes from the Sandbox to be deployed to Production.
4. From the Sandbox environment, click on App Setup –> Deploy –> Outbound Change Sets. An outbound change set is a set of changes you want to send from the currently logged in environment to another environment. E.g. Sandbox to Production. Click Continue if you see the “Understanding Deployments” page and then click “New.”
2. Give it a name such as ‘BtsWebServiceDeployment’ and click Save to go to the Change Set page for BtsWebServiceDeployment.
3. Under Change Set Components click Add.
4. In the Component Type drop down select Apex Class, select both of the classes that were created and click “Add To Change Set.”
5. Back on the properties page for the Change Set, click on Upload.
6. Select Production and click Upload.
If all goes well, a message will let us know the change set was uploaded successfully. At this point we need to go to the Production environment and deploy the change set.
7. In the production environment go to Setup and navigate to App Setup –> Deploy –> Inbound Change Sets. The new change set will be listed under Change Sets Awaiting Deployment.
8. Click the change set name and then click Deploy. Validate can be done before this, but we are going to assume it will work. If so you will should see the deployment with a status of succeeded.
With that our SFDC environment now has a web service that BizTalk can call.
EXPORT THE WSDL AND GENERATE SECURITY TOKEN
This is the last part to perform in SFDC. In this step the WSDL will be to exported from SFDC. That WSDL will then be used with the WCF Wizard in BizTalk to create our connections.
1. In the SFDC production environment navigate to App Setup –> Develop –> Apex Classes.
2. Under the Action column, right-click on WSDL and choose Save As next to the BizTalk Web Service that was deployed to production.
3. Save the file with a .wsdl extension. Remember where this file is. It will be imported into BizTalk.
4. Next generate the security token. SFDC requires a login to occur followed by subsequent requests. The security token along with the username and password is necessary to login to the SFDC. Go to Personal Setup –> My Personal Information –> Reset My Security Token.
5. Click “Reset Security Token.” A security token will be email to the account associated with this SFDC account.
BIZTALK CONFIGURATION
This will be posted as a follow up in a week or so.
Once you have created the web service in SFDC, BizTalk, or any client can go ahead and consume the web service. There is one additional step to this. When accessing SFDC web service, you need to first call a login web service to get a token that can be used in subsequent requests. Seroter’s blog comes in handy with a method he wrote that can be called from an orchestration which will go out and call the web service and store the token for later usage.
No comments:
Post a Comment
Post Your Comment...