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.


Microsoft CRM Update: Scribe Insight Update for V6.5.0 Available

  | 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 has recently released a minor update to version 6.5 - 6.5.2. Insight 6.5.2 requires that you have first installed Insight 6.5 or Insight 6.5.1.  Scribe Insight 6.5.2 includes a variety of bug fixes and new capabilities including:

  • Scribe Insight now provides failover capability to satisfy the needs of those customers who require a high availability solution. The Scribe Failover solution is built upon Microsoft's Clustered Server technology. Clustered Server provides a "virtual" reference for physical machines in a cluster, so that clients using a specific physical machine don't reference it by its specific name directly, but by its "virtual" name instead. This lets Clustered Server resolve a request for a "virtual" name to a specific physical machine with minimal to no impact to the requesting servers.
  • Scribe Insight now supports both SQL Authentication and Windows Authentication for connecting to the Scribe internal database.
  • Scribe Insight now runs on Windows Server 2008 64 bit environments.
You can find more information on this update by visiting Scribe Software's Openmind website.  A username and password is required and can be obtained from Scribe Software directly if you don't already have one.

Microsoft CRM Tip & Trick: Moving a Scribe Insight Instance

  | 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 Elite ResellerScribe Insight is arguably the most popular data integration and data migration tool for the Microsoft Dynamics CRM application. As such, it's fairly common to encounter situations where the application is installed on one server but the some part of it needs to be moved to another server. We will review the steps to affect this transfer process. For our example the original and new SQL servers will be the same version.

Preparation
You will want to have the Scribe registration key (a 16 character string), a current backup of your SCRIBEINTERNAL database, the Scribe installation media for the version currently running or the upgraded version (as this would be a good opportunity to upgrade), a copy of the collaborations folder, and verification that the new environment meets the prerequisites normally required for your Scribe installation. The prerequisite I am thinking of in particular is the message queues.

Final step once you are sure you are moving the database: remember that the old server installation must first be unregistered in order to free up the licenses. This is done through the help menu of the Scribe workbench.

Steps to follow in the new environment are:

  • Restore the database on the new SQL server
  • Install the Scribe Insight application
    • Be sure to point the installation to the existing database and not create a new one.
    • If it is an upgrade, the INTERNALDB utility will open up and guide you through the database upgrade.
    • Add your user to the new local group Scribe Console Users and restart the server.
  • Copy the collaborations folder into the Scribe program files folder overwriting the old one.
  • Using the INTERNALDB.exe located in the Scribe program folder, move the internal database.
  • Open the Scribe Workbench and register the application with the registration key.
  • Open the Console and verify that you can see the integration processes built in the previous system.
    • Open the integration processes to ensure that they open properly and ensure that they connect to the target and source correctly.

These steps will help you successfully move an installation. However, this procedure is not flawless. I have encountered various small problems that are varied and unique while doing this.  Going forward, I will address them here in our blog.


All Posts