Configuration of interface.cfg

In RAP Integration, data from all pre-defined planning interfaces to external systems such as RMF CS or internal systems such as RI/Science must be pulled via importers from the RDX schema. Any data that is going from Planning to external systems can also be exported via exporters to the RDX schema. Although interface tables in the RDX schema are fixed or do not change very frequently, as defined by the interface contracts between respective applications, the planning/forecast application that is implemented on PDS supports extensibility and EE configuration. Because of this, it should have configurable/flexible importers and exporters to configure for all available metrics from the RDX schema tables since dimensions/fact names can be different for an EE customer. This is handled through the use of the interface.cfg file (interface configuration file). It is a free-form text file similar to the batch control file, and contains the mapping of dimension/facts in PDS to columns mapped to external tables for each interface.

Figure 1-1 Interface.cfg

Description of "Figure 1-1 Interface.cfg"

Both importers/exporters can be commonly referred as interfaces within PDS, with an unique interface ID for each interface. Interfaces are classified as follows: dimension importers (H), data importers (I), and data exporters (E). Table 1-2 shows the pre-defined list of interfaces that are available for the customers in a RAP integration; there may be more application-specific interfaces. Customers can create or modify entries only for the available list of interfaces. They can configure the interface to match and import the required dimension/fact data based on the dimension/fact names configured within their application when those interfaces are executed in batch. For GA applications, a pre-configured interface.cfg file is available and the customer can customize it for any further extensibility changes, similar to an EE customer.

For most of the interfaces, the external interface table name is the same as the interface name; however, for few interfaces that require derived data from other interface tables, pre-defined views are created and columns from those views are used to obtain the data. Interfaces can be defined to only import/export to one external interface table/view. In Table 1-3, the External View Name column is populated only for interfaces that use internal views. Source tables used to define the view are specified within brackets if it is different than the interface name. The incremental flag Y indicates that the interface is incremental in nature; that is, for each interface run it obtains only the changed data, compared to the previous run of the interface. However, if the incremental flag is N, the interface always obtains a full set of data for each run. All hierarchy interfaces are complete-extract interfaces in order to obtain the latest data available in other applications and so keep all integrating applications synchronized. Refer to the application-specific Implementation Guides for more details about the list of columns available and used for the import or export for each interface.

Table 1-2 List of Pre-Defined Interfaces

Interface Name	Interface Description	Importer Type	Interface Source/Destination	External View Name	Incremental
RSE_FCST_DMD_EXP	Forecast Interface from Science	I	RSP		Y
W_PDS_SLS_IT_LC_WK_A	Sales Interface	I	RI		Y
W_PDS_INV_IT_LC_WK_A	Inventory Interface	I	RI		Y
W_PDS_MKDN_IT_LC_WK_A	Markdown Interface	I	RI		Y
W_PDS_PO_ONORD_IT_LC_WK_A	On Order Interface	I	RI		Y
W_PDS_INVRC_IT_LC_WK_A	Receipts Interface	I	RI		Y
W_PDS_INVADJ_IT_LC_WK_A	Inventory Adjustments	I	RI		Y
W_PDS_INVTSF_IT_LC_WK_A	Inventory Transfers	I	RI		Y
W_PDS_DEALINC_IT_LC_WK_A	Deal Incomes	I	RI		Y
W_PDS_SLSWF_IT_LC_WK_A	Wholesale/Franchise	I	RI		Y
W_PDS_EXCH_RATE_D	Currency Conversion Rates	I	RI	VW_CURR_RATE	N
VW_LOC_DATA	Location Data	I	RI	VW_LOC_DATA	N
W_PDS_PRODUCT_D	Product Hierarchy	H	RI		N
W_PDS_ORGANIZATION_D	Location Hierarchy	H	RI		N
W_PDS_CALENDAR_D	Calendar Hierarchy	H	RI	VW_CLND_HIER	N
VW_CURR_HIER	Currency Hierarchy	H		VW_CURR_HIER(W_PDS_EXCH_RATE_D)	N
MFP_PLAN1_EXP	Merch Plan Export from MFP to RI	E			N
MFP_PLAN2_EXP	Merch Target Plan Export from MFP to RI	E			N
MFP_PLAN3_EXP	Location Plan Export to from MFP to RI	E			N
MFP_PLAN4_EXP	Location Target Plan Export from MFP to RI	E			N

Interface Mappings

Each interface can have a configuration specification defined as the interface mapping that provides details about the mapping of the source table columns and the destination. It can be provided by the customer as the configuration file interface.cfg, which is loaded into an internal interface mapping table. It can be used by generic importer/exporter packages to transfer data when those interfaces are executed in the batch. Table 1-3 provides a list of entries in the interface mapping table (RP_G_INTF_MAPPING_MD).

Table 1-3 Interface Mappings

Column	Description	Purpose	Example
INTF_MAP_NAME<INTERFACE_NAME>	Interface name	Actual interface name for which the mapping is defined	W_PDS_SLS_IT_LC_WK_A
INTF_MAP_PARAM<PARAM>	Interface parameter name	Grouping within that interface. Can be App Name or, within an application, a different set of data to process for that interface, based on this parameter.	MFP
INTF_MAP_TYPE<TYPE>	Interface parameter type	Type of mapping. Can be dimension mapping or data mapping or filter criteria for the mapping. Valid Interface Mapping types vary, based on the type of interface.	DIM01 / DATA
INTF_MAP_RPAS<INTERNAL_NAME>	Interface mapping column from PDS (RPASCE)	Dimension or fact name from PDS, based on the mapping type.	WEEK / DRTYSLSREGU
INTF_MAP_EXTERNAL<EXTERNAL_NAME>	Interface mapping column from external table (source or destination table)	Column name from external interface table.	NET_SALES_REG_UNITS
INTF_MAP_VALUE<VALUE>	Interface mapping value or constant	Can be a hard-coded constant value to use if mapping is not provided. It can be used for FILTER Type entries. It can also be a scalar measure specified with prefix @.

Syntax for Interface Mappings

This section provides the syntax for interface mappings in the interface.cfg file.

<INTERFACE_NAME> : <PARAM> : <TYPE> : <INTERNAL_NAME> : <EXTERNAL_NAME> : <VALUE>

Here are the details for the entries.

<INTERFACE_NAME> - The name of interface

<PARAM> - Parameter grouping can be App Name or any internal grouping name. It must have a different value only if the same interface is used to import/export different levels of data, based on different criteria.

<TYPE> - For data importers/exporters, DIMxx (xx 01,02,03) for dimension mapping. DIM01 is reserved for the Calendar dimension. DATA for data mapping. FILTER for optional filter criteria. FILTER or FILTER_EQ used for equal (=) operator. It also allows FILTER_NE (<>) ,FILTER_GT (>), FILTER_GE (>=), FILTER_LT (<), FILTER_LE (<=)(<=),FILTER_LK (Like), FILTER_NL (Not Like) as different filter types. More than one filter entries can be used, but they all use the AND operation of the filter.

<TYPE> - For hierarchy/dimension importers, HDMxx (xx 01,02,03) for dimension mapping for all dimensions from a single hierarchy, HDLxx for dimension label mappings, FILTER* for optional filter criteria.

<INTERNAL_NAME> - For data importers/exporters, internal dimension/fact name. It must be dimension name for DIMxx type and fact name for DATA type entries.

<INTERNAL_NAME> - For hierarchy/dimension importers, hierarchy dimension column from a single hierarchy,it is required only for HDMxx type entries.

<EXTERNAL_NAME> - Mapping column from external interface table for dimension, data, or filter types.

<VALUE> - Constant value to use for mapping if column mapping not present. Also constant value to use for FILTER criteria. It can also be a scalar measure specified with prefix @. If this value is provided for hierarchy importer types, it will be used as the prefix for dimension or labels

Multiple entries for same interface are required to completely define all the required mappings for an interface.

Example for Data Importer Interface

Entries for data importer interfaces are displayed as follows:

<INTERFACE_NAME : <PARAM> : DIMxx : <DIM_NAME> : <EXTERNAL_COLUMN> :

<INTERFACE_NAME> : <PARAM> : DATA : <FACT_NAME> : <EXTERNAL_COLUMN> :

<INTEFACE_NAME> : <PARAM> : FILTER : : <EXTERNAL_COLUMN> : <FILTER_VALUE>

Example:

W_PDS_SLS_IT_LC_WK_A: MFP: DIM01 : WEEK : EOW_DATE

W_PDS_SLS_IT_LC_WK_A: MFP: DIM02 : SKU : ITEM_ID

W_PDS_SLS_IT_LC_WK_A: MFP: DIM03 : STOR : LOCATION_ID

W_PDS_SLS_IT_LC_WK_A: MFP: DATA : DRTYNSLSREGU : NET_SALES_REG_UNITS

W_PDS_SLS_IT_LC_WK_A: MFP: DATA : DRTYNSLSREGC : NET_SALES_REG_COST

W_PDS_SLS_IT_LC_WK_A: MFP: DATA : DRTYNSLSREGR : NET_SALES_REG_RETAIL

W_PDS_SLS_IT_LC_WK_A: MFP: DATA : DRTYRTNREGU : RETURNS_REG_UNITS

W_PDS_SLS_IT_LC_WK_A: MFP: DATA : DRTYRTNREGC : RETURNS_REG_COST

W_PDS_SLS_IT_LC_WK_A: MFP: DATA : DRTYRTNREGR : RETURNS_REG_RETAIL

W_PDS_SLS_IT_LC_WK_A: MFP: DATA : DRTYNSLSCLRU : NET_SALES_CLEAR_UNITS

W_PDS_SLS_IT_LC_WK_A: MFP: DATA : DRTYNSLSCLRC : NET_SALES_CLEAR_COST

W_PDS_SLS_IT_LC_WK_A: MFP: DATA : DRTYNSLSCLRR : NET_SALES_CLEAR_RETAIL

W_PDS_SLS_IT_LC_WK_A: MFP: DATA : DRTYRTNCLRU : RETURNS_CLEAR_UNITS

W_PDS_SLS_IT_LC_WK_A: MFP: DATA : DRTYRTNCLRC : RETURNS_CLEAR_COST

W_PDS_SLS_IT_LC_WK_A: MFP: DATA : DRTYRTNCLRR : RETURNS_CLEAR_RETAIL

Example for Data Exporter Interface

Entries for data exporter interfaces are displayed as follows:<INTERFACE_NAME> : <PARAM> : DIMxx : <DIM_NAME> : <EXTERNAL_COLUMN> :

<INTERFACE_NAME> : <PARAM> : DATA : <FACT_NAME> : <EXTERNAL_COLUMN> :

<INTEFACE_NAME> : <PARAM> : FILTER : <FACT_NAME> : :<FILTER_VALUE>

The following example shows a sample generic exporter that obtains data from different facts of same base intersection and imports data into same table for different versions (MPCP and MPOP) of the plan. This is controlled by using a different PARAM for each different version of the data.

MFP_PLAN1_EXP:MPOP:DIM01:WEEK:CLND_KEY:

MFP_PLAN1_EXP:MPOP:DIM02:SCLS:PROD_KEY:

MFP_PLAN1_EXP:MPOP:DIM03:CHNL:LOC_KEY:

MFP_PLAN1_EXP:MPOP:DATA::PROD_DH_ATTR:@MFP_DRDVDPOST

MFP_PLAN1_EXP:MPOP:DATA::SUPPLIER_NUM:@MFP_DRDVDPOST

MFP_PLAN1_EXP:MPOP:DATA::VERSION_NUM:0

MFP_PLAN1_EXP:MPOP:DATA:MPOPLDOWD:CAL_DATE:

MFP_PLAN1_EXP:MPOP:DATA:MPOPSLSU:SLS_QTY:

MFP_PLAN1_EXP:MPOP:DATA:MPOPSLSR:SLS_RTL_AMT:

MFP_PLAN1_EXP:MPOP:FILTER:MPOPEXPORTB::TMFP_PLAN1_EXP:MPCP:DIM01:WEEK:CLND_KEY:MFP_PLAN1_EXP:MPCP:DIM02:SCLS:PROD_KEY:MFP_PLAN1_EXP:MPCP:DIM03:CHNL:LOC_KEY:MFP_PLAN1_EXP:MPCP:DATA::PROD_DH_ATTR:@MFP_DRDVDPOSTMFP_PLAN1_EXP:MPCP:DATA::SUPPLIER_NUM:@MFP_DRDVDPOSTMFP_PLAN1_EXP:MPCP:DATA::VERSION_NUM:1MFP_PLAN1_EXP:MPCP:DATA:MPCPLDOWD:CAL_DATE:MFP_PLAN1_EXP:MPCP:DATA:MPCPSLSU:SLS_QTY:MFP_PLAN1_EXP:MPCP:DATA:MPCPSLSR:SLS_RTL_AMT:MFP_PLAN1_EXP:MPCP:FILTER:MPCPEXPORTB::T

Example for Hierarchy/Dimension Importer Interface

Hierarchy importers are similar to importers. However, the dimension mapped belong to the same hierarchy. Each hierarchy dimension can also contain the corresponding mapping for labels. The new mapping type entries differentiate an interface as a hierarchy importer interface.

Note:

If the mapping is for an alternate level that is loaded via flat file and there is no mapping available inthe External Interface table for the alternate level, then default value can provided as NA or na. In this scenario, the current position name, if it already exists, is not overwritten. However, for a new value, the position name will be added as <level>_<number>, where <level> is the level name that is the alternate level here and <number> is an integer starting with 0. If the default value provided is not NA or na, then the position name will be saved as the default value provided.

The following two mappings are used instead of DIMxx and DATA type mappings.

<INTERFACE_NAME> : <PARAM> : HDMxx : <DIM_NAME> : <EXTERNAL_DIM_COLUMN> : <OPTIONAL_PREFIX_VALUE>

<INTERFACE_NAME> : <PARAM> : HDLxx : : <EXTERNAL_LABEL_COLUMN> : <OPTIONAL_PREFIX_VALUE>

<INTEFACE_NAME> : <PARAM> : FILTER : : <FILTER_SOURCE_COLUMN> : <FILTER_VALUE>

The following is an example entry for hierarchy importers.

W_PDS_CALENDAR_D:PDS:HDM01:DAY:DAY:

W_PDS_CALENDAR_D:PDS:HDM02:WEEK:WEEK:

W_PDS_CALENDAR_D:PDS:HDM03:MNTH:MNTH:

W_PDS_CALENDAR_D:PDS:HDM04:QRTR:QRTR:

W_PDS_CALENDAR_D:PDS:HDM05:HALF:HALF:

W_PDS_CALENDAR_D:PDS:HDM06:YEAR:YEAR:

W_PDS_CALENDAR_D:PDS:HDM07:WOYR:WOYR:

W_PDS_CALENDAR_D:PDS:HDM08:HLDY::NA

W_PDS_CALENDAR_D:PDS:HDM09:EVNT::NA

W_PDS_CALENDAR_D:PDS:HDM10:STDB:STDB:

W_PDS_CALENDAR_D:PDS:HDL01::DAY_LABEL:

W_PDS_CALENDAR_D:PDS:HDL02::WEEK_LABEL:

W_PDS_CALENDAR_D:PDS:HDL03::MNTH_LABEL:

W_PDS_CALENDAR_D:PDS:HDL04::QRTR_LABEL:

W_PDS_CALENDAR_D:PDS:HDL05::HALF_LABEL:

W_PDS_CALENDAR_D:PDS:HDL06::YEAR_LABEL:

W_PDS_CALENDAR_D:PDS:HDL07::WOYR_LABEL:

W_PDS_CALENDAR_D:PDS:HDL08:::Unassigned

W_PDS_CALENDAR_D:PDS:HDL09:::Unassigned

W_PDS_CALENDAR_D:PDS:HDL10::STDB_LABEL:

Process for Uploading New interface.cfg File

A customer can upload a new interface.cfg file using the OAT task Load Interface Mappings. Before executing this task, the customer must upload the interface.cfg file to the object store using the naming convention incoming/config/interface.cfg and then execute that task.

The upload process does basic validation for entries in interface.cfg, verifying that the correct parameters are used and the interface column mappings are valid both in the application and in the external table sources. If the validation fails, it will provide details about the errors in the log and restore the previous interface.cfg file. If the validation is successful, it will upload the new interface.cfg configuration file and subsequent interface execution calls will use the new interface.cfg file.