Deployment Container¶

This is the final stage of Data Migration. Approved records in Output Container and Basic Data Container which are ready for deployment appear in the deployment container. User can simulate deployment or do the actual write to the database. In order to see any data in the Deployment Container, the Filters have to be set for a specific Migration Object and a Target Table. If a given record is deployed and does not exist in the environment, record will be 'INSERT' via the Standard New__ method in the API and if already exist, records will be 'UPDATE' via the standard Modify__ method in the API. If user want to deploy data via a method other than them, they can define Other deployment Method.

In Data Migration Manager, it is possible to create Additional Deployment Processes per Target Table. There are 2 different types of Additional Deployment Processes. Pre Deployment, modifies the data in the Target Table, before it is deployed, and Post Deployment, modifies the records after it has been deployed in the Target Environment. If a Template Project is used, it usually contains a number of predefined Pre and Post Deployment processes.

Deployment container has a generic table structure similar to other with 12 columns to store key field values, 400 columns to store non-key field values and 12 columns called 'Target Key' to fetch key values from the target environment it is deployed to. This happens if the Key Field is defined to be “Auto Generated” in the Target Table Definition. If the deployed record has been deployed and maybe needs to be updated, Data Migration Manager needs to know the key values to be able to find the record. If the key value is auto generated, this value is created in the environment and needs to be fetched and stored in the Data Migration Manager for later use.

Data Deployment¶

When Deploying Records to Target Environment, there are two different options to choose between. Deploy with Commit and Deploy without Commit. 'Deployment Without Commit' option helps to identify potential data deployment errors where the deployment transaction is rolled back at the end. 'Deployment with Commit' migrate the data record with a commit and upon successful deployment values of the key fields are fetched to the 'Target Key' columns, if they are Auto Generated. Only Deploy with Commit, can update the Deploy Status and the Deploy Date Time field. The Result of Deploy without Commit, is presented in the Deploy Message Field. Post deployment can be carried out with 'Deploy With Commit' Option only.

Other Deployment¶

If a user wants to deploy a record using a method other than the standard New__ and Modify__, Other Deployment can be defined. Setting this method active will consider this method and not the New__ or Modify__ standard methods.

Pre and Post Deployment¶

It is possible to setup a chain of Methods, to be executed in a sequence, either before the deployment, Pre Deployment, or after the deployment, Post Deployment. The purpose of this is to have the possibility modify or update the data when needed.

Use the Sequence field, to define the execution order for the methods. The List of Value, will list all Methods, connected to the specified Target Table, but for the advanced user, it is also possible to specify other suitable methods if needed.

When a method is defined, its parameters need to be set. This requires, good knowledge about how the Methods and its parameters works. Define what Target Table fields should be used for Input and Output. It is also possible to use Default values as Input. The output value could be mapped to destination field(s). Each output field could be mapped to up to three fields if needed. User need to map the Target Table Fields in the Output Container, containing Legacy Data, against the correct Parameters. Some Parameter could have Default values, some is used for Input and some for Output. In the case of Functions FUNCTIONAL_RESULT denotes the output value.

Pre Deployment could be used for Calculations of missing values, like sales prices, using, IFS methods for Sales Price calculations, or, to Update missing Key values, that is Target Environment Specific, like Sequence Numbers.

Post Deployment is typically used for different kind of Updates of Records, or Status Updates for transactions that should be further processed. Like Customer Orders, after they've been created. When Status updates is used, it is possible to specify a field to be used for execution condition, like Order Status.

Execute Sql Statement - Additional Deployment Process¶

This is a feature for Pre-Deployment process. Process type for this feature is "Sql Statement". This is usually used to query/get a value for a field, which should be available for deployment of particular record. For example, if a record's primary key consists of a sequence, then user can configure system to get next sequence number from target database and use it as the primary key for deploying records like wise deployment with custom reference field should be done with a pre-deployment process for execute SQL statement as it requires the 'OBJKEY' for the record from the reference table.

Following describes how to configure a process of pre deployment sql statement.

1. Create additional deployment process.¶

Navigate to Solution Manager > Data Management > Data Migration Manager > Deployment Processing > Additional Deployment Processes > Additional Deployment Process Overview
Add a additional deployment process
- Process Category: Pre Deployment
- Process Type: Sql Statement

2. Add sql executor method as the method name in additional deployment process detail¶

Navigate to Solution Manager > Data Management > Data Migration Manager > Deployment Processing > Additional Deployment Processes > Additional Deployment Process or click on command "View Deployment Process" in step 1
The method "DAT_DEPLOY_DEFINITION_API.EXECUTE_SQL_STATEMENT", will be available with any selected target table. This method will dynamically execute sql statements user provides.

3. Add Sql Statement¶

Specifying sql statement done by defining method parameters for "DAT_DEPLOY_DEFINITION_API.EXECUTE_SQL_STATEMENT". Following are parameters.

Parameter Name	Description
SQL_STMT_	Accepting Sql Statement. Only accepting Sql Statements starting with SELECT or WITH clauses Sql Statement should only be returning one value. Sql statements returning multiple values are not accepted since purpose is to extract single value for destination column in a record Sql statement should be defined in client field "Default Value"
PARAM1_ to PAPAM20_	Optional parameter values which can be used inside Sql statement. User has possibility to map a source column to a parameter so that source column value will be taken as a parameter for sql statement
FUNCTION_RESULT	OUT parameter receving result of executed sql statement. Can be mapped to destination column

Example 1: Adding a constant description value to a description field of a target table

Here, sql statement will always returning constant value and replacing description field value in target table. This is a basic demonstration example which will illustrate how to setup a sql statement.

SQL_STMT_ :

 Select 'demo description' from dual

FUNCTION_RESULT : Destination column1 mapped

Example 2: Use a parameter inside Sql statement

Here, column value of a row will be used as a parameter in sql statement, which will be used to fetch description value and place it on another column. In this example, inventory part is migrated. Users want to fetch description of the inventory part from master part.

SQL_STMT_:

Select &AO.Part_Catalog_API.Get_Description(:PARAM1_) from dual

PARAM1 _: Source column mapped FUNCTION_RESULT : Destination column1 mapped

This example, the process will fetch "description" from master part for each inventory part and use that value for "DESCRIPTION" field of inventory part record.

Example 3: Get next sequence

Here, next sequence number will be fetched, which will be used to assign key value for the record. In this example, Design Object (PLANT_OBJECT) is migrated. Users want to get next sequence value for primary key and use it on deployment.

SQL_STMT_:

SELECT &AO.PLANT_OBJECT_SEQ.nextval FROM DUAL

FUNCTION_RESULT: Destination column1 mapped

This example, process will fetch next sequence value from target database sequence for Design Object and use that value for "OBJECT_SEQ" field of design object record.

Example 4: Get OBJKEY for reference custom field

Here, objkey value will be fetched, which will be used to connect the custom field with the reference table. In this example, data migrated for sales region table with a reference field as locality_id from locality table. Users want to get OBJKEY value for reference field and use it on deployment.

SQL_STMT_:

SELECT OBJKEY FROM LOCALITY WHERE LOCALITY_ID = :PARAM1_

PARAM1 _: Source column mapped FUNCTION_RESULT: Destination column1 mapped

This example, process will fetch objkey value from reference table for given locality_id in legacy data and use that value for reference field 'LOCALITY' of sales region record.

4. Important Notes¶

Additional deployment process should be active to use the process.
Any DML or DDL operations are restricted
User should be concerned about the performance of the SQL as this will be executed for each deployed record.
Using heavy calculations are not recommended as it may impact performance.