Monday, 31 January 2011

Ruby and Salesforce Integration (Part 2)

Before we begin I have to bring up the fact that the Steelers did beat the Jets. I'm not on the same level of Nostradamus yet...but I'm getting close. When we left off at our last post we created four new Ruby files in our Salesforce directory. And as I previously mentioned we will be using code from Andrew (Super-Size) Interwebdiary to generate an easy login in function.

The following is the code for the extra file we will be using for the simple login:

client_auth_header_handler.rb

 1 require 'soap/header/simplehandler'
 2
 3 class ClientAuthHeaderHandler < SOAP::Header::SimpleHandler
 4   SessionHeader = XSD::QName.new("rn:enterprise.soap.sforce.com", "SessionHeader")
 5
 6   attr_accessor :sessionid
 7   def initialize
 8     super(SessionHeader)
 9     @sessionid = nil
10   end
11
12   def on_simple_outbound
13     if @sessionid
14       {"sessionId" => @sessionid}
15     end
16   end
17
18   def on_simple_inbound(my_header, mustunderstand)
19     @sessionid = my_header["sessionid"]
20   end
21 end
22

For the final portion of code used in the login you will need to change the username, password, and security token to fit your specifications (changes needed are highlighted in red). This code will fetch records from the Account object and post raw output on the screen.

test.rb

 1 require 'rubygems'
 2 gem 'soap4r'
 3 require 'soap/soap'
 4 require 'defaultDriver'
 5 require 'client_auth_header_handler'
 6 require 'soap/wsdlDriver'
 7
 8
 9 d = Soap.new
10 d.wiredump_dev = STDOUT
11
12 h = ClientAuthHeaderHandler.new         
# Create a new handler
13
14 l = d.login(:username => "USERNAME", :password => "PASSWORD" + "SECURITY_TOKEN")
15
16 d.endpoint_url = l.result.serverUrl       
# Change the endpoint to what login tells us it should be
17 h.sessionid = l.result.sessionId            
# Tell the header handler what the session id is
18 d.headerhandler << h                         
# Add the header handler to the Array of headerhandlers
19
20 d.getUserInfo("")  
21 d.query(:queryString=> "select id,name from account")

defaultDriver and client_auth_header_handler (the code from above) are assumed to be in the current directory.
As always you are going to want to test the code. Do this by going to the Ruby console, then the 'sfdc' folder and input the following command:

ruby test.rb

If you run into errors you are going to have look at more API calls in the API docs....which kind of drives me crazy. But sometimes that what it takes when learning new languages.

Next post we will start exploring Ruby and RoR.

Tuesday, 18 January 2011

Ruby and Salesforce Integration

With the announcement that Salesforce acquired the cloud platform Heroku I had to take a more vested interest in Ruby. Though I was aware of the capabilities of Ruby I would definitely consider myself a newbie with this type of programming. In order to jump on the bandwagon I started an extensive Ruby programming class which will allow me to build my skill set over the next couple of months.

That being said learning Ruby is great and all but the key is using it within the Salesforce platform. The next couple of posts will describe how we will use SOAP to integrate Ruby and Salesforce.

-First you need to install Ruby.  InstantRails 2.0 is radical.
-Access your developer account. Go to Setup->Develop->API then choose "enterprise.wsdl" and save it. Here is an example:

D:\RubyRails\rails_apps\sfdc\enterprise.xml

-Open the Ruby console and then install ‘SOAP4R’ by using this command:

gem install soap4r

You may get an error after running this command that reads "Errno::EADDRNOTAVAIL". This will happen if your Ruby gems are outdated. This is a simple problem to fix by going to the following site:


-After downloading the gems send them to a directory. You can then access that directory from the command line.
-Install the gems with the following command:

ruby setup.rb

At this point everything should be properly installed and you should not run into any errors. Go to the directory where you saved the ‘enterprise.xml’ and use the following command:

ruby wsdl2ruby.rb --wsdl D:\RubyRails\rails_apps\sfdc\enterprise.xml --type client –force

If everything goes well there should be four new files in your Salesforce directory. First step is complete! Next post we will use a code generated from Andrew’s (Super-size) Interwebdiary to generate an easy login function.

Till then fingers crossed the Jets get smashed by the Steelers this weekend.

Tuesday, 4 January 2011

Visualforce Controllers

The holidays are officially over and now that I have had a few days to recuperate it’s time to get back to work. The application we have been creating is pretty much ready to go… Go back to the Scheduled Invoices tab, and create a new invoice with an effective date two months in the past. Set the Duration to six months; fill out the remaining fields, and click "Save." Mark one of your pending payments as paid and you should now see three lists of payments: Past Due, Pending, and Paid. Granted this application is quite simple…but it was completed in a fraction of time and cost it would take for a traditional application.

So now that the first series of posts have been completed I wanted to jump into Visualforce Controllers. If you remember from previous entries a major component of how our application was rendered was through the use of Visualforce pages. Well a Controller is just Apex Code that analyzes and writes data in the force.com database. Also I need to make sure my blog is longer than a paragraph.

When working with Salesforce it is often required that you will need to display data from the force.com database or even insert data in database variables. Controllers can do these sorts of tasks much more quickly. There are two methods of the Controller that interact with the database variables. The ‘Getter’ method takes the value of the variables and displays it on the Visualforce page. The “Setter” method allows the developer to change the value of the variable using different Visualforce components. These methods operate similarly to the Getter and Setter methods in Java and C++.

A nice thing about the force.com platform is that it provides Standard Controllers, which are basic default controller that have already been implemented.  Though somewhat limited in functionality, you can perform certain changes to the native interface like editing records. Also you can use Apex classes to customize the controller.

My preferred method to the aforementioned Controllers is to create a Custom Controller that is completely user defined. The following is an example of a basic Custom Controller:

Page Code:

<apex:page controller="MyController">
   <apex:form>
         Name: <apex:inputText value="{!name}"/>
        <apex: outputText value="{!mssg}"/>
        <apex:commandLink action="{!Display}" value="Show Message" />
   </apex:form>
</apex:page>

MyController Code:

public class MyController{

      public String name {get ; set;}
      public String mssg {get ; set;}
      public PageReference Display() {
           mssg=’Time To Be Awesome’ + name;
           return null;
      }
}


Awesome!