Inaport versus Scribe Workbench

Normally we would not mention a competitive product, but with the release of Inaport for Dynamics CRM a common question is “why use Inaport instead of Scribe Workbench”.

This is a fair question, because Scribe is probably the incumbent player for import/migration/integration projects with Dynamics CRM.

(I might parenthetically point out that a few years ago Scribe Workbench was the incumbent for Sage SalesLogix; now InaPlex is a Sage Endorsed Development Partner, and Inaport is the only endorsed integration product for SalesLogix.)

One obvious answer to the question is pricing. Inaport starts at $450 for an entry level 30 day license through to $3,495 for the unrestricted Professional Edition; there are no seat count restrictions, and no limit on the number of systems it can be installed on. This makes it very competitive against Scribe Workbench, which is $3,995 (server) + $1,295 (adapter) + $995 (user pack) = $6,285.

However, the British have a saying “penny wise, pound foolish”; the American equivalent is “you get what you pay for”. It would be short sighted to save a few thousand dollars on the software, to later discover that either it cannot get the job done or it adds significant time and complexity to the project. Integration projects are already tough enough without also battling your tools.

InaPlex has recently been involved in a project that has provided a unique opportunity to review Inaport and Scribe Workbench side by side. The project involved a complex migration from a heavily customised GoldMine system to an equally heavily customised Dynamics CRM system. It had been started using a mixture of SQL queries and Scribe Workbench, but the project had run into difficulties and the previous personnel had left. InaPlex was part of the team called in to complete the project.

I would like to emphasis at this point that as far as InaPlex is aware, Scribe Workbench was *not* a fundamental reason for the project running into difficulties.

Ease of Use

Ease of use is in many ways a subjective assessment, but these are some of the areas where InaPlex and the channel partner felt Inaport offered benefits:

Documentation – The project had no documentation apart from the actual SQL scripts and Scribe DTS packages. Partly this was because it is not easy to document a Scribe package. Inaport provides File – Print, which produces a formatted report of the complete profile, including all notes made alongside expressions. This print can be saved as PDF or a variety of image formats.

A related issue is how the Scribe DTS packages are stored, as binary objects. Inaport profiles is stored as an XML file, that can be edited witha text editor if necessary. More importantly, version control systems can be used with them to implement safe versioning and roll back. InaPlex strongly recommends using a version control system for managing projects.

Expressions – Inaport expressions are built up using the field names of the incoming records; Scribe expressions are built using the field indexes of the incoming records. Which is easier to understand and less likely to break if the source is modified?
        #FirstName + #LastName  (Inaport)
or
        S1 + S4      (Scribe)

Preview– Almost invariably when building an integration profile, the data is going to have to be transformed. Inaport provides a Preview pane that allows you to see the first N records from the source, and also any transformations you make. The preview pane can be set to show any number of records.

Perhaps most importantly, the Preview pane allows you to see the results of expressions before any data is imported. This means you can build your expressions and see them being applied to 5, 10, or 1000 source rows before a single byte of data is brought into Dynamics. This in turn means that you can check for errors and omissions across a wide range of source data.

SQL Querying – Inaport allows you to build a full SQL Select statement to query Dynamics CRM; Scribe appears to be restricted to lookups, which allow only a single field to be queried an exact match, and a single field returned:
        dbexecsql(“T”, “select contactid from contact where importid = ‘” & #[Original System Id] & “‘”)      (Inaport)
versus
        dblookup( S44, “T”, “contact”, “importid”, “contactid” )      (Scribe)

Power

There is no question: data import and integration is a messy, nasty business most of the time. If your tool set is not up to the job, you will spend a lot of time doing work arounds to massage your data into a format that can be imported.

A classic example can be found on the Microsoft Dynamics Team Blog here, where the poster shows how to use a series of Excel expressions to split a name field (“Bill Smith”) into a first name and last name field (“Bill”, “Smith”). This is necessary because when importing contact data into Dynamics CRM, you cannot write to the FullName field; you must instead write to the individual name components FirstName and LastName. Unfortunately, the Excel functions proposed are fragile and limited – for example they do not handle name prefixes and suffixes (“Mr Bill Smith III”).

This is a very common scenario, and leads directly into one of the major strengths of Inaport.

Data Transformation

Data transformation is the ability to change the data into the required format. We have already touched on the Preview pane and Expression syntax, both of which have real advantages over Scribe.

In additon to a full range of standard functions, Inaport supports regular expressions. This means that Inaport can be used to make literally any imaginable transformation to incoming text data.

Two examples:

Name parsing– Inaport provides special functions just to parse name fields into first and last names. These functions, however, can be controlled and supplemented using prefix and suffix tables that hold regular expressions for the prefixes and suffixes to be handled. This means that you can modify their behaviour to handle specific data sets – for example, military or diplomatic honorifics. Scribe does have a name parsing function, but the prefixes/suffixes are hard coded.

HTML parsing– regular expressions make it easy to strip HTML formatting form text. For example, the GoldMine notes field is HTML formatted, and may also contain NULL characters. A couple of regular expressions are sufficient to strip all HTML formatting and leave plain text for insertion into Dynamics Notes fields.

The Inaport Expression Editor also allows you to test an expression immediately, so that you can see the result and fix any errors before doing an import.

Matching

Matching is the ability to identify correct records in the target.

Scribe matching is based on using SQL SELECT statements to identify possible matches in the target – the expression editor is used to build a a WHERE clause. For example:
        where left(company_name,8) like left(Proper(comp_name),8)

Inaport also supports SQL matching, but is more flexible – it allows you to build the complete SQL statement yourself, which means that you can query different tables or even do joins on tables to get the correct match.

Inaport also supports two further matching techniques: Standard and Fuzzy matching. Both of these techniques allow muchgreater flexibility in how match crieteria can be set up, because they allow you to use the full power of the Inaport expression editor, including using regular expressions, to build the match criteria.

Using Standard or Fuzzy matching you could for exmple, use the Inaport functions for normalising company names; this function will trim white space, remove punctuatuon, and remove noise words such as “Inc”, “llc”, “gmbh”, “ltd” etc. So the match would become:
        normcomp(#company_name)        match to       normcomp(#Comp_Name)

Inaport Fuzzy matching is particularly powerful. It allows you to build match criteria that can handle mis-spelling and near matches – for example, “InaPlex” and “Inaplx”. Using advanced string similarity algorithms,  you can set the degree of similarity you want to achieve, and also specify user review of possible matches during the import run.

Conclusion

We have only touched on the range of differences between Scribe Workbench and Inaport. It would be foolish to suggest that Scribe is a bad product – it is not, and there are clearly areas of functionality where it matches or exceeds Inaport. If you feel that I have been unfair to Scribe in any area, please let me know.

That said, Inaport has better ease of use and more raw data transformation and matching capabilities. This translates into faster, easier to manage projects.

If you would like a demonstration of Inaport capabilities, please contact info@inaplex.com