Logging In

First we need to login to Salesforce and get our session Id.  Under the SoapBinding list, expand login and choose Show Request Editor.  After opening the request editor we need to remove the extra headers we don’t need, and fill in our username and password.

Then press the “play” button to send the request

Now in the resulting XML we can pull out our session Id

And we can pull out our server Url

Adding the new endpoint

If we create a new query request and remove the unneeded headers and insert our session Id and run the request you get the following error:

UNKNOWN_EXCEPTION: Destination URL not reset. The URL returned from login must be set in the SforceService

To fix this issue we need to add a new end point to our SOAP request.  Using the server Url obtained during login we can add it to our request

And now we can rerun our new request with the correct endpoint

Conclusion

Unlike custom webservices which include the Salesforce endpoint as part of the WSDL the standard Salesforce enterprise WSDL only has the test or login url included.  Because of this, we need to use the returned server url to set our end point.

The Problem

Lets say you have a trigger on a Contact that needs information from our mostly static MyObject__c and then the Contact trigger then updates a Case.  The Case trigger also need information from the MyObject__c.  Normally this would require two SOQL queries even if it was in a utility class.  We can use some of the built-in functionality in Apex to overload a static variable.

The Class

MyObjectUtils.cls
 

The Implementation

In the trigger where we want to use the MyObject instance we can do the following
Now, the next time the map or list are used in the same execution we will have it “cached” and will not have to make an additional query.

To combat this, you can take your triggers and condense them down into a single trigger and a single class.  Inside this class you would have a method containing each of your individual triggers.

Preface

In the examples below we will be creating a trigger on the MyObject__c to do awesomness.  In the example we do not cover the case of undelete.

The Trigger

The trigger is quite simple, all it does is call the a static method of the class with the correct parameters.

MyObject.trigger
 

The Class

This is where the meat of the functionality exists.  The constructor sets up the maps and lists as well as the booleans.  Inside your doAwesomeness method you can check to the booleans isUpdate, isDelete, isInsert to make your routing determination.  If you do not want the method to run, just return out of it and the execution will stop. MyObjectTrigger.cls

Conclusion

We’ve been using this method for almost a year now and it works really well.  If you need data to persist between methods this way works wonderfully.   Just create a global variable and set it up in your constructor.  This will save you SOQL calls and if done correctly could save you DML operations

Highlighting

Now vim is great for editing but where I think it shines the most is in highlighting.  I’ve taken the standard java vim file and have modified it for use with the Apex language.  To use it, download the apex.vim file and place it in your syntax directory for vim.

Local

To make it work for just your user you can place the file in ~/.vim/syntax/ but you will need to also symlink (or copy) the html.vim file into that directory.

ln -s /usr/share/vim/vim73/syntax/html.vim ~/.vim/syntax/html.vim

Global

To make it work for all users on the system you can just place the file into your global syntax directory.  For fedora and probably most unix systems it is /usr/share/vim/vim73/syntax/

.vimrc

Now that we’ve got highlighting installed, lets get vim to use it.  First we need to create our backup and swap directories.  We do this to keep extra files out of our Salesforce directory so that we don’t try to deploy them (or commit them to our repo).

mkdir ~/.bak ~/.swp

Now we can add / replace the following options into our .vimrc file

You might need to edit the values for tabstop, shiftwidth and softtabstop for your coding standards but 4 is what we use.

Getting soapUI

You will need to install the Open Source version of soapUI from their sourceforge.  Go ahead, I’ll wait….

Getting the WSDLs

Now that you have soapUI installed we need to download our WSDLs.  You’ll need the Enterprise WSDL which can be found at Setup-Develop-API.  And you’ll need the WSDL for your webservice which can be found at Setup-Develop-Apex Classes, then find your class and click the WSDL link next to it.  I suggest downloading them into a WSDL folder just for organization.

Setting up soapUI

Now that we’ve got all of our parts we need to create a new soapUI project.  If you are testing multiple webservices I suggest you only create one soapUI project and import the additional webservices into it.  This will make updating the enterprise WSDL easier, and will make your life less stressful.

Right-click on Projects and select New soapUI Project and fill out the form with your information.  Your intial WSDL should be the enterprise WSDL.  You will at the very least want to have Create Requests checked.  You can choose the other later if you want to.

After creating the new project you will see a section called SoapBinding with several methods below it.  These are standard Salesforce methods that are provided by the Salesforce Enterprise WSDL. Let’s ignore these for right now, and import our webservice.  To add a new WSDL right-click on the project name, Salesforce in our case, and select Add WSDL.

Then we want to choose our webservices WSDL

Using soapUI

Now that we are all setup, let’s test our webservice.  First we need to login to Salesforce and get our session Id.  Under the SoapBinding list, expand login and choose Show Request Editor.  After opening the request editor we need to remove the extra headers we don’t need, and fill in our username and password.

Then press the “play” button to send the request

Now in the resulting XML we can pull out our session Id

Copy the session Id and we will use it to make a request to our webservice.  In the example below I am calling the search method on my CaseAPI.  Again, we can remove almost all of the header out of the request.  The only section we need to leave is the SessionHeader and SessionId.

Then fill in the request to your webservice.  This will all depend on how yours is designed.  In the webservice call below, we pass in two context objects.  One takes in an ssoName and the other takes in a searchString.  Then as before click the “play” button and you’ll get your response back.

Conclusion

SoapUI is a great tool to help test webservices out.  You can use it to build up tests, but that’s another post.  I use it all of the time to verify that Salesforce is returning the correct data from my webservice instead of trying to write against the webservice and trying to determine if my client is messing up.

At my current job, we have several external systems that interact with Salesforce, and they do so through web-services. This document will cover what I have learned in regards to web-services, caveats with them and common pitfalls.

Overview

The goal of our web-services is to provide a single point of entry for each major object represented in Salesforce.  A major object would be Account, Case, Case Comment etc.  The reason this is differentiated is that for instance, Case Groups would under the AccountAPI since they are a minor object.  Each web-service consists of two parts.  First the actual web-service class which holds the exterally facing methods and from which the WSDL is generated.  The second part is that of the util class which holds all of the logic and is reusable.

Web-service class

APIUtils

This class contains several static variables, exceptions and most importantly the classes that are returned from the web-service

Static Variables

The static variables listed here are used to set the returnCode in the resulting return class.  This helps to keep return codes consistent with what is expected by the calling app

Exceptions

There are two types of base exceptions in APIUtils

InvalidException

This is used for things that are passed into the web-service that are considered invalid.  For example an invalid username passed in, or if the account does not match the requesting contact.

UnknownException

This is used when the requested object cannot be found.  For example if the case 123456 was requested and was not found then this would be aUnknownCaseException

Generic Contexts

For most web-services, they will contain their own Context classes.  But there are some context classes that are common and reusable.  The primary one being the ContactContext.  The ContactContext is often passed into the method to determine access level.

Returned Classes

These are abstraction classes usually representative of a Salesforce object.

• Each field to be returned must be of type WebService
• Each class should have Integer returnCode and String message to be passed back to the caller.
• If the method is to return a List<Object> a wrapper class of APIObjects should contain returnCode, message and a List of Objects.  [Example below]
• Each class should have a constructor to aid in creation.  This will save time in the long run and will make writing tests 1000 times easier

Note: You could probably throw exceptions out to the calling service instead of setting a returnCode.  I think that setting the returnCode instead of throwing an exception makes it easier for integration since the integrator does not need to know the exceptions.

ObjectAPI

This class should be written primarily as a wrapper class for the Object’s util class

Specific Contexts

If contexts are needed and they will only be used by this API, then they should be included directly in the API file

• Each field must be of type WebService
• Each class should have a constructor to aid in creation
• Do not assume that variables in contexts will be set

Methods

Each method should be disparate function of work and contain minimal logic.  These methods should call the required Util methods, transform data, catch exceptions and set returnCode/messages

• Method must be of type WebService
• Method must be static
• Method should return an APIObject
• Method should set the returnCode and the message of the APIObject
• All calls should be in a try-catch block so that no exceptions are leaked

ObjectUtils

This class should have the majority of the logic.  The methods in this class should follow the idea of Samurai Programming.  Samurai Programming means the method should “return successful or not at all.”  This means instead of returning null if an error happens (if the method should return something ie getCase) then the method should throw an exception.

• Most methods will be static
• Methods should throw an exception if the parameters are set incorrectly
• SOQL queries that are single lines should have their exceptions caught, reported then throw the appropriate exception.  For example if we are selecting a single Case using Case c = [ select ... ] then we should catch the exception in case the query fails, and then thrown an UnknownCaseException.

Caveats

• Declaring a class as virtual and then implementing that class to try to have global variables that all classes get do not work.  The fields will not show up in the generated WSDL

As I mentioned in my previous post, we’re looking for more wallpaper contributions to go into the next release of Fedora.  If you were saving your best work for last, or were saying “I’ll get to it soon” well now is the time.  The deadline for the wallpaper submissions is fast approaching, and August 9th will be here before you realize it.  So, take a look at my previous post for a refresher and lets see what’cha got!

What are supplemental wallpapers?

In addition to the standard wallpaper that the design team is working hard to design and finalize, we want to include some addition wallpapers for people to choose from.  We will still ship with the default GNOME upstream supplemental wallpapers but, we want to include some more from our community.

What we need

In order to us the image for the supplemental wallpapers we need some basic information

• URL of the image (ie. “where it’s at”)
• Title of the work in question
• Name of the author (their real name is preferable, but a nickname with a link to the profile on the page the image is from works as well)
• Contact information for the author, email if possible
• URL of the source page that the image was originally from
• The license of the photo (has to be compatible with the Fedora requirements)

In addition to this, what the image is of is important (see the wiki for the full requirements)

• Must not contain brand names or trademarks of any kind
• Must not contain material that is inappropriate, offensive, indecent, obscene, hateful, tortuous, defamatory, slanderous or libelous
• No religious, political, or nationalist imagery (including flags)
• No images of hats, particularly fedoras. (This is a matter of respect for our primary sponsor, Red Hat, Inc., and is not negotiable. Of course, passive appearance of hats, such as those upon heads in a crowd, may be allowed.)
• No version numbers. End users might prefer to continue to use an older theme, or use the latest theme in their older version of Fedora. To enable that choice, do not use any version numbers within the Fedora artwork.
• No text. Text should not be used in the backgrounds because the artwork is intended for a global audience and to be reused by derivative distributions.
• Should not contain images of people (contemporary, historical, or fictional)
• Should not contain images of pets, or captive or mistreated animals

How to submit

So, got that perfect image in mind for a supplemental wallpaper?  Great!  If the image meets all of the requirements then all you need to do is add it to the submissions section of the wiki and wait.  We will take submissions until 23:59 UTC on August 9th 2011 following that the design team will vote for the top 15 and they will be packaged up and included in the Fedora 16 release.

If you have any questions feel free to email me (pcon AT fedoraproject DOT org) or contact me (pcon) in #fedora-design on freenode

#!/bin/bash
meld “$2″ “$5″

Then make it executable with chmod.  Now add the following to your ~/.gitconfig file

[diff]
external = git-meld

This will now run meld whenever you do a git diff.  You can easily see diffs and apply diffs with it now.  If you click the arrow in the blue/green box it will move that chunk of code over.  If you diff multiple files, meld will run with each one of the files, so just quit out of meld and it will relaunch with the next file.

What is dropbox?
Dropbox is a cross-platform application / website that keeps files in sync and gives you 2Gb of storage space for free.  If you’re not a dropbox user already, you can sign up here.

Initial setup

The initial setup is the tricky part.  Fortunately you only need to install something (other than dropbox) on one system and only if you’re running Windows XP.

Windows XP

You’ll need to install junction to make the symlinks in Windows XP.  In Vista and later you can use mklink

Linux / OSX

You’ll use the ln command

After you have installed your game you will need to move your save game directory into your dropbox and then link to it.  For this example, I’ll be using Civ 4.  In the examples below, I’m assuming you’ve already moved your files into Dropbox/games/

Windows

junction “C:\Documents and Settings\User\My Documents\My Games\Sid Meier’s Civilization IV\replay” C:\Documents and Settings\User\My Documents\My Dropbox\games\civ4″

OSX / Linux

ln -s ~/Documents/Sid\ Meier\’s\ Civilzation\ IV/replay ~/My\ Dropbox/games/civ4