Platform 2018.1.0.0 Interface Generation Program Reference Guide

Interface Generation
Program Reference Guide

JDA® Platform
Release 2018.1.0.0
Legal notice
Rights to the content of this document
Copyright © 1996-2018 JDA Software Group, Inc. All rights reserved.

Printed in the United States of America.
Reproduction of this document or any portion of it, in any form, without the express written consent of JDA Software
Group, Inc. ("JDA") is prohibited.
These materials are protected by the Copyright Act of 1976, as amended, as an unpublished work and the foregoing
notice and legend shall not be deemed to constitute publication or an intent to publish thereunder. These materials
are proprietary and confidential information of JDA and may be disclosed and used only as authorized in a signed,
written agreement controlling such disclosure or use.
The fact that a particular name or logo does not appear on this notice does not constitute a waiver of any intellectual
property rights that JDA has established in any of its products, feature or service names, or logos.
Trademark, Registered, and Service Mark notices
JDA is a registered trademark of JDA Software Group, Inc. JDALearn is a service mark of JDA Software Group, Inc.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. SAP and SAP HANA are trademarks or
registered trademarks of SAP SE in Germany and in several other countries. Microsoft, Encarta, MSN, and Windows
are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
Autodesk and Revit are registered trademarks or trademarks of Autodesk, Inc., in the USA and other countries. All
other product names and company names may be the trademarks/service marks or registered trademarks/service
marks of their respective owners.
Throughout this document, certain designations may be used that are trademarks that identify the goods of third
parties. Although this document attempts to identify the particular trademark owner of each mark used, the absence
of a trademark symbol or other notations should not be taken as an indication that any such mark is not registered or
proprietary to a third party. Use of such third-party trademarks is solely for the purpose of accurately identifying the
goods of such third party. The information contained herein is subject to change without notice.
Modifications to the contents of this document
JDA reserves the right, at any time and without notice, to change these materials or any of the functions, features,
and specifications of any of the software described herein. JDA shall have no warranty obligation with respect to
these materials of the software described herein, except as provided in the JDA software license agreement with an
authorized licensee.
Rights to the functionality of this document
Described functionality may not be available as part of a customer's maintenance agreement or the JDA Investment
Protection Program. New features and products are subject to license fees. JDA warranty and support obligations
apply only to the documentation as delivered by JDA, and are void if the documentation is modified or supplemented
by anyone other than JDA. This document embodies JDA valuable trade secrets, is confidential to JDA, and must be
kept in confidence and returned upon the expiration or termination of your JDA license agreement. You are not
permitted to copy, extract, distribute, transfer, or share the contents of this document with anyone except authorized
individuals within your organization.
Technical documentation
NOTICE: This design or technical documentation is supplied as a courtesy only and does not form part of the
"Documentation" as defined in your JDA license agreement. This design or technical documentation is supplied in the
English language only and is supplied "as is" and without warranties. JDA, at its discretion, may choose to offer this
document in additional languages, but is under no obligation to do so. JDA undertakes no obligation to update this
design or technical documentation.
Patents
This product may be protected by one or more United States and foreign patents. Please see the JDA Patents website.
Provide feedback on this document
JDA values your opinion and strives to ensure that the documentation you receive is clear, concise, and
provides the appropriate information required for you to use each JDA application efficiently.
If you would like to provide feedback on this document, you can submit your questions or suggestions to
the JDA Documentation Management team and they will be forwarded to the appropriate development
teams for review and consideration in a future release.
In addition to the provided documentation, many additional resources are available to help you understand
and work with your JDA applications. For more information on these resources, see the JDA Services
website.
Software implementation advisement
JDA products offer intuitive solutions to solve complex problems and situations. Your software comes with
highly advanced algorithms that use techniques that may include heuristics, optimization, machine
learning, data science, and so on. JDA also invests heavily to ensure that the algorithms, workflows, and
overall user experience can be configured to satisfy your needs, providing personalized optimization
combined with extreme scalability. With the broad range of functional and technical capabilities, along with
numerous configuration possibilities that the packaged solutions offer, it is commonly advised to use
strategic services to design, technical services to install and tune, and education services to train, when
rolling out any advanced software.
JDA recommends using JDA certified consultants to get the best possible domain and functional advice
available to ensure that your products are configured to provide the best possible results. In the absence of
expertise, an incorrectly configured system can lead to suboptimal results and subpar performance. In
these circumstances, JDA Support Services will refer you to consulting partners who can be engaged to
answer further questions and guide the implementation.
Software support
The JDA Solution Investment Policy includes the levels of support available for your licensed applications to
maximize your benefit. Through the JDA Customer Support website, you can access a comprehensive
summary of your licensed applications and the Solution Investment Policy that describes your current
levels of support. By supporting only the newest software versions, JDA can provide you with exemplary
service, enabling you to realize an evolving return on your software investment.
Table of Contents
Chapter 1. Interface Generation Program 1
If you are installing a JDA application that uses the IGP 1
If you customize or develop an IGP implementation 1
IGP Reference 2
igp.cmd 2
Component 2
Purpose 2
Default location 2
Source 2
Detailed description 2
Relationships 3
Comments 3
igp_init.cmd 3
Component 3
Purpose 3
Default location 3
Source 3
Relationships 4
Comments 4
igpjobmanager.cmd 4
Component 4
Purpose 4
Default location 4
Source 4
Relationships 5
IGPProperty.properties 5
Component 5
Purpose 5
Default location 5
Source 5
Tracing and logging properties 5
Database connection property (required) 6
Initial trigger state properties 7
Delete unsuccessful header/detail property 7
Pre and post-processing properties 7
Additional property file property 8
UDC properties 9
Row-level pre and post-processing properties 9
Override row-level processing properties 10
Detailed error procedure properties 11
schemaOwner property facilitates a shielded environment 12
TableSpace assignment 13
Storage clause assignment 14
igpxmlgen.cmd 14
Component 14
Purpose 14
Default location 14
Source 14
Relationships 15
INTERR_<TABLENAME> table 15
Component 15
Purpose 15
Default location 15
Source 15
Relationships 16
Comments 16
INTERRPROC_<TABLENAME> procedure 16
Component 16
Purpose 16
Default location 16
Source 16
Relationships 17
INTINS_<TABLENAME> table 17
Component 17
Purpose 17
Default location 17
Source 17
Relationships 17
Comments 17
INTINSPROC_<TABLENAME> procedure 17
Component 17
Purpose 17
Default location 17
Source 18
Relationships 18
INTINSTRIG_<TABLENAME> trigger 18
Component 18
Purpose 18
Default location 18
Source 18
Relationships 19
Comments 19
INTJOBS table 19
Component 19
Purpose 19
Default location 19
Source 19
Relationships 19
Comments 19
INTREP_<TABLENAME> table 19
Component 19
Purpose 19
Default location 20
Source 20
Relationships 20
Comments 20
INTREPPROC_<TABLENAME> procedure 20
Component 20
Purpose 20
Default location 20
Source 20
Relationships 20
Comments 21
INTREPTRIG_<TABLENAME> trigger 21
Component 21
Purpose 21
Default location 21
Source 21
Relationships 21
Comments 21
INTUPD_<TABLENAME> table 21
Component 21
Purpose 22
Default location 22
Source 22
Relationships 22
Comments 22
INTUPDPROC_<TABLENAME> procedure 22
Component 22
Purpose 22
Default location 22
Source 22
Relationships 22
INTUPDTRIG_<TABLENAME> trigger 23
Component 23
Purpose 23
Default location 23
Source 23
Relationships 23
Comments 23
INTUPS_<TABLENAME> table 23
Component 23
Purpose 23
Default location 23
Source 24
Relationships 24
Comments 24
INTUPSPROC_<TABLENAME> procedure 24
Component 24
Purpose 24
Default location 24
Source 24
Relationships 24
INTUPSTRIG_<TABLENAME> trigger 25
Component 25
Purpose 25
Default location 25
Source 25
Relationships 25
Comments 25
uninstall_wcif.sql 25
Component 25
Purpose 25
Default location 25
Source 26
Relationships 26
Comments 26
wcif.plb 26
Component 26
Purpose 26
Default location 26
Source 26
Interface tables created by wcif.plb 28
Triggers created by wcif.plb 28
Stored procedures created by wcif.plb 29
Stored procedure parameters 29
Relationships 31
Comments 31
wcif<TABLENAME>_row_params.txt 31
Component 31
Purpose 31
Default location 32
Source 32
Relationships 32
Comments 32
IGP User Guide 32
Installation 32
Edit the IGPProperty.properties file 32
Create the Integration Jobs table 33
Grant user roles 33
Run the Interface Generation Program 34
Sample execution of igp invocation 34
When to run the IGP 34
Run the interface table creation script 34
Implementing integrations 34
Data flow methods 35
Insert data flow 35
Update data flow 35
Upsert data flow 36
Replace data flow 36
Use the igpjobmanager utility 38
Use the Rename -r flag 38
Use tablespace/storage clause assignments 39
Example TABLESPACE/STORAGE clause assignment 39
Use SQL*Loader to populate interface tables 40
Specify columns in the control file 40
Use the ignore_null parameter 43
XML configuration file defines data requirements 43
IGP parses the XML to create stored procedures 43
Stored procedures use ignore_null to handle NULL values 43
ignore_null parameter purpose 43
ignore_null parameter evaluation 44
Single table scenario logic tables 45
Not nullable and has default 45
Not nullable and no default 45
Nullable and has default 46
Nullable and no default 46
Header table scenario logic tables 47
Detail table scenario logic tables 49
Chapter 1. Interface Generation Program

The WebConnect Interface Generation Program (IGP) component of JDA is used for data level integrations
involving large volumes of inbound data that must be checked for referential integrity or database
constraints before being processed through to JDA application database tables.
The IGP is used to generate the following database objects:
l Interface tables that stage inbound data for processing
l Triggers that invoke IGP-generated stored procedures
l Stored procedures that check data and perform target database loading
l Error tables that capture failed records
l Jobs table that captures Job ID processing data
The IGP properties file is used to control how the IGP generates the database objects. An XML database
configuration file specifies how the IGP-generated interface tables are defined.
The IGP is typically used under the control of an ETL (extract, transform, and load) tool, although data level
integration can be performed at the command line level, as well.
If you are installing a JDA application that uses the IGP

Many JDA applications use the IGP to protect the integrity of the database by accumulating inbound data in
temporary interface tables, then checking each record before moving it into the application’s database. JDA
, which automatically installs the IGP component, must be installed before you install JDA applications that
use the IGP. A JDA application may install a static XML configuration file, which defines the interface table
requirements, and update the IGPProperty.properties file accordingly. However, it is more likely that the
application database schema will be populated with views used by the igpxmlgen command, which
automatically generates the XML configuration file. See "igpxmlgen.cmd" (on page 14)".
Application-specific instructions for configuring the IGP are found in each related application’s installation
and administration guide.
If you customize or develop an IGP implementation

If you customize an existing IGP implementation, or develop one from scratch, this section provides a
complete reference to the features and functions of the IGP.
This section is categorized as following:
IGP Reference - This section uses an alphabetized reference format to explain each delivered or
generated component of the IGP.
IGP User Guide - This section uses a procedural format to explain tasks, involving one or more
components, that you may need to perform when using the IGP.
Notes:
l In order to use the IGP, you must have access to SQL*Plus and SQL*Loader. Also, Oracle needs
to be installed with the Wrap utility, on the computer where you are running the igp command.
The wrap executable must be present in the <ORACLE_HOME>/bin directory. IGP uses the wrap
utility to wrap the .sql files in the wcif.plb file.
l In UNIX, command files have no extensions. For example, in Windows the IGP command file is
named igp.cmd, while in UNIX it is named igp.
JDA Interface Generation Program Reference Guide 1

© Copyright 1996-2018 JDA Software Group, Inc. - Confidential
IGP Reference
Components of the Interface Generation Program include those that are installed and those that are
generated by the installed components. Whether you are editing the IGP properties file, developing a new
IGP implementation, or just curious about how the IGP works, this section explains each component;
including its name, purpose, default location, source, and description, as well as any relationship to other
components. The following components are organized alphabetically and do not reflect the order in which
each should be implemented. For a procedural organization, see the "IGP User™s Guide" section of this
chapter.
igp.cmd
Component
Interface Generation Program (IGP) command file.
Purpose
The Interface Generation Program (IGP) can be used for data level integrations where large volumes of
inbound data must be checked for referential integrity or database constraints before being processed
through to JDA application database tables.
Default location
<jda_config>\bin\platform\igp.cmd
Source
Installed automatically with JDA .
Detailed description
The central file of the Interface Generation Program is the command file, which parses an application’s XML
configuration file and, using property values in the "IGPProperty.properties" (on page 5) file , generates the
IGP interface table creation script "wcif.plb" (on page 26), which you will use to create interface tables,
stored procedures, and triggers.
See "Use SQL*Loader to populate interface tables" (on page 40).
The IGP takes the following command line arguments:
igp [-h] [-u] <user> <password> <xml_file> <APPNAME> [<TABLENAME>]
Argument Description
[-h] Optional and generally used alone. Returns
usage message and exits
[-u] Optional. Returns a list of currently connected

users, while the IGP is connected.
<user> Specifies username for RDBMS.
<password> Specifies password for user on RDBMS.
<xml_file> Specifies the application-specific XML

configuration file to parse.

Argument Description
<APPNAME> Specifies the target schema’s application. Must
match the format used in the
IGPProperty.properties file.
[<TABLENAME>] Optional and used only when creating

interface tables for a single table in the
schema. Specifies a single table name in the
schema. Lacking this optional argument,
interface tables are created for all target tables
described by the XML file.
Relationships
l Configured by "IGPProperty.properties" (on page 5) file.
l Parses the XML configuration file.
l Generates interface table creation script. See "wcif.plb" (on page 26)".
Comments
l Regardless of whether the XML configuration file is provided with a JDA application as a static file or
is generated by the igpxmlgen command, making further modifications to the XML file will cause the
IGP to fail.
l Run the IGP only after running the igp_init.cmd and confirming the IGPProperty.properties file
settings.
igp_init.cmd
Component
IGP initialization command file.
Purpose
The IGP initialization command file creates the INTJOBS table and set up error handling.
Default location
<jda_config>\bin\platform\igp_init.cmd
Source
Before running IGP, you must run igp_init.cmd to create the Jobs table (INTJOBS), which records all of
the tracking information provided by each execution of each stored procedure.
The command igp_init takes one argument, which is the ORACLE connection to the target application
database. For example,
igp_init <oracle_connection_string>

Relationships
l Creates the "INTJOBS table" (on page 19) table.
l Sets up error handling.
Comments
The igp_init command must be run one time for each target application database.
igpjobmanager.cmd
Component
IGP job manager command file.
Purpose
Can perform two functions, depending upon the flag parameter used. Executing the igpjobmanager
command’s Rename function, using the -r flag, allows you to rename the job ID prior to running the stored
procedure. For example:
igpjobmanager -r [-h] <username> <password> <APPNAME> [<job_ID_to_replace>
[<new_job_ID_label>]]
Executing the igpjobmanager command’s Status function, using the -s flag, allows you to set a failure
threshold that you can use to abort the process if more than the specified number of failures occurs. For
example,
igpjobmanager -s [-h] <username> <password> <APPNAME> <target_TABLENAME>
<interface_TABLENAME> <job_ID> [<acceptable_failure_rate>]
Default location
<jda_config>\bin\platform\igpjobmanager.cmd
Source
The igpjobmanager command can be used for two purposes, depending upon the flag used. The
igpjobmanager gets its database connection string from the IGPProperty.properties file, based on
the APPNAME value. As does the IGP, the igpjobmanager also uses the APPNAME in the
IGPProperty.properties file to locate the appropriate dburl parameter.
Operating system return codes for igpjobmanager
Return code igpjobmanager Rename utility igpjobmanager Status utility
0 - Normal The job(s) were renamed All rows were loaded successfully.
successfully.
2 - Warning The job ID to rename does not exist. Some rows were rejected during
the load process; however, the
threshold was not exceeded.

Return code igpjobmanager Rename utility igpjobmanager Status utility

3 - Critical The job cannot be renamed due to an If you specified a threshold, the
error, such as constraint violation or threshold was exceeded.
invalid characters.
4 - Fatal The rename utility cannot connect to The status utility cannot connect
the database or cannot locate the to the database or cannot locate
IGPProperty.properties file. This error the IGPProperty.properties file.
is also returned if you specify an
invalid application name when you
run the utility.
Relationships
l Uses "IGPProperty.properties" (on page 5) file.
l Renames the job ID in the "INTJOBS table" (on page 19).
l Renames the job ID in each "INTERR_<TABLENAME> table" (on page 15) that has a matching job
ID parameter value.
IGPProperty.properties
Component
IGP properties file
Purpose
The IGP properties file is used by the IGP to connect to the desired database, set trigger states, and
otherwise control how the IGP functions.
Default location
<jda_config>\properties\IGPProperty.properties
Source
The IGP properties file is self-documented with comments that explain how to edit the file. Any variable, in
the form <variable>, must be replaced with a valid value in order for the IGP to run successfully.
The IGP properties file contains the following properties:
Tracing and logging properties

traceFileDirectory - The path to the trace file. For example,
traceFileDirectory = d:/server/weblogiclogs
traceFileName: File to which trace information should be written during the import and export processes.
For example,
traceFileName = igp.log

traceFlush: If set to “true”, the trace file will be closed after each write. The default value is “false”. For
example,
traceFlush = false
Typically, traceFlush is set to “true” only for testing or troubleshooting, because processing speed is
adversely affected with this setting.
echoTraceToConsole: If true, tracing information is output to the same window as the executing
process. The default value is “false”. For example,
echoTraceToConsole = false
traceDateFormat: Used to specify the date format to use when writing trace information to the screen or
trace file. For example, to display dates in the format 01/01/2000 11:30:00, set traceDateFormat as
follows:
traceDateFormat = MM/dd/yyyy HH:mm:ss
traceLevel: Specifies the amount of tracing information to output, using one of the following three levels:
off - Outputs no tracing information.
terse - Outputs minimal information.
verbose - Outputs all available information.
To capture minimal tracing information, for example,
traceLevel=terse
useClob: Used only for Collaborate/Market Manager applications. This flag needs to be set as
“true”, when large number of user defined columns exist in a table. Otherwise, the user
may encounter the "Buffer Too Small" error while inserting records using IGP. The default
value is “false”.
useClob=false
Database connection property (required)

You must connect to a target database using the JDBC thin driver.
dburl - prepended by the appropriate application name, is assigned the database connection string. For
example:
<APPNAME>.dburl=jdbc:oracle:thin:@<host>:<port>:<SID>
At a minimum, you must provide the following values for the command:
<APPNAME> is the name of the application to which the target tables belong. dburl - is the database
connection property.
<host>:<port>:<SID> are the three values needed for a connection to the database.
Note: It is strongly recommended that the IGP connect to the target database using the JDBC Thin
driver, as provided for in the template IGP Properties file. If you modify the command to use Oracle’s OCI
JDBC driver, which uses JNI, it is your responsibility to include %Oracle_HOME%/bin in the %Path%
variable for Windows, $ORACLE_HOME/lib32 in $LD_LIBRARY_PATH for Solaris, $ORACLE_HOME/lib32
in $SHLIB_PATH for HP, and $ORACLE_HOME/lib32 in $LIBPATH for AIX.

Initial trigger state properties

Triggers created by the interface table creation script default to an enabled (on) state. A trigger, which is an
Oracle “AFTER INSERT” trigger, invokes the appropriate IGP-generated stored procedure as soon as the
insert statement has completed. If you intend to invoke the stored procedures manually, you can turn off
the triggers by setting their initial states to “off” in the IGPProperty.properties file. Template
commands are provided for each mode of operation, as follows:
Insert: <APPNAME>.<TABLENAME>.INS.InitialTriggerState= off
Update: <APPNAME>.<TABLENAME>.UPD.InitialTriggerState= off
Upsert: <APPNAME>.<TABLENAME>.UPS.InitialTriggerState= off
Replace: <APPNAME>.<TABLENAME>.REP.InitialTriggerState= off
Note: If a Header/Detail relationship exists, the REP trigger will be used in place of UPD and UPS triggers.
In the following example:
l The trigger on the Insert interface table will be disabled upon creation.
l The trigger on the Update interface table will be created in an enabled state.
l The trigger on the Upsert interface table will be created in an enabled state, because it defaults to
“on” if not set to “off”.
APPLICATION1.TABLE1.INS.InitialTriggerState= off
APPLICATION1.TABLE1.UPD.InitialTriggerState= on
Note: The trigger state property settings control only the installed state of the triggers. These states
could be manually changed at any time, thereby altering the expected behavior.
Delete unsuccessful header/detail property

DeleteUnsuccessfulHDRDTL - Specifies how to handle deletion of unsuccessful Header/Detail
relationships. For example,
<APPNAME>.<HEADER_TABLENAME>.DeleteUnsuccessfulHDRDTL= off
where
<APPNAME> is the name of the database application.
<HEADER_TABLENAME> is the name of the header table. It must be in UPPERCASE to be evaluated
properly.
See ""Header and Detail tables" (on page 36)" for a detailed explanation of this feature.
Pre and post-processing properties

Pre/post processing functionality for custom stored procedures, called from within the generated stored
procedure, can be specified in the properties file, allowing application-specific data manipulation operations,
such as data validation on rows entering the application’s database. A different stored procedure can be
called for each operation on a specific target table. Preprocessing stored procedures are invoked prior to the
generated stored procedure and post processing procedures are called before rows are removed from the
interface table.
In the IGPProperty.properties file, define the following properties to invoke pre-processing stored
procedures and post-processing stored procedures:

presp - Facilitates execution of pre-processing stored procedures, prior to executing the IGP-generated
stored procedure. For each operation, on each table, for which you want to run a pre-processing procedure,
you need to set up the following sequence of property assignments:
l <APPNAME>.<TABLENAME>.<OPERATION>.presp= <pre_processing_stored_
procedure_name>
Optional:
l <APPNAME>.<TABLENAME>.<OPERATION>.PRESP.TOTALPARAMS= <NUMBER_OF_TOTAL_
PARAMETERS>
l <APPNAME>.<TABLENAME>.<OPERATION>.PRESP.PARAM1= <PARAMETER_ONE_VALUE>
l <APPNAME>.<TABLENAME>.<OPERATION>.PRESP.PARAM2= <PARAMETER_TWO_VALUE>
l (…)
l <APPNAME>.<TABLENAME>.<OPERATION>.PRESP.PARAMX= <PARAMETER_X_VALUE>
postsp - Facilitates execution of post-processing stored procedures, following execution of the IGP-
generated stored procedure. For example,
l <APPNAME>.<TABLENAME>.<OPERATION>.POSTSP= <POST_PROCESSING_STORED_
PROCEDURE_NAME>
l Optional:
l <APPNAME>.<TABLENAME>.<OPERATION>.POSTSP.TOTALPARAMS= <NUMBER_OF_TOTAL_
PARAMETERS>
l <APPNAME>.<TABLENAME>.<OPERATION>.POSTSP.PARAM1= <PARAMETER_ONE_VALUE>
l <APPNAME>.<TABLENAME>.<OPERATION>.POSTSP.PARAM2= <PARAMETER_TWO_VALUE>
l (…)
l <APPNAME>.<TABLENAME>.<OPERATION>.POSTSP.PARAMX= <PARAMETER_X_VALUE>
Note: Stored procedures that you provide must not perform commit, rollback, or savepoint operations
internally. Using these transaction statements in ORACLE will compromise the integrity of the IGP-
generated stored procedure and produce unintended results.
Additional property file property

additionalfile - Enables specification of one separate property file, into which you can place properties
that need to be logically grouped or need to be selectively activated by changing this property. For example,
<APPNAME>.ADDITIONALFILE = <filename>.properties
The file must have the .properties extension and its location must reside in the CLASSPATH variable.
Note: The only property that must reside in the IGPProperty.properties file is the dburl property.

UDC properties
User-defined columns (UDCs) can be added to the interface table when needed to accumulate information
that is used within the integration. These interface table UDCs must be configured in the
l Interface table UDCs:
l Do not map to columns in the target tables.
l Do not support column constraints.
l Do support DEFAULT and NOT NULL attributes for a column.
l Are ignored by the generated stored procedure, unless specified as selectable.
l Can be included in the select statement of the IGP-generated stored procedure.
l Cannot be renamed with a short column name, if selectable.
Two properties in the IGPProperty.properties facilitate use of UDCs:

UDC - Specifies additional columns to be included in the interface table creation. These columns are
created only to aid in the integration process. They are not passed to the target table, have no effect on the
execution of stored procedures, and are not logged to the error table. UDC properties must be numbered
and listed in ascending order, starting with UDC1. All numbered UDCs must be preceded by the udccount
property, which specifies the number of UDCs added. For example,
<APPNAME>.<TABLENAME>.UDCCOUNT =<number_of_UDCs_listed_below>
<APPNAME>.<TABLENAME>.UDC1 = <oracle_specific_column_description>
<APPNAME>.<TABLENAME>.UDC2 = <oracle_specific_column_description>
include (UDCs in SELECT statement) - Enables you to include any of the UDCs that you added for
integration use (see above) in the internally generated SELECT statements. This would allow you to pass
UDCs to a row-level stored procedure, for example. Valid values are:
on - include the UDC in the SELECT statement
off- don't include the UDC in the SELECT statement [DEFAULT]
Selectable UDCs must already exist as UDCs for integration use in this IGP properties file, so the include
property must follow the UDC property. The following example includes both of the example UDCs above:
<APPNAME>.<TABLENAME>.UDC1.include = on
<APPNAME>.<TABLENAME>.UDC2.include = on
Row-level pre and post-processing properties

These properties control row-level pre and post processing stored procedures that are used to execute
operations that must be performed on a row-level basis.
Note: Stored procedures that you provide must not perform COMMIT, ROLLBACK, or SAVEPOINT
operations internally. Using these ORACLE features will compromise the integrity of the IGP-generated
stored procedure and produce unintended results.
ROWPRESPTOTAL - Tells IGP how many row-level pre-processing stored procedures to expect.

ROWPRESPx - Pre-processing stored procedure identifier, where “x” is the sequential number of a
ROWPRESP property in the list and the assigned value is the name of the stored procedure. For example,
the second ROWPRESPx property, having a procedure name of “PRE_PROCEDURE_TWO”, following a
ROWPRESPTOTAL = 2, would be,
<APPNAME>.<TABLENAME>.INS.ROWPRESP2= PRE_PROCEDURE_TWO
ROWPOSTSPTOTAL - Tells IGP how many row-level post-processing stored procedures to expect.
ROWPOSTSPx - Post-processing stored procedure identifier, where “x” is the sequential number of a
ROWPOSTSP property in the list and the assigned value is the name of the stored procedure. For example,
the second ROWPOSTSPx property, having a procedure name of “POST_PROCEDURE_TWO”, following a
ROWPOSTSPTOTAL = 2, would be,
<APPNAME>.<TABLENAME>.INS.ROWPOSTSP2= POST_PROCEDURE_TWO
TOTALPARAMS - Tells the IGP how many parameters it should pass to the processing stored procedure
(default = 0).
PARAMx - Parameter “x”, where “x” is the sequential number of a parameter in the list of parameters
with a value of [1..TOTALPARAMS], and that parameter is then assigned a parameter value, which should
be enclosed in single quotes if it is a String. For example,
<APPNAME>.<TABLENAME>.INS.ROWPOSTSP1.PARAM2= 'TEXT TO BE PROCESSED'
Note: The numeric order present in the IGPProperty.properties file is preserved in the generated code.
Override row-level processing properties

Allows application developers to use the IGP for interface table generation and error handling, then
override row-level processing by supplying a custom stored procedure. The following properties point to and
set properties for a supplemental properties file:
ROWOVERRIDE - When followed by the pre-processing stored procedure name, identifies the stored
procedure, which will replace all row-level processing.
TOTALPARAMS - Tells the IGP how many parameters it should pass to the processing stored procedure
(defaults to 0).
PARAMx - Property x [1..TOTALPARAMS] tells the IGP what value to pass to parameter x in the processing
stored procedure. Strings should be enclosed in single quotes. This parameter is checked only if
TOTALPARAMS > 0.
The following example shows the syntax for a typical row-level override:
l <APPNAME>.<TABLENAME>.<OPERATION>.ROWOVERRIDE = <pre_processing_stored_
procedure_name>
l Optional:
l <APPNAME>.<TABLENAME>.<OPERATION>.ROWOVERRIDE. TOTALPARAMS = <number_of_

total_parameters>
l <APPNAME>.<TABLENAME>.<OPERATION>.ROWOVERRIDE.PARAM1 = <parameter_one_
value>
l <APPNAME>.<TABLENAME>.<OPERATION>.ROWOVERRIDE.PARAM2 = <parameter_two_
value>
l (…)

l <APPNAME>.<TABLENAME>.<OPERATION>.ROWOVERRIDE.PARAMx = <parameter_x_
value>
Detailed error procedure properties

An INTERRPROC stored procedure is generated by the IGP for each error table. The stored procedure
populates the ERROR_STR column in the INTERR table with the relevant error message(s) for a given error
row. The stored procedure also handles constraints listed in the XML configuration file. See"INTERRPROC_
<TABLENAME> procedure" (on page 16). The following properties handle invocation and behavior of the
INTERRPROC stored procedure:
DetailedErrorProcInvocation - Determines whether the error procedure will be automatically invoked
from within an IGP-generated stored procedure. This property defaults to “off” to avoid compromising
expected performance levels by automatically invoking the INTERRPROC stored procedure. This property
applies to the named operation on the named table. For example,
<APPNAME>.<TABLENAME>.<OPERATION>.
DetailedErrorProcInvocation = off
DisplayFirstConstraintFailureOnly - Specifies the error message depth. This property applies to all
operations that are valid for the named table.
If set to “on” (the default), the INTERRPROC stored procedure displays only the first error encountered. For
example,
<APPNAME>.<TABLENAME>.DisplayFirstConstraintFailureOnly = on
If set to “off”, the INTERRPROC stored procedure will update the ERROR_STR column in the INTERR table
with all errors that pertain to a row.
Effects of setting detailed error procedure properties

The following table explains the combined effect of setting the DetailedErrorProcInvocation and
DisplayFirstConstraintFailureOnly properties in the IGPProperty.properties file. In every case, an
ERRORPROC stored procedure is generated by the IGP for each error table. But code to automatically
invoke the error procedure from within the IGP generated stored procedures (INS/UPD/UPS/REP) for each
table will only be added if the DetailedErrorProcInvocation property is set to “on”. Optionally, the procedure
can be invoked manually from the command line. In addition, control over error reporting only occurs if the
error procedure is invoked, in which case either all encountered failed constraints are logged or only the
first encountered constraint is logged.
DetailedErrorProcI on on off off

nvocation =
DisplayFirstConstra on off on off

intFailure =
Database objects Error procedure Error procedure Error procedure Error procedure
created created and set to created and set to created and set to created and set to
rename ERROR_ rename ERROR_ rename ERROR_ rename ERROR_
STR with first failed STR with all failed STR with first failed STR with all failed
constraint. constraints. constraint. constraints.
Call added to Call added to No call added to No call added to
invoke error invoke error invoke error invoke error
procedure from procedure from procedure from procedure from
within within within stored within stored
INS/UPD/UPS/REP INS/UPD/UPS/REP procedures. procedures.

procedures. procedures.
Runtime behavior Data load - the Data load - the Data load - Error Data load - Error
error stored error stored table is populated table is populated
procedure is procedure is with all constraints with all
invoked from invoked from that could possibly constraints that
within within have failed. could possibly
INS/UPD/UPS/REP INS/UPD/UPS/REP Optionally, the have failed.
procedures and procedures and error procedure can Optionally, the
changes error changes error be invoked from error procedure
messaging to the messaging to all the command line can be invoked
first encountered failed constraints. to change error from the
failed constraint. messaging to the command line to
first encountered change error
constraint. messaging to all
failed constraints.
schemaOwner property facilitates a shielded environment

You can use the schemaOwner property to set up a shielded environment for interface table loading and
processing.
l If the schemaOwner is not specified and the IGP is invoked from the application schema, all IGP-
generated database objects go in the application database.
l If the schemaOwner is not specified and the IGP is invoked by the user of a different schema, all of
the IGP-generated database objects go in that schema.
l If the schemaOwner is specified as the application database, the IGP-generated stored procedures
go in the application database and all other IGP-generated database objects go in the schema from
which the IGP was invoked.
Therefore, if you define the schemaOwner as the application schema and establish a different schema
called, for example, igpuser, then invoke the IGP table creation script ("wcif.plb" (on page 26)) from
igpuser, the IGP-generated stored procedures will go in the application database and all other IGP-
generated database objects will go to igpuser.
This method has two advantages:
l Security: The application database is “shielded” from the igpuser, who has no direct access to the
application tables.
l Performance: The IGP generates a significant number of database objects, including the INTJOBS
table, error tables, and interface tables, which may need to accommodate a high volume of inbound
data. All of these objects can be located in a separate schema, which can be on a separate physical
drive.
schemaOwner: Identifies the application schema in which the target tables reside and directs the IGP to
place the stored procedures in that schema. All other database objects go in the schema from which the
IGP is invoked. The schemaOwner property is set in the IGPProperty.properties file, as in the following
example:
<APPNAME>.schemaOwner=<schema_name>

igpuser requirements
The schemaOwner configuration requires an igpuser schema, which is separate from the application
schema. The igpuser is required to have the SELECT_CATALOG_ROLE granted to it. Otherwise, the IGP
cannot read the system tables to determine the schema of the tables to be loaded.
The generated script also generates the necessary grant statements to link up the stored procedures and
triggers. In addition, the igpuser can manually invoke the generated stored procedure on the application
schema if the triggers are disabled.
Create a schemaOwner-supported shielded environment

1. Before you run IGP command, create an IGP user.
provides a script that creates an IGP user/schema with the name “igpmgr”. If you use this script,
you should open it and determine if you need to make any modifications for your environment. The
script, which is provided for both Windows and Unix, is: <jda_config>\database\setup\cr_
igp_user.*
If you don’t use the script, you must manually create the user and grant igpuser the SELECT_
CATALOG_ROLE.
JDA
2. Run igpinit.cmd from the application schema.
3. Run the IGP from the igpuser schema, as follows:
igp <igpuser> <password> <xml_filename> <APPNAME> [<TABLENAME>]
where:
l igpuser/password connect to an igpuser schema, which is not the application schema.
l xml_filename is the XML configuration file for the application.
l APPNAME is the application name for which the schemaOwner property has been assigned in the
4. Run wcif.plb
The generated script wcif.plb (or <TABLENAME>.plb must be invoked by the same IGP user that
invoked the IGP. The script will then prompt for the TNS_ALIAS (sqlplus stsc/stsc@TNS_ALIAS) at
the command line. You must provide the TNS_ALIAS even if the ORACLE_SID variable is set in your
environment. The script will create the interface tables to the schema of the igpuser and then
prompt the user for the password to the application schema. It will then install the stored
procedures to the application's schema. The user will be prompted for the igpuser password. Then,
the script will finish up by installing the triggers in the igpuser schema.
TableSpace assignment
The IGP generated stored procedure can generate the interface tables on a tablespace other than that
used by the target schema. Using this feature to physically create the interface tables in a separate data
file from the target schema may improve performance on high-end-systems. In addition, an overall
performance gain may result from assigning the interface tables to a different tablespace from that used
for the target schema, because the interface tables and target schema will not share Oracle blocks.

A tablespace assignment applies to all interface tables created by the IGP generated stored procedure for
the named table, or it can apply to all tables if the TABLENAME identifier is replaced with the “AllTables”
identifier. To assign tablespace for a table, add the following property:
<APPNAME>.<TABLENAME>.TableSpace = <TBS_NAME>
where:
TABLENAME can be either the target table name for which the interface tables are being created, or the
identifier “AllTables”, which causes interface tables to be created in the assigned tablespace.
TBS_NAME is the name of the assigned tablespace. It is appended to the interface table generation
portion of the generated script.
Note: The named tablespace must exist in the database before you run IGP with this property set.
Storage clause assignment

A storage clause assignment uses the format:
<APPNAME>.<TABLENAME>.Storage = <STORAGE_CLAUSE>
where:
STORAGE_CLAUSE is a list of storage parameters that are appended to the interface table generation
portion of the generated script. The script handles placement of parentheses around parameters. See
Oracle documentation for information on constructing a proper storage clause.
igpxmlgen.cmd
Component
IGP XML generation command.
Purpose
Generates an XML configuration file for a database if the schema is configured for dynamic XML
configuration generation. The alternative is a fixed XML configuration file, which cannot be updated in the
field to reflect changes in the database schema.
Default location
<jda_config>\bin\platform\igpxmlgen.cmd
Source
The IGP XML generation command can dynamically generate an XML configuration file for an application,
using information stored in four configuration view tables, which are added to the application’s schema for
the purpose.
XML configuration view tables

l IGPXML_TABLES
l IGPXML_OIDS

l IGPXML_TABLE_DETAILS
l IGPXML_RELATIONS
Rather than distributing a static XML configuration file with the application database, these four views
allow you to generate an XML configuration file that immediately reflects any post-release changes made
to the application’s schema.
Command line arguments

igpxmlgen <username> <password> <APPNAME> <schemaName> [<xmlFileName>]
where:
l username is the Oracle user name for location of configuration view tables.
l password is the Oracle password associated with username.
l APPNAME is the same as specified in the IGPProperty.properties file (case must match). This
provides a connection to the application database.
l schemaName - Selects configuration view tables for the specified schema of application tables.
l xmlFileName - optional argument, which specifies the XML filename to be generated (defaults to
<APPNAME>_igp.xml).
Relationships
l Reads four configuration views in the application database schema.
l Generates the XML configuration file that is used by igp.cmd to generate the interface table creation
script wcif.plb.
INTERR_<TABLENAME> table
Component
Interface error table for the specified target table.
Purpose
Accumulates records that fail integrity checking or database constraints.
Default location
Database object.
Source
Created for each specified interface table by the interface table creation script wcif.plb
(<TABLENAME>.plb if a single table is specified).
For each application database table, there is one INTERR_<TABLENAME> table. It is used to store records
that fail integrity checking or database constraints.

Relationships
l Created by wcif.plb.
l Populated by the INTERRPROC_<TABLENAME> stored procedure.
Comments
Information contained in each table is controlled by properties of the INTERRPROC_<TABLENAME> stored
procedure.
INTERRPROC_<TABLENAME> procedure
Component
Interface error procedure.
Purpose
Controls how records that fail integrity checking or database constraints are recorded in the INTERR table
for the specified interface table.
Default location
Stored procedure in the database.
Source
Generated by wcif.plb (<TABLENAME>.plb if a single table is specified). Each INTERR table has an
associated INTERRPROC procedure.
An INTERRPROC stored procedure is generated for each INTERR table. The stored procedure populates the
ERROR_STR column in the INTERR table with relevant error messages for constraints that fail integrity
checking. The method by which the INTERRPROC stored procedure lists failed constraints is determined by
two properties in the IGPProperty.properties file:
l DetailedErrorProcInvocation property, if enabled, the INTERRPROC stored procedure will be invoked

from the IGP-generated stored procedure.
l DisplayFirstConstraintFailureOnly property, if enabled, lists only the constraint for the first column
that failed a constraint for the current row. Otherwise, lists constraints for all columns in the row
that failed a constraint.
See "Detailed error procedure properties" (on page 11)" for details on setting these properties in the
Parameters
int_job parameter - The error procedure has only the int_job parameter. When invoked, the error
procedure selects only rows in the error table having a value matching the int_job parameter value.
The error procedure has no int_stamp parameter, because it does not filter on timestamps. The error
procedure has no ignore_null parameter, because the error procedure may be invoked outside the scope or
an IGP-generated stored procedure.

Example
Following is an example of the signature of an error procedure, based on the ITEM table:
INTERRPROC_ITEM(job_id IN VARCHAR DEFAULT ‘INT_JOBS’)
Relationships
Generated by wcif.plb (<TABLENAME>.plb if a single table is specified).
Populates the ERROR_STR column in the current INTERR table.
INTINS_<TABLENAME> table
Component
Interface table for data insert operation.
Purpose
Interface table used to accumulate inbound data for ""Insert data flow" (on page 35) processing.
Default location
Database object.
Source
Generated for each specified target table by the interface table creation script wcif.plb
Temporarily holds inbound records that will be processed by the generated stored procedure for an insert
data flow to the specified application table.
Relationships
Comments
For more information, see "Insert data flow" (on page 35) method.
INTINSPROC_<TABLENAME> procedure
Component
Insert data flow stored procedure.
Purpose
Stored procedure that handles "Insert data flow" (on page 35) processing for the specified table.
Default location
Database object.

Source
Generated stored procedure that moves records that pass referential integrity checking or database
constraints from the INTINS_<TABLENAME> table to the associated target database, using the insert data
flow method. Failed records are passed to the associated INTERRPROC_<TABLENAME> procedure, which
moves them to the associated INTERR_<TABLENAME> table. The procedure also accumulates a count of
successfully inserted records and total rows processed in the INTJOBS table.
Relationships
l Generated for each specified target table by the interface table creation script wcif.plb.
l Called by either the statement-level "AFTER INSERT" INTINSTRIG_<TABLENAME> trigger, or an

explicit call.
l Processes records in the INTINS_<TABLENAME> table.
l Inserts records in the associated target table.
l Passes failed records to INTERR_<TABLENAME> table.
l Updates count in the INTJOBS table of successfully inserted records.
l Updates count in the INTJOBS table of total rows processed.
INTINSTRIG_<TABLENAME> trigger
Component
"AFTER INSERT" trigger for the specified interface table.
Purpose
Invokes IGP generated stored procedure when all source records have been inserted in the interface table.
Default location
Database object.
Source
Integration source data is always added to an interface table by an insert operation. The "AFTER INSERT"
trigger, which fires when all input records have been inserted in the interface table, invokes the IGP
generated stored procedure INTINSPROC_<TABLENAME>.

Relationships
Invokes the IGP generated stored procedure.
Comments
For information on enabling/disabling triggers, see ""Initial trigger state properties" (on page 7).
INTJOBS table
Component
Integration jobs table.
Purpose
Records all of the tracking information provided by each execution of each stored procedure.
Default location
Database object.
Source
Created by igp_init command. See "igp_init.cmd" (on page 3).
The Jobs table (INTJOBS), records all of the tracking information provided by each execution of each stored
procedure. Each IGP-generated stored procedure for each of the data flow methods, accumulates a count
of successfully inserted/updated/upserted records and total rows processed and records the counts in the
INTJOBS table.
Relationships
Created by the igp_init command. See ""igp_init.cmd" (on page 3).
Populated with tracking information by each execution of each IGP-generated stored procedure.
If run, the igpjobmanager command renames the job ID in the INTJOBS table. See "igpjobmanager.cmd"
(on page 4).
Comments
The INTJOBS table must be created prior to running the IGP command.
INTREP_<TABLENAME> table
Component
Interface table for data replace operation
Purpose
Interface table used to accumulate inbound data for "Replace data flow" (on page 36) processing, which is
used in place of update or upsert operations for header/detail relationships.

Default location
Database object.
Source
Temporarily holds inbound records that will be processed by the generated stored procedure for a replace
data flow to the specified header and detail tables.
Relationships
l Associated with the INTREPTRIG_<TABLENAME> trigger, used to invoke the generated stored
procedure.
l Associated with the INTREPPROC_<TABLENAME> procedure for the specified target table.
Comments
For more information, see "Replace data flow" (on page 36) method, "Delete unsuccessful header/detail
property","Header and Detail tables" (on page 36), and ""Header table scenario logic tables" (on page 47)".
INTREPPROC_<TABLENAME> procedure
Component
Replace data flow stored procedure.
Purpose
Stored procedure that handles "Replace data flow" (on page 36) processing for header/detail relationships.
Default location
Database object.
Source
constraints from the INTREP_<TABLENAME> table to the associated target table using the replace data
flow, when processing header/detail table records. For header rows, an upsert operation is performed, in
which matched records are updated and all others are inserted. For detail rows, existing rows in the target
table, which match on header detail link columns, are deleted and replacement rows are inserted.
Relationships
Generated for each specified target table by the interface table creation script wcif.plb.

Called by either the statement-level "AFTER INSERT" INTREPTRIG_<TABLENAME> trigger, or an explicit

call.
Processes records in the INTREP_<TABLENAME> table.
Inserts or updates header and replaces detail records in the associated target tables.
Passes failed records to INTERR_<TABLENAME> table.
Updates the INTJOBS table’s count of successfully inserted/updated header records.
Updates the INTJOBS table’s count of successfully inserted detail records.
Updates the INTJOBS table’s count of total rows processed.
Comments
For more information, see "Replace data flow" (on page 36) method, "Delete unsuccessful header/detail
property","Header and Detail tables" (on page 36), and "Header table scenario logic tables" (on page 47).
INTREPTRIG_<TABLENAME> trigger
Component
Purpose
Default location
Database object.
Source
trigger, which fires when all input records have been inserted, invokes the IGP generated stored procedure
INTREPPROC_<TABLENAME>.
Relationships
Comments
For information on enabling/disabling triggers, see "Initial trigger state properties" (on page 7)
INTUPD_<TABLENAME> table
Component
Interface table for data update.

Purpose
Interface table used to accumulate inbound data for "Update data flow" (on page 35) processing.
Default location
Database object.
Source
Temporarily holds inbound records that will be processed by the generated stored procedure for an update
Relationships
Comments
For more information, see "Update data flow" (on page 35) method.
INTUPDPROC_<TABLENAME> procedure
Component
Update data flow stored procedure.
Purpose
Stored procedure that handles "Update data flow" (on page 35) processing for the specified table.
Default location
Database object.
Source
constraints from the INTUPD_<TABLENAME> table to the associated target database, using the update
data flow method and based on primary key matches between the interface table and the target table.
Every matching primary key gets updated. Failed records are passed to the associated INTERRPROC_
<TABLENAME> procedure, which moves them to the associated INTERR_<TABLENAME> table. The
procedure also accumulates a count of successfully updated records and total rows processed in the
INTJOBS table.
Relationships
Generated for each specified target table by the interface table creation script wcif.plb.

Called by either the statement-level "AFTER INSERT" INTUPDTRIG_<TABLENAME> trigger, or an explicit

call.
Processes records in the INTUPD_<TABLENAME> table.
Updates records in the associated target table.
Passes failed records to INTERR_<TABLENAME> table.
Updates the INTJOBS table’s count of successfully updated records.
Updates the INTJOBS table’s count of total rows processed.
INTUPDTRIG_<TABLENAME> trigger
Component
Purpose
Default location
Database object.
Source
trigger, which fires when all input records have been inserted in the interface table, invokes the IGP
generated stored procedure INTUPDPROC_<TABLENAME>.
Relationships
Comments
For information on enabling/disabling triggers, see "Initial trigger state properties" (on page 7).
INTUPS_<TABLENAME> table
Component
Interface table for data upsert operation.
Purpose
Interface table used to accumulate inbound data for "Upsert data flow" (on page 36) processing.
Default location
Database object.

Source
Temporarily holds inbound records that will be processed by the generated stored procedure for an upsert
Relationships
Comments
For more information, see "Upsert data flow" (on page 36) method.
INTUPSPROC_<TABLENAME> procedure
Component
Upsert data flow stored procedure.
Purpose
Stored procedure that handles "Upsert data flow" (on page 36) processing for the specified table.
Default location
Database object.
Source
constraints from the INTUPS_<TABLENAME> table to the associated target database, using the upsert
data flow method. Failed records are passed to the associated INTERRPROC_<TABLENAME> procedure,
which moves them to the associated INTERR_<TABLENAME> table. The procedure also accumulates a
count of successfully updated records, successfully inserted records, and total rows processed in the
INTJOBS table.
Relationships
l Called by either the statement-level "AFTER INSERT" INTUPSTRIG_<TABLENAME> trigger, or an

explicit call.
l Processes records in the INTUPS_<TABLENAME> table.
l Updates or inserts records in the associated target table.

l Passes failed records to INTERR_<TABLENAME> table.
l Updates the INTJOBS table count of successfully inserted and updated records.
l Updates the INTJOBS table count of total rows processed.
INTUPSTRIG_<TABLENAME> trigger
Component
Purpose
Default location
Database object.
Source
trigger, which fires when all input records have been inserted, invokes the IGP generated stored procedure
INTUPSPROC_<TABLENAME>.
Relationships
l Generated for each specified target table by the interface table creation script wcif.plb
l Invokes the IGP generated stored procedure.
Comments
For information on enabling/disabling triggers, see "Initial trigger state properties" (on page 7)
uninstall_wcif.sql
Component
IGP uninstall script.
Purpose
Use uninstall_wcif.sql to remove IGP-generated database objects from your database, especially prior to
uninstalling JDA .
Default location
<jda_config>\bin\platform\uninstall_wcif.sql
<jda_config>\bin\platform\uninstall_<TABLENAME>.sql

Note: Uninstall_<TABLENAME> exists only if you ran IGP with the <TABLENAME> argument.
Source
Created by the IGP command.
TABLENAME>.sql, which removes only those database objects created for the named table. To clean up
IGP-generated database objects for a single table, run uninstall_<TABLENAME>.sql (created for only those
tables generated with the IGP tablename argument). To clean up all IGP-generated database objects, run
uninstall_wcif.sql.
Following are the steps for removing IGP database objects:
1. Navigate to the directory from which you invoked the IGP command.
2. Run SQL*Plus, then type
@uninstall_wcif.sql
All IGP database objects are dropped from the database.
Note: If you did not run the IGP command with no tablename arguments, but rather ran it against
individual table names, you will need to run all of the resulting uninstall_<TABLENAME>.sql scripts.
Relationships
l Created by the IGP command.
l Removes IGP-generated database objects.
Comments
Warning: You must run wcif uninstall scripts prior to uninstalling JDA . Otherwise, IGP-generated
database objects will remain in your database and the scripts for removing them will have been removed
while uninstalling JDA .
wcif.plb
Component
Interface table creation script.
Purpose
Creates interface tables, triggers, and stored procedures.
Default location
Directory from which the IGP was invoked.
Source
Created by the IGP command.

wcif.plb
The IGP command parses the XML configuration file for all database table definitions and generates the
wcif.plb file. For each database table described in the XML configuration file, wcif.plb creates one error table
and a separate interface table, trigger, and stored procedure for each of the three data flow
methods"Insert data flow" (on page 35), "Update data flow" (on page 35),"Update data flow" (on page
35)). For HDR/DTL tables, it also creates ""Replace data flow" (on page 36) tables, triggers, and stored
procedures, which are used in place of those for UPD and UPS.
<TABLENAME>.plb
The IGP command, when invoked with a <TABLENAME> parameter, parses the XML configuration file for
only the specified table name definitions and generates the <TABLENAME>.plb. For the defined table,
<TABLENAME>.plb creates one error table and a separate interface table, trigger, and stored procedure for
each of the three data flow methods "Insert data flow" (on page 35), "Update data flow" (on page
35),"Update data flow" (on page 35)).
Database object naming conventions

Following are the naming conventions used for interface tables, stored procedures, and triggers:
Database object Naming convention Description

Insert data flow table INTINS_<TABLENAME> Interface table with
insert data flow
method.
Update data flow table INTUPD_<TABLENAME> Interface table with

update data flow
method.
Upsert data flow table INTUPS_<TABLENAME> Interface table with

upsert data flow
method.
Replace data flow table INTREP_<TABLENAME> Interface table with

replace data flow
method. For
HDR/DTL
relationships, the
replace operation
exists in place of the
update/upsert
functions.
Error table INTERR_<TABLENAME> Accumulates records

that fail integrity
checking.
Trigger INT<OPERATION>TRIG_ “AFTER INSERT”

<TABLENAME> trigger for a data
flow operation on an
interface table.

Database object Naming convention Description

Stored procedure INT<OPERATION>PROC_ Stored procedure for
<TABLENAME> a data flow operation
on an interface
table.
Database object names must comply with the naming restrictions associated with the database. The IGP
generates a database object name having a maximum of 30 characters, the table name portion of which
cannot exceed 18 characters because the IGP naming convention requires 12 characters. When longer
interface table names are needed, you can do one of the following:
l Specify a new short table name in the XML file.
l Allow the IGP to handle table renaming.
When the IGP handles renaming the table, it appends three digits to a truncated form of the table name, if
no short name is specified in the XML file. For example,
ABCDEFGHIJKLMNPQRST is generated into ABCDEFGHIJKLMNP001
The IGP takes the first 15 characters from the long table name and appends three digits starting with 001.
If multiple tables exist with long table names and the first 15 characters are identical, then the IGP
appends unique digits to the end. For example:
ABCDEFGHIJKLMNPQRST is generated into ABCDEFGHIJKLMNP001
ABCDEFGHIJKLMNPRSTU is generated into ABCDEFGHIJKLMNP002
Interface tables created by wcif.plb

If the XML configuration file describes a database table called SAMPLE, the interface table creation script
would create the following interface tables:
l INTERR_SAMPLE table, which accumulates all records bound for the database SAMPLE table that fail
the integrity checks. See "INTERR_<TABLENAME> table" (on page 15).
l INTINS_SAMPLE table, which accumulates records that will be inserted into the database SAMPLE
table. See "INTERR_<TABLENAME> table" (on page 15).
l INTUPD_SAMPLE table, which accumulates records that will be updated in the database SAMPLE
table. See ""INTUPD_<TABLENAME> table" (on page 21).
l INTUPS_SAMPLE table, which accumulates records that will be upserted in the database SAMPLE
table. See "INTUPS_<TABLENAME> table" (on page 23).
Given Header table SAMPLE_HEADER and Detail table SAMPLE_DETAIL table in the database, the following
interface tables would be created, as well:
l INTREP_SAMPLE_HEADER table.
l INTREP_SAMPLE_DETAIL table.
See "INTREP_<TABLENAME> table" (on page 19).
Triggers created by wcif.plb

would create the following “AFTER INSERT” triggers:

l INTINSTRIG__SAMPLE triggers insert data flow.
See "INTINSTRIG_<TABLENAME> trigger" (on page 18).
l INTUPDTRIG_SAMPLE triggers update data flow.
See "INTUPDTRIG_<TABLENAME> trigger" (on page 23).
l INTUPSTRIG_SAMPLE triggers upsert data flow.
See "INTUPSTRIG_<TABLENAME> trigger" (on page 25).
triggers would be created, as well:
l INTREPTRIG_SAMPLE_HEADER trigger.
l INTREPTRIG_SAMPLE_DETAILS trigger.
See "INTREPTRIG_<TABLENAME> trigger" (on page 21).
Stored procedures created by wcif.plb

would create the following stored procedures:
l INTERRPROC_SAMPLE procedure, which controls how records that fail integrity checking or
database constraints for the database SAMPLE table are recorded in the INTERR_SAMPLE table. See
"INTERRPROC_<TABLENAME> procedure"
l INTINSPROC_SAMPLE is the insert data flow stored procedure for the table. See "INTINSPROC_
<TABLENAME> procedure".
l INTUPDPROC_SAMPLE is the update data flow stored procedure for the table. See "INTUPDPROC_
<TABLENAME> procedure".
l INTUPSPROC_SAMPLE is the upsert data flow stored procedure for the table. See "INTUPSPROC_
<TABLENAME> procedure"
procedures would be created, as well:
l INTREPPROC_SAMPLE_HEADER procedure.
l INTREPPROC_SAMPLE_DETAIL procedure.
See "INTREPPROC_<TABLENAME> procedure".
The stored procedure performs referential integrity checks on data in an interface table to guarantee that
only valid data is moved to its associated live table. The stored procedure also ensures that data failing to
pass all referential integrity checks is moved to the appropriate error table. The stored procedure uses
information parsed from the XML configuration file to perform the necessary integrity checks.
Stored procedure parameters

All IGP-generated stored procedures will have the following parameters:
l "int_stamp" (on page 30)
l "job_id" (on page 30)

l "ignore_null" (on page 30)
The order of parameters is int_stamp, job_id, ignore_null. The stored procedure parameters can be used to
filter rows by date/time, filter rows by job ID, and control the handling of NULL values in columns.
Note: The job_id parameter is the only parameter passed to the stored procedure from the trigger.
int_stamp
The int_stamp parameter of the generated stored procedure can be used to filter rows by date/time in the
interface table. If you want to filter rows by date/time, you must first populate the INTEGRATION_STAMP
column of the interface table. To use this functionality, the stored procedure must be invoked manually
(for example, the trigger will be disabled). When invoking the stored procedure, pass in a DATE value to the
stored procedure. Rows in the interface table will be processed according to these rules:
l int_stamp = NULL: All rows will be processed regardless of INTEGRATION_STAMP column’s value.
This is the default value.
l int_stamp = <date>: All rows, where INTEGRATION_STAMP <= int_stamp or INTEGRATION_

STAMP = NULL, will be processed.
job_id
The job_id parameter of the stored procedure allows you to filter rows in the interface table by matching on
a job identifier. This parameter is generally used when the interface table is populated from multiple
sources, each having a unique job ID. Since the job_id parameter matches values in the INTEGRATION_
JOBID column of the interface table, the INTEGRATION_JOBID column must be populated, either explicitly
or implicitly, with the values against which the stored procedure compares.
job_id behavior when the trigger is enabled

If the trigger is enabled, the stored procedure takes as its value for the job_id parameter the
INTEGRATION_JOBID from the first row of the interface table.
job_id behavior when the trigger is disabled

To filter on the INTEGRATION_JOBID column of the interface table when the trigger is disabled, invoke the
stored procedure manually, passing the job_id parameter with the desired string value.
To use the default value in the INTEGRATION_JOBID column of the interface table, when the trigger is
disabled, invoke the stored procedure manually without passing the job_id parameter.
Note: If you are not populating the INTEGRATION_JOBID column of the interface table, invoke the
stored procedure without the job_id parameter. This causes the stored procedure to use the default job_
id value (INT_JOB), which is the same default used in the INTEGRATION_JOBID column.
ignore_null
The ignore_null parameter allows you to choose the way in which the stored procedure handles NULL
values in columns of the interface table. If the stored procedure is invoked with the ignore_null parameter
having a value of ‘Y’, SQL statements for rows containing NULL values will be constructed without the
NULL columns. If the stored procedure is invoked with the ignore_null parameter having a value of ‘N’, the
stored procedure will treat NULL values as intentional and no columns will be omitted.
Note: The Insert data flow method defaults the ignore_null parameter to ‘N’. All other data flow
methods default ignore_null to ‘Y’.

Column constraints affect ignore_null behavior

If the XML configuration file defines a target column as having range or foreign key constraints, the stored
procedure evaluates the ignore_null parameter based upon its value (“Y” or “N”), and the combination of
two column properties; the existence of a default value, and whether the column is nullable or not
nullable. This prevents data flow problems, such as a NULL value being passed to a not nullable column for
which there exists no default value.
See "Use the ignore_null parameter" (on page 43) for ignore_null logic tables that provide the expected
SQL “where” clause output for various combinations of data flow methods, ignore_null settings, default
availability, nullable status, and column values.
Stored procedure parameter examples

Following are examples of the stored procedure INTINSPROC_ITEM.
To invoke the stored procedure with all default values:
EXEC INTINSPROC_ITEM();
To invoke the stored procedure to filter on job ID ITEM_INSERT_0307:
EXEC INTINSPROC_ITEM(job_id => ‘ITEM_INSERT_0307’);
To invoke the stored procedure to select rows on or before December 31, 2002 with job ID of ITEM_
INSERT_0307:
EXEC INTINSPROC_ITEM(TO_DATE(‘2002-12-31’,’YYYY-MM-DD’), ‘ITEM_INSERT_0307’);
To invoke the stored procedure to ignore NULL values:
EXEC INTINSPROC_ITEM(ignore_null => 'Y');
Relationships
wcif.plb is generated by the IGP command, based upon database definitions in the XML configuration file.
wcif.plb generates interface tables, triggers, and stored procedures for the defined database tables.
wcif.plb is configured by the IGPProperty.properties file.
Comments
Notes:
l The stored procedure does not perform a commit operation.
l The first time you run the interface table creation script, you may see messages informing you
that tables can’t be dropped. You can ignore these because the interface table creation script
always attempts to drop existing tables and it will find none the first time it runs.
wcif<TABLENAME>_row_params.txt
Component
Column parameter generated text file.
Purpose
The IGP automatically generates the column parameter text file to provide the column names required by
row-level stored procedures.

Default location
Directory from which the IGP was invoked.
Source
Generated by the IGP.
When working with the row-level override stored procedures or the pre/post-processing stored procedures,
you need to provide the names of the columns that the IGP is selecting from the interface table. However,
the IGP internally generates unique names for these values; names which are derived from, but do not
match, columns in the application table. To provide you with the actual column names that you need to
pass to row-level stored procedures, the IGP automatically generates the <wcif_<TABLENAME>_row_
params.txt file.
Relationships
Information for row-level override stored procedures.
Information for pre/post-processing stored procedures.
Comments
When using the values provided in the row parameters text file, you may have to update your SQL*Loader
control files and/or IGP property file as necessary.
Note: Row-level processing occurs in INS/UPD routines. The UPS routine invokes the INS and UPD row-
level stored procedures.
IGP User Guide

Following are the tasks you may need to undertake to customize, configure, generate, and run various IGP
scripts, or otherwise implement IGP features. For a detailed description of the IGP components referenced
in this section, see the "IGP Reference" (on page 2) in this chapter.
Installation
drive>\jda\jdav7800\config, hereafter referred to as <jda_config>. Following is a list of the paths and
file names for files you may need to edit or run to configure your integration environment:
<jda_config>\properties\IGPProperty.properties
<jda_config>\bin\platform\igp.cmd
<jda_config>\bin\platform\igp_init.cmd
<jda_config>\bin\platform\igpjobmanager.cmd
<jda_config>\bin\platform\igpxmlgen.cmd
Following installation of JDA , confirm the location of these files and make note of any path differences
resulting from a change to the default installation location.
Edit the IGPProperty.properties file

The IGP is primarily configured by settings in the IGPProperty.properties file. See "IGPProperty.properties"
(on page 5).

Create the Integration Jobs table

Prior to running the IGP, you must create the Jobs table (INTJOBS), which records all of the tracking
information provided by each execution of each stored procedure. Run <jda_
config>\bin\platform\igp_init.cmd one time for each target application database. At the
command prompt, type:
igp_init <oracle_connection_string>
The file calls igp_init.sql to create the INTJOBS table and set up error handling.
Note: When you run the IGP, it will populate the Jobs table with tracking information. Prior to running
the IGP again, you must clean out the Jobs table by deleting appropriate rows or using igpjobmanager.
Grant user roles

To give users access to required DBA views, you will need to grant SELECT_CATALOG_ROLE to each IGP
user, as follows:
grant CONNECT, RESOURCE, SELECT_CATALOG_ROLE to <schemaOwner>;
where <schemaOwner> is the user that will invoke the IGP.
IGP generates the following script and runs as the IGP schema owner:
CREATE TABLE IGPMGR.INTINS_TRANSMODECAP (
UOM INTEGER NOT NULL,
MINCAP FLOAT DEFAULT 0 ,
MAXCAP FLOAT DEFAULT 999999999 ,
TRANSMODE VARCHAR2(50) NOT NULL,
CHECKCAPSW NUMBER(1) DEFAULT 1 ,
INTEGRATION_STAMP DATE,
INTEGRATION_JOBID VARCHAR(32) DEFAULT 'INT_JOB' NOT NULL );
GRANT UPDATE, DELETE, SELECT ON INTINS_TRANSMODECAP TO SCPOMGR;
CREATE OR REPLACE SYNONYM SCPOMGR.INTINS_TRANSMODECAP FOR IGPMGR.INTINS_
TRANSMODECAP;
The following grants are required for the IGP schema owner:
CONNECT,
CREATE TABLE,
CREATE VIEW,
CREATE SYNONYM,
CREATE SEQUENCE,
CREATE DATABASE LINK,
RESOURCE,
SELECT_CATALOG_ROLE,
CREATE ANY SYNONYM

Run the Interface Generation Program

Sample execution of igp invocation
igp myname mypassword appname_igp.xml <APPNAME >
This command runs igp.cmd (Windows) or igp (Unix) using the appname_igp.xml
configuration file, for an APPNAME database, to generate an interface table creation script called
wcif.plb, that is used to generate interface tables (and other related tables) for each database table
defined in the XML file (see"Run the interface table creation script" (on page 34)). An uninstall_
wcif.sql script is also created. If you specified a table in the tablename parameter, an uninstall_
<TABLENAME>.sql file will be created instead.
Note: If you use incorrect syntax when executing igp.cmd (or igp in Unix) from the command prompt,
the usage message is displayed. You can also display the usage message by entering igp -h at the
command prompt.
When to run the IGP

The Interface Generation Program must be run when:
l The database has not set up for integration.
l You specified selected tables in previous executions of the IGP and want to generate additional
interface table creation scripts.
l The schema for the database is altered since you last executed the IGP.
l The data in the tables corresponding to data domains is changed since the IGP was last executed.
Note: Failure to re-run the IGP following a schema change, such as adding a column to a table in a UDA
process, will result in unpredictable results and may generate an Oracle error.
Run the interface table creation script

The IGP parses the XML configuration file to determine which database tables need interface tables and
how those tables are defined. Based upon that configuration information, the IGP command generates the
interface table creation script, wcif.plb. It is the interface table creation script that actually creates the
interface tables, triggers, and stored procedures. If the XML configuration file changes, running the IGP
command against the modified XML file will generate a modified wcif.sql script, which reflects the changes
made in the XML. The updated wcif.plb script would have to be run to create interface tables for the
modified database configuration.
The interface table creation script is run from a command prompt using the format:
sqlplus <username>/<password> @wcif.plb
Implementing integrations
Data level integration can be performed at the command line level, by a batch script, or under the control
of an ETL tool.

Data flow methods

Each live table has a separate associated interface table for each of three data flow methods: "Insert data
flow" (on page 35)"Update data flow" (on page 35), and "Upsert data flow" (on page 36). For Header/Detail
relationships, there is a "Replace data flow" (on page 36), which replaces Update and Upsert. After source
data is inserted into the selected interface table, the trigger calls the stored procedure that performs
referential integrity checking, then moves the records to the application table using the interface table’s
data flow method. Errors reported by the DBMS during execution of the stored procedure are captured in
the Error table, which in addition to having the same schema as the interface table, includes columns to
record error messages, error codes, job IDs, and date/time stamps. Severe errors, such as “Table does not
exist.”, are passed to the Jobs table and include the RDBMS error code and error message. The stored
procedure also records successful record transfers in the Jobs table.
Insert data flow

In an insert data flow, source records should be inserted into the insert table (INTINS_<TABLENAME>)
that is associated with the target live table. When the AFTER INSERT trigger fires, it passes the Job ID from
the first row in the interface table to the stored procedure, which moves the records to the live table. Errors
are sent to the error table (INTERR_<TABLENAME>) and the count of successfully inserted records is
added to the jobs table (INTJOBS).
Insert record functional summary

l Records flow into the Interface table from an outside source.
l The stored procedure, which can be initiated by an explicit call or from a statement level AFTER
INSERT trigger, provides referential and/or unique integrity checking, then moves the data to the
live table.
l Errors are added to the error table.
l A count of successfully inserted records is added to the jobs table.
l A count of the total rows processed is added to the jobs table.
Note: For information on the rules governing AFTER INSERT triggers, consult the Oracle
documentation. Instead of the AFTER INSERT trigger invoking the procedure, an explicit call may be
made to the stored procedure if triggers are disabled. This is true for all data flow methods.
Update data flow

In an update data flow, source records are inserted into the update table (INTUPD_<TABLENAME>) that is
associated with the target live table. When all available records have been added to the table, an AFTER
INSERT trigger calls the stored procedure that ensures referential integrity, while updating records in the
live table, where there is a primary key match in the interface table. Errors are sent to the error table
(INTERR_<TABLENAME>) and the count of successfully updated records is added to the jobs table
(INTJOBS).
Update record functional summary

INSERT trigger, updates the data in the live table based on primary key matches from the interface
table. Every matching primary key gets updated accordingly.

l A count of successfully updated records is added to the jobs table.
Upsert data flow

In an upsert data flow, source records are inserted into the upsert table (INTUPS_<TABLENAME>) that is
associated with the target live table. When all available records have been added to the table, an AFTER
INSERT trigger calls the stored procedure that ensures referential integrity, while updating records in the
live table, where there is a primary key match in the interface table (existing records), then inserting all
remaining interface table records into the live table (new records). Errors are sent to the error table
(INTERR_<TABLENAME>) and counts of successfully inserted and updated records are added to the jobs
table (INTJOBS).
Upsert record functional summary

INSERT trigger, updates records that have matching primary keys and inserts records without
matching primary keys. It also maintains referential and/or unique integrity and moves data to the
live table.
l A count of successfully inserted records is added to the jobs table.
l A count of successfully updated records is added to the jobs table.
Replace data flow

Header/Detail relationships have a replace operation in place of either update or upsert. For the Header
rows, an upsert operation is performed. For the Detail rows, existing rows in the target table (matched on
header detail link columns) are deleted and new rows are inserted.
Header and Detail tables

The Header and Detail tables maintain a 1:1 mapping relationship between the interface table and the
target live table. The Header and Detail tables have two data flow types: Insert and Replace
Replace header/detail functional summary

l Records flow into the Detail Interface table from an outside source.
l Records flow into the Header Interface table from an outside source.
The stored procedure, which can be initiated by an explicit call or from a statement level AFTER INSERT
trigger (on the Header table), performs a replace operation on records that have matching link fields. It also
maintains referential and/or unique integrity and moves data to the live tables.
l Errors are added to the error table. In addition to recording failed insertions, the error table also
records header rows that are inserted incorrectly.

l A count of successfully inserted/updated records is added to the row corresponding to the header
table in the jobs table.
l A count of successfully inserted records is added to the detail row of the jobs table.
l A count of total rows processed is put in the header and detail rows of the jobs table.
Insert header/detail functional summary

l Records flow into the Detail Interface table from an outside source.
l Records flow into the Header Interface table from an outside source.
INSERT trigger (on the Header table), inserts records that have matching link fields. It also
maintains referential and/or unique integrity and moves data to the live tables.
l Errors are added to the error tables. In addition to recording failed insertions, the error table also
records header rows that are inserted incorrectly.
Note: If a Detail row fails to find a matching Header row, it will remain in the Interface table following
completion of stored procedure processing. Because the stored procedure does not search the interface
table for orphaned Detail rows prior to concluding processing, they will not be moved to the error table. If
there is a possibility that interface tables could be populated with Detail rows for which no matching
Header row exists, you should manually check the Interface table following completion of stored
procedure processing. This holds true for Replace data flows, as well.
l A count of successfully inserted records is added to the header and detail rows of the jobs table.
l A count of the total rows processed is added to the header and detail rows of the jobs table.
Header/Detail relationships have a replace operation in place of either update or upsert. For the Header
rows, an upsert operation is performed. For the Detail rows, existing rows in the target table (matched on
header detail link columns) are deleted and new rows are inserted.
Errors related to Header/Detail relationships

l Detail rows
o When a Header/Detail relationship fails, due to a problem with the Header row, the Error
message for each Detail row will indicate a Header row problem.
o When DeleteUnsuccessfulHDRDTL=on, and a Detail row fails, the rest of the Detail rows in
the relationship will contain error messages indicating that one of the other Detail rows
caused the failure.
l Header rows
o When DeleteUnsuccessfulHDRDTL=off, and a Detail row fails, the Header error table will have
a row stating that at least one Detail row has failed. This is an informational row in the error
table, as there is no error with the Header table.
o When DeleteUnsuccessfulHDRDTL=on, this message indicates the error that caused the
Header row to be in the error table.

Use the igpjobmanager utility

The igpjobmanager utility can be used for two purposes, depending upon the flag used. The igpjobmanager
gets its database connection string from the IGPProperty.properties file based on the APPNAME value. As
does the IGP, the IGPJOBMANAGER also uses the APPNAME in the IGPProperty.properties file to locate the
appropriate dburl parameter. See "igpjobmanager.cmd" (on page 4)
Use the Rename -r flag

Executing igpjobmanager.cmd with the -r flag to rename the job ID before you run the stored
procedure. This is typically used for periodic batch processing to provide a unique job ID for each run.
Command line arguments are as follows:
igpjobmanager -r [-h] <username> <password> <APPNAME>
[<job_ID_to_replace> [<new_job_ID_label>]]
Tables affected:
l INTJOBS
l INTERR_<each_table_with_a_matching_job_ID_to_the_parameter_passed_in>
You can specify the following parameters:
l Database connection information (same as IGP)
l Application name (same as IGP)
l Job ID to replace, which is the name of the Job ID to be replaced (default is INT_JOB, as in IGP
generated interface tables and stored procedures).
l New Job ID label is the name of the new job ID. The default value is derived by concatenating the
SYSDATE to the job ID that is being replaced.
Use the Status -s flag

Executing igpjobmanager with the -s flag allows you to set a failure threshold that you can use to abort the
process if more than the specified number of failures occur. Command line arguments are as follows:
igpjobmanager -s [-h] <username> <password> <APPNAME> <target_TABLENAME>
<interface_TABLENAME> <job_ID> [<acceptable_failure_rate>]
Command line parameters:
l Target Table Name is the target table to which the rows are being moved.
l Interface Table Name is the interface table from which the rows are being moved.
l JobID is a unique identifier that identifies the execution of this process.
l Acceptable Failure Rate is the percentage of failed rows (rows that failed / total rows processed) that
is acceptable for continuation of the process. The acceptable_failure_rate parameter value defaults
to 25%.

Use tablespace/storage clause assignments

It is possible to create interface tables in a separate location from the target schema. For example, placing
the interface tables on a disk other than that used by the schema. Using a different tablespace also
prevents the interface tables from sharing Oracle blocks with the target schema’s tablespace. Either of
these strategies may improve performance.
Tablespace and storage clause assignments are configured by adding tablespace properties
(see"TableSpace assignment" (on page 13)) and corresponding storage clause properties (see "Storage
clause assignment" (on page 14)) to the IGPProperty.properties file. This is especially useful if the default
storage space for the target schema is tuned for operations other than data loading. By placing the
interface tables in a different tablespace, you can tweak the storage clause to match the anticipated
incoming data volume before loading.
Warning: The IGP does not duplicate Oracle’s parsing engine, therefore you are responsible for
ensuring that your TABLESPACE/STORAGE tuning will work properly for your system. It is particularly
important to confirm that the parameters for your STORAGE cause have been specified correctly. An
invalid STORAGE clause will cause errors that will not show up until the generated script is run against
the target database.
Example TABLESPACE/STORAGE clause assignment

The following example shows the interface table creation script segment that creates interface tables for
the target schema table called ITEM, based upon these properties in the IGPProperty.properties file:
PROD.ITEM.TableSpace = NEWTBS
PROD.AllTables.Storage = INITIAL 500K NEXT 5K
PROD.TEST_HDR.TableSpace = NEWTBS
Following is a script segment that creates interface tables for ITEM:
DROP TABLE INTINS_ITEM;
CREATE TABLE INTINS_ITEM (
…column definitions go here…
) TABLESPACE NEWTBS
STORAGE (INITIAL 500K NEXT 5K);
DROP TABLE INTUPD_ITEM;
CREATE TABLE INTUPD_ITEM (
) TABLESPACE NEWTBS
DROP TABLE INTUPS_ITEM;
CREATE TABLE INTUPS_ITEM (
) TABLESPACE NEWTBS
DROP TABLE INTERR_ITEM;

CREATE TABLE INTERR_ITEM (

) TABLESPACE NEWTBS
Use SQL*Loader to populate interface tables

You can use the IGP’s generated stored procedures from within SQL*LOADER to populate interface tables.
Generally, SQL*LOADER is used when you want to automate the process in a batch script. Following is a
suggested approach to constructing a simple batch process.
Note: Before running the batch script, ensure that the appropriate triggers are enabled.
Specify columns in the control file

In the SQL*LOADER control file (*.ctl), specify the columns that will be populated in the interface table.
This process does not populate the live tables. However, interface table columns specified in the control file
should be only those for which there are corresponding columns in the live table.
Construct the SQL*LOADER call

Following is a sample SQL*LOADER call:
sqlldr user1/password1 table1.ctl bindsize=1000000 rows=2500 parallel=Y
The sample call does the following:
l Executes SQL*LOADER with the sqlldr command.
l Logs into the database using user1/password1.
l Calls the control file for table1 (table1.ctl).
l Sets the bindsize parameter to 1,000,000 bytes (based on an estimated 40 bytes for each of the
2500 rows in the example).
l Sets the rows parameter to 2500.
l Sets the parallel parameter to Y.
The bindsize and rows parameters are used to determine the commit frequency.
Construct the batch script

Following is a sample batch script format, which uses the sample SQL*LOADER call and provides the
format for an igpjobmanager call:
@echo off
SETLOCAL
@REM set variable for logging purposes in the event that an error is
encountered
set LOADTABNAME SAMPLE_TAB
@REM invoke igpjobmanager to rename jobid with date/time stamp
@call igpjobmanager stsc stsc SCPO INT_JOB
IF ERRORLEVEL 3 GOTO JOB_RENAMING_ERROR

@call sqlldr %ORALOGON% load_%LOADTABNAME%.ctl

@REM sqlldr Passes only a value of zero back on successful completion
IF ERRRORLEVEL 1 GOTO SQLLOADER_ERROR
@REM we can accept 35% failure rate for this table
@call igpjobmanager stsc stsc SCPO %LOADTABNAME% INTINS_%LOADTABNAME% INT_JOB
35
IF ERRORLEVEL 3 GOTO STATUS_ERROR
@REM oooooooooo
@REM Next table
@REM oooooooooo
@REM set variable for logging/running purposes in the event that an error is
encountered
set LOADTABNAME TEST_TAB
@REM invoke igpjobmanager to rename jobid with date/time stamp
@call igpjobmanager stsc stsc SCPO INT_JOB
IF ERRORLEVEL 3 GOTO JOB_RENAMING_ERROR
@call sqlldr %ORALOGON% load_%LOADTABNAME%.ctl
@REM sqlldr Passes only a value of zero back on successful completion
IF ERRRORLEVEL 1 GOTO SQLLOADER_ERROR
@REM we can accept 35% failure rate for this table
@call igpjobmanager stsc stsc SCPO %LOADTABNAME% INTINS_%LOADTABNAME% INT_JOB
35
IF ERRORLEVEL 3 GOTO STATUS_ERROR
@REM oooooooooooooooooooooo
@REM Error handling section
@REM oooooooooooooooooooooo
:SQLLOADER_ERROR
@echo Error executing SQL*Loader for %LOADTABNAME%
GOTO END
:STATUS_ERROR
@echo Error: Failure rate exceeded for load of %LOADTABNAME% or
@echo critical error while retrieving status.
GOTO END
:JOB_RENAMING_ERROR
@echo Error renaming job prior to dataload of %LOADTABNAME%
GOTO END
:END

ENDLOCAL
@echo Script finished.
@echo on
Note: The errorlevel variable is checked twice: after the SQL*LOADER call and after the igpjobmanager
call. Use “$?” instead of “%errorlevel%” on UNIX.
Horizontal format imports

Horizontal format imports are streams of data in which multiple rows, having key fields in common, are
defined by position within a single record. For example, an input file might have the following record:
PRODUCT1 LOC1 125 182 206
The following SQL*Loader control file loads the interface table as shown perviously:
LOAD DATA
CHARACTERSET 'UTF8'
INFILE 'test.dat'
BADFILE 'out.bad'
DISCARDFILE 'out.dsc'
APPEND
INTO TABLE TESTTAB
(PRODUCT POSITION(1:10) CHAR(10) TERMINATED BY WHITESPACE,
LOC POSITION(11:20) CHAR(10) TERMINATED BY WHITESPACE,
QTY POSITION (21:25) INTEGER EXTERNAL TERMINATED BY WHITESPACE,
STARTDATE EXPRESSION "TO_DATE('20030710', 'YYYYMMDD')")
INTO TABLE TESTTAB
INTO TABLE TESTTAB
To define an additional date/qty pair, copy and paste the “INTO TABLE <TABLENAME>” clause and modify
the data element position range for the fourth date and quantity.
The following SELECT statement produces the results shown:
SQL> select * from testtab;
PRODUCT LOC STARTDATE QTY

PRODUCT1 LOC1 2003-07-10:00:00 125

PRODUCT1 LOC1 2003-07-11:00:00 182
PRODUCT1 LOC1 2003-07-12:00:00 206
Use the ignore_null parameter

values when moving records from interface tables to live database tables. This section summarizes the
process by which the IGP uses the XML configuration file to create stored procedures, which ensure
referential data integrity when transferring data from interface tables to live tables, including the transfer
of NULL values to live table columns having data requirements affecting the use of NULL values.
XML configuration file defines data requirements

For each JDA -based application database, an XML configuration file defines the data requirements for
columns in the live database. The IGP uses this information to identify records in the interface table that
will fail to satisfy the live table data requirements, then re-routes these records to the appropriate error
tables.
IGP parses the XML to create stored procedures

The Interface Generation Program parses the XML configuration file and generates the following:
l interface table creation scripts
For each database table described in the XML configuration file, the interface table creation script
creates one error table and a separate interface table for each of the three data flow methods
(insert, update, upsert). Interface tables serve as intermediate storage areas for incoming data,
making it possible to ensure referential integrity prior to moving data to the live table.
l Triggers
For each interface table, the IGP creates a trigger, which fires when a statement that inserts records
into the interface table completes. The trigger always contains an “AFTER INSERT” definition.
l Stored procedures
Stored procedures use information parsed from the XML configuration file to perform referential
integrity checking on data in the interface table. This guarantees that only valid data is moved to
the associated live table columns.
Stored procedures use ignore_null to handle NULL values

All IGP-generated stored procedures will have the following parameters:
l "int_stamp" (on page 30)
l "job_id" (on page 30)
l "ignore_null" (on page 30)
ignore_null parameter purpose

values in columns of the interface table. In general, if the stored procedure is invoked with the ignore_null
parameter set to Y, SQL statements for rows containing NULL values will be constructed without the NULL
columns. If the stored procedure is invoked with the ignore_null parameter set to N, the stored procedure
will treat NULL values as intentional and no columns will be omitted. Insert procedures default the ignore_

null parameter to N. All other procedures default ignore_null to Y.
ignore_null parameter evaluation

The effect of setting the ignore_null parameter to Y or N varies considerably if the XML configuration places
foreign key or range constraints on columns in the database tables. To use the ignore_null parameter
effectively, you need to understand the rules governing how the IGP generates a SQL statement “where”
clause, based on the relationships among of the following attributes:
l The Database table’s column is defined by the XML configuration file as having:
o Either a foreign key constraint or range constraint
o Either a default value or no default value
o Either a nullable status or a not nullable status
l The Interface table’s column has one of the following values:
o NULL
o Any value that satisfies the XML column constraint
o Any value that fails to satisfy the XML column constraint
l The stored procedure ignore_null parameter has either of the following values:
o Y
o N
( Y is the default value for all data flow methods, except Insert, which is N.)
l For Header/Detail columns, the IGP.properties file has either of the following:
o <APP1>.HDR_FK.DeleteUnsuccessfulHDRDTL= on<APP1>.HDR_
FK.DeleteUnsuccessfulHDRDTL= off

Single table scenario logic tables

Not nullable and has default
Expected result in the generated SQL “where” clause, based upon IGNORE_
Interface NULL parameter value for each data flow
table
Insert Insert Update Update Upsert Upsert
column
value ignore_null ignore_null ignore_null ignore_null ignore_null ignore_null
=Y =N =Y =N =Y =N
NULL Constraints NULL Constraints NULL Constraints NULL
ignored. evaluated. ignored. evaluated. ignored. evaluated.
SQL ignores Fails SQL ignores Fails If update: Fails
column. constraints. column. constraints. SQL ignores constraints.
Default value Row to error Row to error column. Row to error
used. table. table. If insert: table.
SQL ignores
column.
Default value
used.
(Satisfies SQL includes SQL includes SQL includes SQL includes SQL includes SQL includes
constraint) column. column. column. column. column. column.
(Fails Row to error Row to error Row to error Row to error Row to error Row to error
constraint) table. table. table. table. table. table.
Not nullable and no default

table
Insert Insert Update Update Upsert
column Upsert
value ignore_null ignore_null ignore_null ignore_null ignore_
ignore_null = Y
=Y =N =Y =N null = N
NULL NULL NULL Constraints NULL Constraints NULL
evaluated. evaluated. ignored. evaluated. ignored. evaluated.
Fails Fails SQL ignores Fails If update: Fails
constraints. constraints. column. constraints. SQL ignores constraints.
Row to error Row to error Row to error column. Row to
table. table. table. If insert: error table.
Fails with a not
null violation.
(Satisfies SQL includes SQL includes SQL includes SQL includes SQL includes SQL
constraint) column. column. column. column. column. includes
column.
(Fails Row to error Row to error Row to error Row to error Row to error Row to
constraint) table. table. table. table. table. error table.

Nullable and has default

table
column
=Y =N =Y =N =Y =N
NULL Constraints Constraints Constraints Constraints Constraints Constraints
ignored. ignored. ignored. ignored. ignored. ignored.
SQL ignores NULL value SQL ignores Column If update: If update:
column. used. column. updated with SQL ignores NULL value
Default value NULL value. column. used.
used. If insert: If insert:
SQL ignores NULL value
column. used.
Default value
used.
Nullable and no default

table
column
=Y =N =Y =N =Y =N
NULL Constraints Constraints Constraints Constraints Constraints Constraints
ignored. ignored. ignored. ignored. ignored. ignored.
NULL value NULL value SQL ignores Column If update: If update:
used. used. column. updated with SQL ignores NULL value
NULL value. column. used.
If insert: If insert:
SQL ignores NULL value
column. used.
NULL value
used.

Header table scenario logic tables

Interface Expected result in the generated SQL “where” clause, based upon IGNORE_
table NULL parameter value for each data flow
column Insert Insert Replace Replace

value ignore_null = Y ignore_null = N ignore_null = Y ignore_null = N
NULL Constraints ignored. Constraints fail. Constraints ignored. Constraints fail.
SQL ignores column. HDR/DTL If update: HDR/DTL
Default value used. relationship to SQL ignores column. relationship to
respective error If insert: respective error
tables. SQL ignores column. tables.
Default value used.
(Satisfies SQL includes SQL includes SQL includes SQL includes

constraint) column. column. column. column.
(Fails HDR/DTL HDR/DTL HDR/DTL HDR/DTL

constraint) relationship to relationship to relationship to relationship to
respective error respective error respective error respective error
tables. tables. tables. tables.


NULL Constraints fail. Constraints fail. Constraints fail. Constraints fail.
HDR/DTL HDR/DTL HDR/DTL HDR/DTL
relationship to relationship to relationship to relationship to





value ignore_null = N ignore_null = Y ignore_null = Y ignore_null = N
NULL Constraints ignored. Constraints ignored. Constraints ignored. Constraints ignored.
SQL ignores column. NULL value used. If update: SQL If update: NULL
Default value used. ignores column. value used.
If insert: SQL If insert: NULL value
ignores column. used.
Default value used.




NULL value used. NULL value used. If update: SQL If update: NULL
ignores column. value used.
If insert: SQL If insert: NULL value
ignores column. used.
NULL value used.



Detail table scenario logic tables

Interf Expected “where” clause, based on IGNORE_NULL and DeleteUnSuccessfulHdrDtl
ace parameter values for each data flow.
table
Insert with ignore_null = N Insert with ignore_null = Y
colum
DeleteUnsuccessf DeleteUnsuccessfu
n DeleteUnsuccessfulH DeleteUnsuccessfulH
ulHdrDtl lHdrDtl
drDtl=on drDtl=off
value =on =off
=on
NULL Constraints ignored. Constraints ignored. Constraints fail. Constraints fail.

SQL ignores column. SQL ignores column. HDR/DTL
Default value used. Default value used. relationship to
respective error
tables.
( SQL includes column. SQL includes column. SQL includes SQL includes
Satisfi column. column.
es
constr
aint)
(Fails HDR/DTL relationship to Constraints fail. HDR/DTL Constraints fail.

constr respective error tables. relationship to
aint) respective error
tables.

table
Replace with ignore_null = Y Replace with ignore_null = N
colum
n DeleteUnsuccessful DeleteUnsuccessful DeleteUnsuccessful DeleteUnsuccessful
value HdrDtl=on HdrDtl=off HdrDtl=on HdrDtl=off
NULL Constraints ignored. Constraints ignored. Constraints fail. Constraints fail.
SQL ignores column. SQL ignores column. HDR/DTL relationship
Default value used. Default value used. to respective error
tables.
( SQL includes column. SQL includes column. SQL includes column. SQL includes column.
Satisfi
es
const
raint)
(Fails HDR/DTL relationship Constraints fail. HDR/DTL relationship Constraints fail.

const to respective error to respective error
raint) tables. tables.


table
Insert with ignore_null = Y Insert with ignore_null = N
colum
HDR/DTL relationship HDR/DTL relationship
to respective error to respective error
tables. tables.
Satisfi
es
const
raint)


table
colum
HDR/DTL relationship HDR/DTL relationship
to respective error to respective error
tables. tables.
Satisfi
es
const
raint)



table
colum
SQL ignores column. SQL ignores column. SQL ignores column. SQL ignores column.
Default value used. Default value used. NULL value used. NULL value used.
Satisfi
es
const
raint)

Interf
ace
table Expected “where” clause, based on IGNORE_NULL and DeleteUnSuccessfulHdrDtl
colum parameter values for each data flow.
n
value
DeleteUnsuccessful DeleteUnsuccessful DeleteUnsuccessful DeleteUnsuccessful
HdrDtl=on HdrDtl=off HdrDtl=on HdrDtl=off
SQL ignores column. SQL ignores column. SQL ignores column. SQL ignores column.
Default value used. Default value used. NULL value used. NULL value used.
Satisfi
es
const
raint)



table
colum
NULL value used. NULL value used. NULL value used. NULL value used.
Satisfi
es
const
raint)


table
colum
NULL value used. NULL value used. NULL value used. NULL value used.
Satisfi
es
const
raint)



Platform 2018.1.0.0 Interface Generation Program Reference Guide

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Platform 2018.1.0.0 Interface Generation Program Reference Guide

Загружено:

Авторское право:

Доступные форматы

Interface Generation

Program Reference Guide

Copyright © 1996-2018 JDA Software Group, Inc. All rights reserved.

Chapter 1. Interface Generation Program

l Interface tables that stage inbound data for processing

l Triggers that invoke IGP-generated stored procedures

l Error tables that capture failed records

l Jobs table that captures Job ID processing data

If you are installing a JDA application that uses the IGP

If you customize or develop an IGP implementation

JDA Interface Generation Program Reference Guide 1

[-u] Optional. Returns a list of currently connected

<user> Specifies username for RDBMS.

<password> Specifies password for user on RDBMS.

<xml_file> Specifies the application-specific XML

JDA Interface Generation Program Reference Guide 2

[<TABLENAME>] Optional and used only when creating

l Parses the XML configuration file.

JDA Interface Generation Program Reference Guide 3

l Sets up error handling.

JDA Interface Generation Program Reference Guide 4

Return code igpjobmanager Rename utility igpjobmanager Status utility

l Renames the job ID in the "INTJOBS table" (on page 19).

Tracing and logging properties

JDA Interface Generation Program Reference Guide 5

Database connection property (required)

JDA Interface Generation Program Reference Guide 6

Initial trigger state properties

In the following example:

Delete unsuccessful header/detail property

Pre and post-processing properties

JDA Interface Generation Program Reference Guide 7

Additional property file property

JDA Interface Generation Program Reference Guide 8

l Interface table UDCs:

l Do not map to columns in the target tables.

l Do not support column constraints.

l Do support DEFAULT and NOT NULL attributes for a column.

l Are ignored by the generated stored procedure, unless specified as selectable.

l Can be included in the select statement of the IGP-generated stored procedure.

l Cannot be renamed with a short column name, if selectable.

Two properties in the IGPProperty.properties facilitate use of UDCs:

Row-level pre and post-processing properties

JDA Interface Generation Program Reference Guide 9

Override row-level processing properties

l <APPNAME>.<TABLENAME>.<OPERATION>.ROWOVERRIDE. TOTALPARAMS = <number_of_

JDA Interface Generation Program Reference Guide 10

Detailed error procedure properties

Effects of setting detailed error procedure properties

DetailedErrorProcI on on off off

DisplayFirstConstra on off on off

JDA Interface Generation Program Reference Guide 11

schemaOwner property facilitates a shielded environment

JDA Interface Generation Program Reference Guide 12

Create a schemaOwner-supported shielded environment

2. Run igpinit.cmd from the application schema.

3. Run the IGP from the igpuser schema, as follows:

igp <igpuser> <password> <xml_filename> <APPNAME> [<TABLENAME>]

l igpuser/password connect to an igpuser schema, which is not the application schema.

l xml_filename is the XML configuration file for the application.

JDA Interface Generation Program Reference Guide 13

Storage clause assignment

XML configuration view tables

JDA Interface Generation Program Reference Guide 14