About the CRM Insights Blog

CRM Insights Blog shares practical tips, trends, thoughts, links, ideas and tools for successful CRM today.

Subscribe by Email

Your email:

CRM Insights Blog

Current Articles | RSS Feed RSS Feed

Managing Scribe Timeouts

  | Share on Twitter Twitter | Share on Facebook Facebook | Buzz This  Google Buzz | Submit to Digg digg it |  Add to delicious  delicious |  Submit to StumbleUpon StumbleUpon |  Share on LinkedIn LinkedIn 

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. 


Scribe GP Adapter Table Access

  | Share on Twitter Twitter | Share on Facebook Facebook | Buzz This  Google Buzz | Submit to Digg digg it |  Add to delicious  delicious |  Submit to StumbleUpon StumbleUpon |  Share on LinkedIn LinkedIn 

As part of our integration practice, we end up creating integrations that are well outside the functionality of templates offered by the integration software provider.  In particular, there are times where the tables involved in the integration need special inclusion in the security model that informs the integration module.

Each integration software has different methods for providing object access to the integration tool.  In Scirbe Insight's case, when it comes to Dynamics GP, the list of SQL objects that can be accessed by their tool is contained in a table called KSYNCTABLEBASE located in the company database (not to be confused with the DYNAMICS database). 

It is likely that part of your design document includes identification of the objects that are being integrated between the systems.  You can check to see if the tables included in your integration design are accessible by reviewing the results of the following query against the company database:

select * from KSYNCTABLESBASE

Note - of course, you must have Scribe Insight and the Scribe GP Adapter installed for this table to exist there.  

If the table you are looking for is not found there, you may add it using the following query and substituting the 'PA00401' value with whatever table you need to access with the Scribe Workbench: 

 INSERT INTO KSYNCTABLESBASE

( TABLENAME, OWNER, SUBJECT_AREA, LABEL, TYPE, UPDATABLE, HIDDEN, DRS_OBJECT, BASE_TABLES, REMARKS, FIELD_INFO )

VALUES

( 'PA00401', 'dbo', 'Additional Integration Objects', null, 'U', 'Y', 'N', null, null, 'Table used for additional information', null)

Happy integrating.

 


Scribe Insight - Salesforce URL and Endpoint

  | Share on Twitter Twitter | Share on Facebook Facebook | Buzz This  Google Buzz | Submit to Digg digg it |  Add to delicious  delicious |  Submit to StumbleUpon StumbleUpon |  Share on LinkedIn LinkedIn 

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.


Outlook Integration Behaving Badly?

  | Share on Twitter Twitter | Share on Facebook Facebook | Buzz This  Google Buzz | Submit to Digg digg it |  Add to delicious  delicious |  Submit to StumbleUpon StumbleUpon |  Share on LinkedIn LinkedIn 

A driving force in adoption of any CRM application is often tied directly to the ability of the CRM application to integrate with the end user's primary communication and planning tool -- Microsoft Outlook.  A solid integration with this application plays a critical role with end user buy-in.  Many sales efforts are won or lost based on a good Outlook integration.  

What many evaluators tend to overlook is that Microsoft Outlook becomes unstable with add-ins.  I have seen add-ins from Skype, Microsoft, Salesforce and many others cause Outlook to hang, crash, restart and force mail store file scans.  Many other blog postings (on various websites) have addressed these specific issues in detail. The goal of this blog is only to identify the fact that the add-ins are not necessarily the problem.

The matter then is really that Microsoft Outlook is overly cautious about capturing the potential errors sometimes leading to instability of a once-stable key end user application.  Understanding this before evaluating any software integration with Microsoft Outlook is critical.

Sometimes conflicts can occur between various add-ins.  It is important to understand which add-ins your users are currently employing so that you can research which combinations tend to cause problems.  Prior to purchasing any CRM application it is important to aggressively test drive the trial offer from a CRM application ensuring that you work the Outlook integration.  For on premise users, this means testing it within your network environment. 

Understanding that Microsoft Outlook sometimes behaves badly with add-ins will prevent un-met expectations and a lot of frustration down the road.


All Posts