Improved Error Handling with (Version 3.2.92m)

By Michael Bock, Founder & CEO - December 01, 2015

We are very happy to announce a number of recent updates to our support. These updates include e.g.:

  • Huge performance enhancements for large SOAP/XML messages
  • More information on fields included in the 'Table Layout Browser'
  • Ability to transfer changes from SFDC faster
  • Improved and more complete error messages

Huge performance enhancement for large SOAP/XML messages

To improve the processing speed we have done some general performance optimizations in our code that is handling the parsing of SOAP and XML messages. For very large XML messages received from e.g. the performance optimizations have a very big impact. One of our test cases showed that the processing time went from several hours to a few minutes. However, this was an extreme case were SFDC sent back a 15MB SOAP/XML message with 540.000 Account Ids (a response to the SFDC GetUpdated method).

Overall this optimization will benefit all services that use SOAP based WebServices - this includes SFDC, e-conomic, MS Dynamics CRM, MS Dynamics NAV Web Services and MS Dynamics AX Web Services.

The update was made in version 3.2.91m

Control characters 0x1A to 0x1F now removed from messages sent to SFDC

We now automatically check for and remove any control characters from 0x1A to 0x1F in messages sent to SFDC to make life easier for you :)

So if you had some control characters such as 'NewLine' and 'CarriageReturn' in your data fields and these where sent to, then you would get an error message back indicating that these characters could not be accepted by SFDC. We now automatically check for and remove the special characters from the data that we send to SFDC.

This update was made in version 3.2.91s

More information on fields included in the 'Table Layout Browser'

When reading design from, we now include more information about the fields in the objects in your SFDC organization. We have added information if a field is 'readonly', 'mandatory' (not nillable), 'createable', 'updateable', 'unique', 'calculated' and ' deprecatedAndHidden'. This information is visible in the 'TypeInfo' column in the 'Browse Table Layout' (see image below).

You can use this additional information to quickly determine which fields you need to map in for example the field lists in your Transfers.

type info field in the table layout browser

image 1: type info field in the 'Table Layout Browser'

This new feature is available in version 3.2.91v or later of the Rapidi Central Service.

Improved error message for non-supported features

With we currently do not support the "All Fields" feature. It normally does not make much sense to use this feature when transferring data between different systems as the field names are normally different. We now display a proper error message if you try to select this feature anyway (the error message did not indicate the exact cause of what was wrong). We also now display a better error message if you leave the Field List empty and try to run a transfer like this.

These changes are available in version 3.2.91y

Ability to transfer changes from SFDC faster

When reading from we support reading only the data that was changed or created since the last data transfer (e.g. Accounts or other objects). This is done when you specify or select the field "DBSourceControl" in the field "Source Control Field" under Source Control on a Transfer (see image 2 below). 
This will trigger some additional functionality in the Rapidi Central Service that uses the SFDC 'getUpdated' method to retrieve a list of all the Ids of objects changed in a specified time interval. We will get the Starting Time from the RTI entry for this Transfer and the Ending Time is the current timestamp.

DBSourceControl under Source Control

image 2: Transfers -> Source Control: Selecting 'DBSourceControl' in the Source Control Field 

However, the 'getUpdated' method only takes into account the date, the hour and the minute (and ignores the seconds). This means that the last changes done in SFDC within the last minute might not be returned by this call to getUpdated, but would be returned next time the transfer will run.

In cases critical transfers and especially in combination with the SFDCScheduleTrigger feature this could result in a delay of data transfer. Therefore we have now added an option that the Rapidi Central Service will automatically add one minute to the current timestamp when doing the getUpdated call to SFDC. This will ensure that all changes also from the last minutes get over correctly. But most likely this will also result in reading some records again next time the transfer runs (as we are forced to save the SourceControl as the current server Timestamp value from Salesforce - without the added minute, to avoid missing some records). So please note that when opting to use this feature, you need to check that your transfers will have no problem in getting transferred more than one time !

The feature is enabled using a server side parameter (on your Rapidi Central Service) called "SForceSCAddMinuteToLast" - default value is 0 and to enable the feature it needs to be set to 1.

You need to be on version 3.2.92b or later to use this. Please contact our support to enable this feature. When enabled, the feature will be enabled for all transfers.

Read more on our wiki about Source Control with 

Improved & more complete error messages from

We have made several changes to the error handling related to  Now the error messages provided should be more complete, more precise, and easier to understand - making your life easier as you now can resolve problems quicker related to these errors.

When transferring data to SFDC, we support sending several records to SFDC in the same message. In this case, SFDC will return a status for each record sent. In the earlier version, we checked the response and when encountering the first error message, we would return this message to the user. Now we continue to analyze the entire response and compose an error message for each record that failed to get into SFDC. In this way, you will be informed immediately of all the records failing to get into SFDC allowing you to resolve all errors at the same time. Each error message including details about what data was sent to SFDC will be written into a separate entry in the Log.

In the case of using the UPSERT method the error message will also include additional information such as if the record already exists in SFDC or does not exist. If the record exists, the ID is included in the message. This will allow you to quickly identify the problem with the data.

Fewer Log entries 

As a result of this change mentioned above, we write fewer entries into the Log. In the earlier versions, we would split the error message into several Log entries. Each time we encountered a NewLine in the message, we would start a new Log entry. This resulted in several Log entries for the same error message and sometimes it would even break the message in the middle of the data sent to SFDC containing the NewLine character. Now we only start a new Log entry when we encounter two NewLines right after each other. This works much better and the Log is now much easier to read.

Specific error messages for 'INVALID_LOGIN' & 'Password Expired'

We now provide specific error messages including directions on how to resolve the problem for 'INVALID_LOGIN' and 'Password Expired' error messages. This should make it easier for you to resolve these errors quicker without help from our support.

All these changes are available in version 3.2.92m of the central Rapidi Service. Please contact our support to arrange an upgrade to this version.

As always questions and comments are most welcome!

Best Regards


Stay Tuned for more Product Updates

About the author

Michael Bock, Founder & CEO

Picture of
Michael founded Rapidi on technological excellence, fantastic customer service and continuous improvement. A data integration specialist since 1987, he remains focused on creating technology that solves real business problems.