Posted by Bill Goulette on Tue, Mar 09, 2010
Scribe Insight DTS packages, which are the integration mappings and instructions component of a Scribe integration, may be scheduled and managed through a tool called the Scribe Console.
The tool presents categories of information in a tree on the left side and list views on the right. The list views within the Collaborations - Integrations area of that tool provides an overview and general status of the scheduled integrations. Occassionally, the status might give you something other than the designed Paused or Active status. When the status is Failed, the desciption column will give you some information on the reason.
I recently encoutered an error I hadn't seen before that I couldn't readily find the answer for:
"The Job was terminated because the message processor is unresponsive."
After some research it was discovered that there is a 60 second timeout built into Scribe that is applied to the time the source query is initially executed and the time that the first row is processed into the target. There are a variety of reasons for why this might happen (server latency, network latency, etc...). While you are trying to determine the cause for the latency, there is a registry entry you can create that will allow for a manual override of the standard timeout.
The key named ProcHangTimeOut needs to be created in the HKEY_LOCAL_MACHINE\SOFTWARE\Scribe\EventManager\Settings key. This represents the timeout in seconds. Set this to what makes sense for you.
Remember that messing around in the registry is inherently dangerous if you don't know what you are doing, so be careful not to disturb anything else when working in the registry.
Posted by Bill Goulette on Mon, Feb 01, 2010
Scribe Insight is an affordable, on premise ETL (Extract - Transform - Load) middleware that works very well with the majority of possible data sources. Early on, Scribe had the only software that one could use to load data into Dynamics CRM versions 1.X and 3.0 because of a connector they built for it, but enough with the history lesson.
As Salesforce.com grew in popularity, Scribe developed a connector for it also. One can use the connector by selecting it from the available adapter connections when developing a DTS in the workbench or when creating a publisher that queries Salesforce. In both instances, there is the ability to specify the URL in the connection information. I will spend a paragraph or two pointing out a few of the often overlooked aspects of the URL used in these connections.
When defining the connection to Salesforce.com you may specify a Salesforce.com sandbox instance. This is done by taking out the 'www' the URL in the connection string and replacing it with 'test' (i.e.: "https://www.salesforce.com/services/Soap/u/14.0" now reads "https://test.salesforce.com/services/Soap/u/14.0"). The username and the password for the sandbox connection will then work. Often times, a person will use the sandbox's username and password and get a failed connection error and will realize after some troubleshooting that this little setting change was overlooked. Of course, when the work you have done is ready for production, be sure to change this segment in the connection string back to 'www'.
Salesforce.com upgrades its application on a regular basis repairing issues and making new functionality available to their user base. Salesforce.com releases are represented in the connection string at the end of the connection string. You will notice that the version that is defaulted to 14 (i.e.: "https://www.salesforce.com/services/Soap/u/14.0"). In order for existing publishers and DTS packages to take advantage of the new features provided in the new versions of Salesforce, the URL must be manually modified to reflect the new version. These are commonly referred to as endpoints. (At the time this blog article was written, the current version was 17.0).
Interestingly enough this change must be made to all of the connections that connect to the same Salesforce.com instance. Part of the reason that the costs can be kept affordable is that the licensing model they use is based on licenses purchased and not on a per-connection basis. As a result, if you do not change the end point for all the connections that connect to the same Salesforce.com instance, Scribe will multiply the amount of licenses that it thinks you need by the amount of distinctly different endpoints that your integrations are are using.
For example; an organization has purchased 100 licenses of Salesforce.com Enterprise Edition but is using endpoints 16.0 on older integrations and 17.0 for all the new ones. Scribe is now going to count 200 licenses and give you a licensing error in the alert log in the Scribe Console. This is easily remedied by manually making the suggested adjustment from the above paragraph, but it will give your integration administrator a bit of work to figure out the problem.