Jitterbit - Jack of all Trades, Master of ETL
Use Cases and Deployment Scope
We have 15 Jitterbit projects in production right now (housing about 5 times as many jobs/operations that run at various times of the day/night) and QA/DEV environments that mirror those projects. Currently, these jobs primarily move business data to and from our Salesforce org. We are currently also looking at Jitterbit's API creation and management capabilities for real-time data needs, but have not put anything info production yet... only QA.
Integrations we currently have (Source/Targets):
Oracle ↔️ Salesforce
SQL ↔️ Salesforce
FTP ↔️ Salesforce
Salesforce ↔️ Salesforce
Local File ↔️ Salesforce (Used in Jitterbit Cloud Dataloader for one time import/exports)
Jitterbit Features we Use: *Including, but not limited to the list below*
Operation Chaining
Email Notifications (success or failure)
Logging (WriteToOperationLog)
Scripting
Operation Chunking
Project Variables for source/target credentials
Conditional Mapping
StringToHex/Base64Decode for creation of varBinary SQL data
Get/Set Last Run Time – for pulling only modified records since last successful run
SQL Target Db Pre-script - Include Null Updates
Temporary Storage (for csv files to use further down Operation chain)
Pros
- Logging - totally configurable by the user, you can log any details about your running jobs, online (WriteToOperationLog) or to an email.
- Cloud management environment. Can manage users and/or the running of operations from the website and do not need a client application to do so.
- Client application is full featured and allows for greater control than our last "EDI"-type product we owned.
- Operation-chaining -- a necessity! And it works well.
Cons
- Migrating operations from QA to Production work well for initial deployment, however, when migrating an update to an existing job to production, sometimes certain project items are duplicated. This is not the end of the world... the duplicates can be removed, but would be nice if it was not required.
- I have not found a way to trap under-the-covers SOAP errors (for example, when a query you are running against Salesforce takes too long). You get a warning error in the operation log that the job only pulled a "partial" file, but it does not fail.
