Here’s a couple of tips I have on using the tool that I’ve run across in the past week. (Tip #0 – Use it!)
Tip #1 – Saving your project
However, in their support forum, a Jitterbit employee explains how it can be done in the free Data Loader version:
A last option is to export your whole project as a “jitterpak”. Go to File > Export as Jitterpak and select a file location. This exports everything in your project in a format that can be imported in the full Jitterbit enterprise client.
However, you can import it into the Data Loader using this trick:
– Close the data loader.
– Go to the location on disk where yourproject is located (C:\Users\User Name\.jitterbit_dataloader\projects on Windows and ~/.jitterbit_dataloader on a Mac).
– Move away your current project (called “Data Loader”).
– Unzip the jitterpak (it has a different file ending but it’s just a zip archive) in the same location.
– Open the data loader and the exported project appears.
– The folder has to be called “Data Loader” and nothing else.
The data loader only supports a single project and that’s why you have to do it this way. The Jitterbit enterprise product supports multiple projects and you can import the jitterpak directly in the UI.
I tried this and it appears to have worked just as described.
This will be a handy trick for operations you might want to test on one machines and then later deploy to another location or when they’ve been created under one user’s login and you want to share to someone else.
Tip #2 – Bug in version 5.0.3.8 using copy function
- You create a Data Operation, let’s say it’s an upsert.
- You test it in a sandbox and have it perfected.
- You make a copy of it, edit it to use your Data Connection to your production org.
- You run it and — what the heck? now it doesn’t work.
Here’s the error message received — with some client-specific info changed to xxxx’s:
Error(s) while processing \\xxxxx.csv
Call to webservice at https://xxxx.salesforce.com/services/Soap/u/24.0/xxxxxxxxxx failed.
Reported error:
The webservice call failed.
The web service returned a SOAP Fault:
Code: sf:INVALID_SESSION_ID
Message: INVALID_SESSION_ID: Invalid Session ID found in SessionHeader: Illegal Session Detail: <sf:UnexpectedErrorFault xsi_type=”sf:UnexpectedErrorFault”><sf:exceptionCode>INVALID_SESSION_ID</sf:exceptionCode><sf:exceptionMessage>Invalid Session ID found in SessionHeader: Illegal Session</sf:exceptionMessage></sf:UnexpectedErrorFault>
Additional details: Failed to call the web service at “https://lxxxx.salesforce.com/services/Soap/u/24.0/xxxx”. Reason: The last (and probably most relevant) error was: The server returned HTTP Status Code : 500 Server Error Error is: The server encountered an unexpected condition that prevented it from fulfilling the request. Headers sent by the server: HTTP/1.1 500 Server Error Date: Wed, 10 Jul 2013 21:44:13 GMT Content-Type: text/xml;charset=UTF-8 Content-Length: 700
The bug is that there seems to be an issue with the copy functionality or the way that a data operation is created originally that is holding onto some portion of your connection information. Then, despite seeming to switch the connection information to another data connection, it’s holding onto some aspect of the original definition, causing a connection failure with your SF org. Where I ran into this the client has their own Salesforce domain name with salesforce, so that might be a necessary part of this bug.
So, the sad news is that it seems to require that you re-create your operation if you need it to point to another SF org. The good news is that it’s easy to do so with Jitterbit.
