Target Configuration
Choosing
the target system is nearly identical to choosing the source data, but
the process varies after you have provided the necessary connection
parameters.
Figure 3 shows the Scribe target connection options.
A
“target” in the Scribe Workbench consists of both the locations in the
target system and how the target data is structured (including
transaction integrity).
Suppose, for
example, that you are integrating sales orders into a target system.
Often, the sales header will be a different location than the sales
lines. Therefore, you define the target system as both places.
Furthermore, you most likely attempt to integrate the lines after the
header has been successfully integrated.
In
this example, integrating into the sales header and sales lines would
be represented as steps. A step has an action (for example, an insert
or update) and a workflow of what you want to happen as each step
passes, and what you want to happen should the step fail. You can chain
these steps together based on the result of a given step. The Scribe
Workbench contains a graphical representation of this flow, showing the
workflow of behaviors based on various results of the steps defined.
When you preview or test an integration, you will see the steps, or
route, each record being integrated follows, as shown in Figure 4.
Mapping and Linking Options
Scribe
Insight makes some intelligent decisions about data transformation and
management based on how you relate the source and target data sets to
each other. For example, Scribe retains the cross-referential integrity
between two systems based on key fields defined in the two systems. To
accomplish this, there are two ways to link fields in the Scribe
Workbench:
Links
A
data link is the traditional mapping relationship between two fields in
two separate systems. By choosing to relate to fields using a data
link, you are stating that you want to change the value in the target
to the value in the source.
A
lookup link defines the relationship between the source and target
fields a bit differently. A lookup link tells Scribe that the two
fields (or, more specifically, the relationship between the two fields)
define how the two data sets relate to each other. You can customize
how these two fields relate to each other; for example, the first four
characters of the source key field should align to the last four
characters of the target key field.
Formulas
You
can choose to use any of the 180+ formulas included with the product to
transform data as it moves from source to target. Alternatively, you
can create your own formulas in Visual Basic 6.0.
Many
of the core formulas are data driven, so you can modify or extend their
behavior by adding content to the appropriate Scribe database table
(specifically the SCRIBE.FunctionList table). Applications for this
feature include modifying the data used by fuzzy logic functions
available within Scribe and adding permutations for lookup.
Additional Functions
Although not in direct support of the migration of data, the Scribe Workbench allows some other functionality worth mentioning.
Test Window
The
Test window lets you to step through each record being integrated. This
preview includes the original source content, the target value
(including any transformation or formula applied to the link), and the
step control.
To open the Test window, on the Run menu, click Test.
Update Source
Upon
successfully integrating a given record, a value can be written back to
a field in the source. This feature is commonly used to mark a row as
having been successfully integrated. This value can be a string literal or a calculated value (using a formula).
The feature is available in the Source Configuration window.
Rejected Rows
When
a record fails to integrate, you can opt to have a copy of the source
data saved in a separate data source. This can prove useful when there
are larger sets of data and you want to review failed records without
sifting through the entire source data set. Furthermore, by redirecting
rejected source rows to a different location, you can focus solely on
those rows.
For example, if 150 rows fail
out of 20,000, the rejected source rows table will contain only the 150
failed rows. Working with a set of 150 rows is much easier than working
with a row of 20,000 (especially when you are trying to troubleshoot an
issue).
On the Run menu, click Edit Settings. Then use the Rejected Source Rows tab.
Key Cross Reference
One
of the common issues when trying to integrate data between disparate
systems is that values that uniquely identify an entity in one
application do not match up nicely with values used to identify that
same entity in the other system. For example, Microsoft Dynamics GP
uniquely identifies a customer using an alphanumeric
quasi-“human-readable” string; whereas Microsoft CRM uses a globally
unique identifier (GUID). Scribe offers the Key Cross Reference feature
as a way to coordinate these unique/“key” values across disparate
systems.
Over time, these unique
identifiers (databases refer to them as a “key”; hence the feature
name) are collected in a Scribe table. The more identifiers tracked,
the more efficient your integrations become. The efficiency comes in
Scribe’s capability to resolve an alphanumeric value to a GUID without
having to make calls in to CRM, for example.
These
unique values can be leveraged in formulas, too. For example, if you
want to use the key value of the Microsoft Dynamics GP customer as a
note on the account in Microsoft CRM, you can reference the unique GP
customer ID as a formula on the account’s Note field.
To manage key cross references, on the Links menu, click Cross-Reference Keys.
