Integration Processors

This is used when there is no need for a preprocessor.

This creates the following tables in IntegrationJob.InitialDataSet:

1. ProductLookup table
2. CustomerLookup table
3. MiscLookup table.

These tables can be used by the integration processor to look up GUIDs for products, customers, and integration user profile Id respectively.

This is a rarely-used processor since the Integration Framework will normally take the "natural keys" from the source system and look up the related entities on the server side. There is a process for Pricing, however, that requires embedding of the actual product and customer Ids into resulting dataset.

Exercise caution when using this processor since it sends down all customers and products and is only available for the duration of the current job being run on the WIS.

This is used when there is no need to perform any logic on the integration server. This is typically used on jobs where only a postprocessor is needed such as rebuilding indexes or sitemaps. The external WIS processor is used to simply get the job to be processed.

The SourceMask can be used with pipe delimiters to select files with differing masks and even include subdirectories.

The destination directory is always in context to the UserFiles directory - do not use a prefix of slash.

DeleteSourceFilesOnCopy have values of True or False.

The default location for the api call can be overridden by specifying a "RemoteServerUrl". This should rarely be needed.

This connects to a remote Odbc Datasource and gets and returns data via a windows service located external to a web server requesting the data.

The query is constructed from the "Select", "From", and "Where" or "Parameterized Where" fields.

If a step parameter is present and the parameter is passed into the integration job, then the parameterized where clause is invoked rather than the standard where clause. This is used when, for example, a single customer is being requested from the management console to be refreshed - it sends in the value of the current customer into the job and the parameterized where clause is invoked in place of the standard where clause.

Parameters are referenced in the parameterized where clause by using the parameter name preceded by @

This is used when there is no need to perform any logic on the <> web server after the integration processor finishes. An example of this might be an Order Submit.

Deletes all archived datasets on the web server's /DataSet folder that are older than the "RetentionDays" parameter.

Get the latest exchange rates for all currencies in the system. This uses the application setting called "CurrencyConverter" to select the converter to use. <> currently supports WebserviceX.

Additionally, there is an application setting called "CurrencyRatePurgeDaysBack" that is used to automatically purge out conversion entries over a certain age.

Maps the data from the dataset return from the integration processor to the <> database through objects. See FieldMap section below for more details.

Handles all post processing after a Customer/Order submit. Typically this involves syncing the <> data to what was submitted to the ERP.

It updates the customer or order object respectively with the data returned from the ERP system.

When the submits are returned, the CustomerOrder is updated with the ERPOrderNumber and sets the status to "Processing". The Customer Submit updates with the ERPCustomerNumber and ERPCustomerSequence on the customer record.

Populates the "From Property" to the "To Property"

Populates the "To Property" from the application setting specified in the "From Property"

Specifies a relationship to a child collection that is specified in the "To Property". The natural key is held in the "From Property". For example, a product can be a child collection of a category.