List of required changes for existing LDI graphs

This topic lists changes you should make in existing LDI graphs before attempting to run them after you upgrade the LDI Designer and the MDEX Engine to version 2.2.x.

If you have existing graphs created in LDI that worked with the MDEX Engine in the Latitude 2.1 release, the following changes are required in these graphs so that they work after you upgrade to this release:

Making changes to the namespace of the Configuration Web Service

Change the namespace in the Request Structure of those components in LDI that use calls to the Configuration Web Service.

The namespace of the Configuration Web Service has changed to the following:

<config-service:configTransaction 
xmlns:config="http://www.endeca.com/MDEX/config/services/types" 
xmlns:mdex="http://www.endeca.com/MDEX/XQuery/2009/09">

This means that if you used the LDI WebServiceClient for sending requests through the Configuration Web Service, you need to change the way the Request Structure is specified. Use the following example:

<config-service:configTransaction 
xmlns:config-service="http://www.endeca.com/MDEX/config/services/types" 
outerTransactionId="${MDEX_TRANSACTION_ID}">
...
</config-service:configTransaction>

In this example, the line:

xmlns:config-service="http://www.endeca.com/MDEX/config/services/types"

correctly identifies the namespace.

Making Latitude components transaction-friendly

Change your existing Latitude components so that they are aware of transactions and can run either outside of transactions, or within them.

All Latitude-specific components automatically reference the outer transaction ID if it is specified in the workspace.prm file for your project.

Therefore, to make it possible to run your Latitude-specific components within transactions (as well as without transactions), add this ID to an existing project in its workspace.prm file, as in the following example (notice the empty value):

MDEX_TRANSACTION_ID=

With this change, you can continue to run your components outside of transactions (as in previous releases), and also run them within transactions, without making any additional changes to them, or to workspace.prm.

Making non-Latitude components transaction-friendly

Note: Setting the MDEX_TRANSACTION_ID parameter is optional. It allows you to have flexibility in your project if you ever need to run transactions. If you don't set it, you will still be able to run all graphs that don't use transactions.

To use any non-Latitude components, such as WebServiceClient or HTTPConnector) inside a graph that starts and commits a transaction, do the following:

Specify an outer transaction ID parameter in the workspace.prm file for your project, with an empty value:
```
MDEX_TRANSACTION_ID=
```

Include a reference to this parameter in the Request Structure for your component, as in this example:

<config-service:configTransaction 
xmlns:config-service="http://www.endeca.com/MDEX/config/services/types" 
outerTransactionId="${MDEX_TRANSACTION_ID}">
...
</config-service:configTransaction>

These steps make it possible for the components to run both with and without transactions, without requiring any additional modifications to the components configuration.

For information on Latitude-specific parameters in the workspace.prm file, see the Before You Begin section in the LDI MDEX Engine Components Guide.

Changing the way precedence rules are loaded

If you are upgrading an existing graph that loaded the configuration document describing precedence rules, this graph will no longer work. The precedence_rules document has been removed from the MDEX Engine in this release.

Replace your existing graph with the new graph that includes components for reading the precedence rules configuration from a file, reformatting the file, and then loading the rules as records, using the WebServiceClient component in LDI.

For information on loading precedence rules records into the MDEX Engine, see the section about precedence rules in the LDI MDEX Engine Components Guide.