An Easier Way to Monitor Your Scribe Integration Processes

For anyone that's used Scribe to develop integrations between Microsoft CRM and any other application, you know the importance of monitoring your Scribe Integration Processes for potential errors. It's extremely important to notify administrators of potential problems or errors as soon as possible after they occur.

While Scribe does offer built in alerting functionality, as well as email capability, it can sometimes be difficult to setup. In contrast, you've most likely setup workflow based emails in CRM and know how easy that is to do.

On a recent project, I decided to try a different approach for monitoring my Scribe processes.

As I'm sure you're aware, every time a Scribe DTS runs, either manually or automatically via an integration process, it writes a record to a table called EXECUTIONLOG within the SCRIBEINTERNAL database. My solution was to create a Scribe integration process to query the EXECUTIONLOG on a timed basis, and import all new rows into a new entity in CRM. The steps I took were as follows:

1. Create a new entity in CRM called Scribe Logs. The attributes in this entity should match up with the fields in the EXECUTIONLOG table within the SCRIBEINTERNAL database. The attribute list looks something like this:

   

   1. Note that the new entity does not need any relationships to other entities within CRM
   2. Be sure and specify that the entity should be visible in Settings within CRM
2. Modify the form for the new entity to include the desired attributes. Mine looks like this:

   

3. Modify the default view for the new entity so that it looks like this (notice all of my Scribe Log records):

   

4. Create a DTS that pulls records from the EXECUTIONLOG table into your new CRM.
   1. The source of the DTS should be the SCRIBEINTERNAL database, and the query looks something like the following. Note that I am joining the EXECUTIONLOG table to my new entity and only pulling in new records (that don't already exist in CRM). Also, there are a couple of exclusions, including my Scribe collaboration for the ExecutionLog updates (I don't want a record for my process that populates my CRM entity):
      
      

      "select SCRIBE.EXECUTIONLOG.*,ORG_MSCRM.dbo.NEW_scribelog.NEW_execid

      from SCRIBE.EXECUTIONLOG

      left outer join

      ORG_MSCRM.dbo.NEW_scribelog on SCRIBE.EXECUTIONLOG.EXECID=

      ORG_MSCRM.dbo.NEW_scribelog.NEW_execid collate database_default

      where ORG_MSCRM.dbo.NEW_scribelog.NEW_execid is null

      and collaboration<>'exec log to crm'"

5. Create a query based Integration Process in Scribe that runs the aforementioned DTS and populates the new entity in CRM. The finished product looks something like this:

   

6. Finally, create a workflow rule or rules in CRM to alert a user or set of users anytime an error condition (or anything you want to monitor for that matter) occurs. In my particular case, I'm sending an email anytime a Scribe Log record gets created that has any failed records or a fatal error message.

   

   

Now, with all of your Scribe log records in your CRM database, you can use CRM workflow to monitor and alert as you wish. You'll obviously still need to login to your Scribe/CRM server to resolve any issues, but using CRM workflow for alerting has proved much easier for me that utilizing the built in Scribe tools. Plus, you have a nice and easy place within CRM to go and see how many processes have run, etc.

Note you will probably also want to setup jobs or tasks to clear out your Scribe Execution log as well as the Scribe Log entity in CRM on a periodic basis. That might just be a topic for my next blog post…

Comments

[Pierre Hulsebus]

Clever! Very Clever...

[Robert_Engage2day]

As usual, Nice post and great idea! It makes the import progress accessible to more than the developers. Thanks.