This chapter discusses implementing integrations.
Setting up service operations
Setting up chunking
Setting up electronic data collections
Setting up BackBone Interlinks
Setting up XML Mapper
PeopleSoft is delivered with many enterprise integration points (EIPs) to send and receive data with a third-party system or another PeopleSoft application, such as CRM. These EIPs are implemented using service operations within PeopleSoft Integration Broker. The instructions in this section describe the steps necessary to enable service operations.
See Scenarios for Integration With PeopleSoft Supply Chain Management.
Note. Your database administrator will need to assist you with this setup.
Understanding Inbound EIPs
PeopleSoft Integration Broker can receive data from a third-party system or another PeopleSoft system, such as CRM. The inbound data can have the following data formats:
An XML file that uses the PeopleSoft format.
This XML file could be generated by another PeopleSoft system, generated by a third-party system in this PeopleSoft XML format, or generated by a third-party system and then converted to the PeopleSoft XML format by a middleware product. Once received by your PeopleSoft system, the inbound data is placed in the message queue, checked for errors and then moved to the inbound staging tables to be processed by the individual PeopleSoft application.
A flat file that uses the PeopleSoft format.
This file could be generated by a third-party system in this PeopleSoft format or generated by a third-party system and then converted to the PeopleSoft format by a middleware product. A flat file could also come from another PeopleSoft system. The PeopleSoft Integration Broker uses transforms to convert the data from a flat file to an XML file also using the PeopleSoft format. The inbound data is then placed in the message queue, checked for errors, and then moved to the inbound staging tables to be processed by the individual PeopleSoft application.
A flat file using an EDI X.12 format.
This file could be generated by a third-party system in this EDI X.12 flat file format or generated by a third-party system and then converted to the EDI X.12 flat file format by a middleware product. An EDI flat file could also come from another PeopleSoft system. Once received by your PeopleSoft system, the PeopleSoft Integration Broker uses transforms to convert the data from a flat file to an XML file and then from EDI X.12 format to the PeopleSoft format. The inbound PeopleSoft-formatted XML data is then placed in the message queue, checked for errors, and then moved to the inbound staging tables to be processed by the individual PeopleSoft application.
An XML file using an EDI X.12 format.
This file could be generated by a third-party system in this EDI X.12 XML format or generated by a third-party system and then converted to the EDI X.12 XML format by a middleware product. An EDI XML file could also come from another PeopleSoft system. Once received by your PeopleSoft system, the PeopleSoft Integration Broker uses transforms to convert the data from EDI X.12 format to the PeopleSoft format. The inbound PeopleSoft-formatted XML data is then placed in the message queue, checked for errors, and then moved to the inbound staging tables to be processed by the individual PeopleSoft application.
Note. Standard X.12 transaction definitions are predefined in PeopleSoft along with examples of transformation rules for selected X.12 transactions. Individual trading partner specifications will vary so customizations are required for each transaction or trading partner variation.
Understanding Outbound EIPs
PeopleSoft Integration Broker can send data to a third-party system or another PeopleSoft system, such as CRM using the following data formats:
An XML file that uses the PeopleSoft format.
PeopleSoft can generate a PeopleSoft-formatted XML file to be received by another PeopleSoft system, such as CRM, or a third-party system with or without conversion by a middleware product.
A flat file that uses the PeopleSoft format.
PeopleSoft can generate a PeopleSoft-formatted XML file that is converted, by PeopleSoft Integration Broker, into a PeopleSoft-formatted flat file. This flat file can be received by a third-party system or processed by a middleware product and then received by a third-party system.
A flat file using an EDI X.12 format.
PeopleSoft can generate a PeopleSoft-formatted XML file that is converted, by PeopleSoft Integration Broker, using two transforms (Application Engine programs). The data is first converted into the EDI X.12 format and then from XML to flat file format.
An XML file using an EDI X.12 format.
You do not have to use a flat file for EDI formatted data. As delivered, the PeopleSoft Integration Broker converts the PeopleSoft-formatted XML data into a EDI X.12 formatted flat file using transform programs; first by converting to an EDI XML format and then to a flat file format. However, you can change the system to output EDI X.12 data in an XML format by removing the second transform program.
Note. Standard X.12 transaction definitions are predefined in PeopleSoft along with examples of transformation rules for selected X.12 transactions. Individual trading partner specifications will vary so customizations are required for each transaction or trading partner variation.
Setup Within PeopleSoft Integration Broker
To activate a service operation, complete the following steps in PeopleSoft Integration Broker:
Activate the service operation.
On the General tab of the Service Operations component, select the Active check box for the applicable service operation version. If the desired version is not the default version for the service operation, the default version must also be activated.
For asynchronous service operations only, verify the queue is running.
On the General tab of the Service Operations component, select the View Queue link at the bottom of the page. On the Queue Definitions page, verify the Queue Status field has a value of Run.
Activate the service operation handlers.
Note. This step does not apply to all service operations.
On the Handlers tab of the Service Operations component, select the value of Active in the Status field for all needed handlers.
For inbound asynchronous service operations, activate the OnNotify handler.
For inbound synchronous service operations, activate the OnRequest handler.
If you are using chunking on an outbound service operation, activate the OnRoute handler.
Activate the service operation routings.
On the Routings tab of the Service Operations component, activate a routing definition for each node that will send or receive data. To activate a routing, select the check box next to the routing definition and click the Activate Selected Routings button.
Activate an inbound routing to receive data into PeopleSoft SCM.
Activate an outbound routing for sending data to a third-party system or another PeopleSoft product, such as CRM.
Activate a local routing for sending data using an effective-dated outbound service operation.
Activate a local routing to receive inbound flat files.
You must activate at least one routing if the data is being sent in an XML format.
You can skip this step if a batch publish rule is set up to post to a flat file only.
Verify the routing definition parameters.
On the Routings tab of the Service Operations component, select the link attached to the routing definition name. This link accesses the Routing Definitions component. Select the Parameters tab and complete the following steps:
Confirm the external alias name in the External Alias field for the routing is correct. When sending or receiving data, the Integration Broker determines which routing to use by referring to the external alias name, not the routing name.
Add or verify the transform programs on this routing definition. A routing definition defines the sending and receiving nodes for a transaction and specifies any inbound and outbound transformations to invoke. A transform program is a type of PeopleSoft Application Engine program that can convert data from one format to another; for example, from XML to a flat file. Use a transform program when one node sends a request or response message with a data structure different from the structure required by the other node. Many pre-defined routings are delivered with transform programs. You must decide, based on your unique situation, to change, remove, and add transform programs. For example, some delivered transform programs convert data to the EDI format, if you are not using EDI then you will want to use a different routing definition or remove that transform program from the routing definition.
Verify the node from the routing is active.
Go to the Node Definitions page and verify the Active Node check box has been selected for any sender or receiver nodes used in the routings that you activated on your Service Operations-Routings page.
For an outbound service operation, verify the node or routing is connected to the correct network.
For inbound service operations using a flat file, define the inbound file rule and run control parameters:
For X.12 formatted EDI files, use the Inbound File Loader Rules page and the Inbound File Processing run control under the Integration Broker menu.
For PeopleSoft formatted files, use the File Inbound page and the Inbound File run control under the Enterprise Components menu.
Setup Within PeopleSoft Enterprise Components
To activate chunking, inbound file rules, batch publish rules, or full publish rules for a service operation, complete the following steps in PeopleSoft Enterprise Components:
Setup the publish utility.
If the outbound EIP is sending (publishing) data using the publish utility, setup full or batch data publishing.
The full publish utility automates the process of copying the contents of an entire table into another database or third-party system. You can use the utility to synchronize data between systems. The publishing rules include pages for full table publishing rules, batch publishing rules, record mapping, languages, and batch programs.
Setup for full or batch data publishing using the Full Data Publish Rules component or the Batch Publish Rules component. On both of these components, the Message Name field is the service operation. Complete the following tasks:
Activate the rule by selecting the value of Active for the Status field.
Specify the desired output (XML-based message or flat file).
If you want to use chunking select a Chunking Rule ID. The outbound data will be sent to the nodes specified by the chunking rule.
If you have more than one publish rule defined for a service operation, you should activate a rule for each batch program. For example, item status change, Item Revisions, and Item Loader each have unique rules for the ITEM_SYNC service operation, so three rules must be activated for ITEM_SYNC.
For outbound asynchronous service operations using chunking, activate and configure the appropriate chunk rule mapping definitions. For instance, use the BusUnit Mapping component (EO_CHUNKBU) to configure the BUSINESS_UNIT chunk rule.
See Setting Up Chunking.
Setup the inbound file rules in order to used the inbound file publish utility.
When external systems send flat files, use the inbound file publish utility to translate the incoming data into transactions that are acceptable to your PeopleSoft system. Use the Inbound File Rules page to define the file, file layout, service operation, and other parameters to accept the inbound file.
See Also
Enterprise PeopleTools PeopleBook: Integration Broker
Page Name |
Definition Name |
Navigation |
Usage |
IB_SERVICE |
PeopleTools, Integration Broker, Integration Setup, Service Operations, General |
Define and activate a service operation. |
|
IB_SERVICEHDLR |
PeopleTools, Integration Broker, Integration Setup, Service Operations, Handlers |
Activate one or more service operation handlers. |
|
IB_SERVICERTNGS |
PeopleTools, Integration Broker, Integration Setup, Service Operations, Routings |
Define and activate routing definitions on the service operation. |
|
IB_QUEUEDEFN |
|
Activate the queue used by the service operation. |
|
IB_ROUTINGDEFNDOC |
|
Verify the external service alias names used by this routing. |
|
IB_NODE |
PeopleTools, Integration Broker, Integration Setup, Nodes, Node Definitions |
Activate node used by the service operation. |
|
IB_NODECONN |
PeopleTools, Integration Broker, Integration Setup, Nodes, Connectors |
For an outbound service operation, verify the node is connected to the correct network. |
|
EO_MSGPUBFULL |
Enterprise Components, Integration Definitions, Full Data Publish Rules |
Activate the full data publish rule for the service operations using the full data publish rules. |
|
EO_MSGPUBATCH |
Enterprise Components, Integration Definitions, Batch Publish Rules |
Activate the batch publish rule for the service operations using the batch publish utility. |
|
EO_FILE_INBOUND |
Enterprise Components, Integration Definitions, Inbound File Rule |
Define the parameters to receive inbound flat files from third-party systems. |
See Also
Enterprise PeopleTools PeopleBook: Integration Broker
If you are sending outbound data using a service operation in Integration Broker, you may want to set up chunking. When chunking, the system automatically breaks up the outbound transaction into several smaller transactions based on the values in one or more of the fields in the level zero record of the message. The message identifies the records and fields to be sent and is tied to the service operation. For example, if you want to chunk by the business unit field of the message, the outbound transaction would be broken up by business unit sending each business unit's outbound data to a node that you have defined. Another example would be for sites sending EDI transactions directly to trading partners. If you are sending purchase orders directly to a vendor, make sure that the vendor gets only their information. Chunking provides the ability to split a batch of purchase orders into separate transactions based on the trading partner. The Integration Broker then provides tools to route the transactions to specific nodes based on that trading partner identification, in this case the vendor ID.
See Understanding Electronic Data Interchange.
Note. If you are using a middleware product to transform and route transactions to trading partners then you most likely will not need to use chunking. The entire outbound transaction would go to the node defined for the middleware product.
Chunking is implemented using the Batch Publish Utility or the Full Data Publish Utility. In either case a batch publish rule is created and a chunking rule can be attached. The chunking rule defines a table containing a set of values that map to specific nodes. For example, in the above example where you are chunking by vendor ID, the chunking rule table would contain a set of vendor IDs that map to individual nodes for trading partners receiving the purchase order data.
The following is a step by step explanation of the process flow of an outbound transaction using chunking:
Chunking Selection
The run process that generated the transaction. This may be the Full Data Publish Utility or one of the batch based service operations that use the Batch Publish Utility.
Note. All transactions generated from the Publish Outbound Messages process page use the Batch Publish Utility.
When the batch publish or full data publish utilities run they recognize the chunking rule assigned to the publish rule and split the data into separate XML files for each chunking rule value. The XML files are then published to the Integration Broker.
Chunking Node Routing
The Integration Broker makes the decision of which node will receive each XML file. Standard processing for the Integration Broker will send the outbound data to all of the nodes that have active outbound routings on the service operation. When chunking is used, the Integration Broker needs to send the outbound transaction only to the nodes specified by the chunk rule. This is done by activating the ROUTERSENDHDLR handler on the Service Operations-Handlers page. This handler is an OnRoute application class containing PeopleCode that directs the Integration Broker to only send the outbound data to the nodes that you have defined for the specific chunking rule.
PeopleSoft provides a number of chunking rules, chunking rule tables, and data entry pages that can be used to maintain node mappings and routing rules for some of the more commonly used field values. The data entry pages are noted in the Pages Used to Set up Chunking table below. Additional setup information is provided in the PeopleSoft Enterprise Components PeopleBook explaining how to create your own customized chunking rule, chunking rule table and data entry pages.
See Also
Enterprise PeopleTools PeopleBook: Integration Broker
Scenarios for Integration With PeopleSoft Supply Chain Management
Page Name |
Definition Name |
Navigation |
Usage |
EO_ADNODECHUNK_PNL |
Enterprise Components, Integration Definition, Map Chunking Rules, Node to ChunkRule, Add Nodes to Chunk Rule |
Map nodes by Chunk Rules. |
|
EO_CHUNKBU |
Enterprise Components, Integration Definition, Map Chunking Rules, Business Units, BusUnit Mapping |
Maintain ChunkRule business unit mapping. |
|
EO_ADDBUNODE_PNL |
Enterprise Components, Integration Definition, Map Chunking Rules, BU to ChunkRule/Node, Quick Map |
Map business units by ChunkRules or nodes. |
|
EO_ADDNODEBU_PNL |
Enterprise Components, Integration Definition, Map Chunking Rules, ChunkRule/Node to BU, Map Business Unit |
Map ChunkRules or nodes by business unit. |
|
EO_CHUNKSETID |
Enterprise Components, Integration Definition, Map Chunking Rules, Setids, Setid Mapping |
Maintain ChunkRule setID mapping. |
|
EO_ADDSIDNODE_PNL |
Enterprise Components, Integration Definition, Map Chunking Rules, Setid to ChunkRule/Node, Quick Map |
Map setIDs by ChunkRules or nodes. |
|
EO_ADDNODESID_PNL |
Enterprise Components, Integration Definition, Map Chunking Rules, ChunkRule/Node to Setid, Map Set IDs |
Map ChunkRules by setID. |
|
OM_CHUNKCUSTID |
SCM Integrations, Chunking Rule, CustID to Node Mapping, Customer ID Chunk |
Map customer chunk rule and node to customer ID. |
|
IN_CHUNKBULOCATION |
SCM Integrations, Chunking Rule, BU/Loc to Node Mapping, BU/Location Node Mapping |
Map business units chunk rule and node to location codes. |
|
IN_CHUNKBUPARLOC |
SCM Integrations, Chunking Rule, BU/Par to Node Mapping, BU/Par Location Node Mapping |
Map business unit and par location chunk rule and node to par location ID. |
|
PO_CHUNK_VENDOR |
SCM Integrations, Chunking Rule, Manage ChunkRule VendorID Map, Setup Vendor to Node |
Set up vendor chunk rule and node to vendor ID and vendor location. |
|
PO_CHUNK_SHIPTO |
SCM Integrations, Chunking Rule, Ship to Loc to Node Mapping, PO Chunk Shipto |
Set up ShipTo chunk rule and node to Ship To Location. |
|
OM_CHUNK_SRC_CD |
SCM Integrations, Chunking Rule, Source Code to Node Mapping, Source Code Chunk |
Set up source code chunk rule and node to source codes. |
This section discusses setting up electronic data collections.
Page Name |
Definition Name |
Navigation |
Usage |
BCT_SETUP_FS |
SCM Integrations, Setup, Data Collection, Data Collection Setup |
Set up electronic data collection defaults. |
To enter defaults for inbound transactions, use the Bar Code Transaction Setup component.
Access the Data Collection Setup page (SCM Integrations, Setup, Data Collection, Data Collection Setup).
Transaction Number |
The last transaction number used in the transaction log appears. The system uses the transaction number to automatically generate a unique number for each transaction added to the transaction log from the transaction pages. System-generated transactions also use this field. |
History Options |
Determines whether a history of the transactions is saved when you run the Purge process (INPYPURG) on the transactions in the transaction log. Options are: History for all Transactions: The system maintains a history of all transactions in the transaction log. History only for Errors: The system maintains a history only for transactions that have errors or warnings. No history will be maintained: The system doesn't maintain a history for any transactions in the transaction log. |
Status of Records to Purge |
Determines which records the system purges when you run the Purge process. Options are: Complete: All rows for the transaction are either canceled or successfully processed. Confirmed: Purges only rows set to a confirmed status. This entry should be selected only if you have modified the interacting system to set the status of transactions to confirmed after making sure that the PeopleSoft system has processed the transaction to a complete status. |
File Suffix |
Used as the suffix for the file name of the label extraction file, when a format ID is not specified on the label generation page. |
Note. If your interacting system is selecting Complete transactions to mark them as being ready to purge, the BCT_STATUS on BCT_CTL should be updated from 2 (complete) to 6 (confirmed).
See Also
Using Electronic Data Collection Transactions
This section provides an overview and discusses BackBone InterlinX Framework.
BackBone InterlinX provide a metadata-driven, generic framework for data synchronization of tables between PeopleSoft databases. This framework enables PeopleSoft data synchronization through a single, metadata-driven EIP, thereby leaving standard EIPs to do their intended purpose of providing integration "services".
The design concepts behind the BackBone InterlinX Framework provide:
A single, generic, metadata-driven EIP for selecting and/or synchronizing data between PeopleSoft databases of varied releases.
A private EIP that does not expose any additional unnecessary EIP contracts to the outside world.
An internal EIP that is not intended for external use and not posted to the ISR for external-use or support.
The ability to synchronize record level data independent of application business logic.
The ability to leverage XSL transformations for data model changes between releases.
BackBone InterlinX provides a simple, metadata-driven, Integration Broker-based solution for data synchronization. In addition, BackBone InterlinX provides data query ("Data Pull") capabilities using XML that are not offered with ETL tools.
The following objects must be activated and configured correctly within the PeopleSoft Integration Broker for the BackBone InterlinX Framework to work:
Service operation SAC_BBIX_MESSAGE.
Message SAC_BBIX_MESSAGE.
Queue SAC_BBIX.
Service operation routings.
Service operation handler INBOUND_SAC_BBIX
Page Name |
Definition Name |
Navigation |
Usage |
SAC_BBIX_TARGETSET |
SCM Integrations, Backbone InterlinX, Define Target Set |
Set up target sets, a logical grouping of target databases for data to be synchronized with the Backbone InterlinX framework. You can enter a list of target databases or Integration Broker Nodes for data to be "pushed" to or "pulled" from in order to define your target sets. |
|
SAC_BBIX_DEFN |
SCM Integrations, Backbone InterlinX, Define Integration |
Set up integrations, a record or group of records that you wish to synchronize with other PeopleSoft databases within the BackBone InterlinX Framework. You can select the data options for integrating with your target databases. |
|
SAC_BBIX_USER_EXIT |
Click the Integration User Exits link on the Integration Definition page |
Set up additional processing to be done before and/or after data is synchronized using the BackBone InterlinX Framework. |
Access the Define Target Sets page (SCM Integrations, Backbone InterlinX, Define Target Set).
Target Set |
Enter an identifier for your target set. |
Node Name |
Enter a PeopleSoft Integration Broker Node with which to synchronize data. Note. Add additional rows for each Node that you wish to integrate with for this target set ID. |
See Also
Enterprise PeopleTools PeopleBook: Integration Broker
Access the Integration Definition page (SCM Integrations, Backbone InterlinX, Define Integration).
Integration ID |
Enter an ID for your integration. |
Active |
Click to indicate that the integration is active. If cleared, the integration is inactive. Inactive integrations will not publish data. |
Processing |
Determines how the integration will be processed. Options include: Standard Mode: Select to enables theProcessing Options group box so that you can execute the integration either from the BBIX Run Control Component or directly from PeopleCode. PeopleCode Only Mode: Select to disables the Processing Options group box so that you can only execute the integration using PeopleCode. |
Data |
Determines the type of data that the integration will synchronize. Options include: Setup Data: Data is synchronized and committed record by record Transaction Data: Data is synchronized and committed based on a parent-child transaction model. When this option is selected, the first record in the Processing Options group box is used as the parent record, and all additional records are used as child records. The system synchronizes data one parent row and all of the corresponding children rows at a time. Each parent row and the children rows is considered a logical transaction. This option is only available with the processing option of Standard Mode. |
Action |
Select to determine whether data is sent to or retrieved from the target sets. Options include: Data Push – Data is sent to the defined target set(s). Data Pull – Data is retrieved from the defined target set(s). This option is only available with the processing option of Standard Mode. |
Processing Options
Import Option |
Select to determine whether date is deleted from tables before synchronization occurs. Options include: Update and Append Only: Data is not deleted from the source or target database(s). The data sent is updated if the record already exists or added if the record does not exist in the target for a "Data Push" or in the source for a "Data Pull". Delete All Record Data: The system deletes date from the source or target database. ALL of the data in the table is deleted in the target for a "Data Push" or in the source for a "Data Pull" before the new data is inserted. Delete Records using Filter: Data is deleted from the source or target database(s) based on the record "filter" that is defined. The data that matches the "filter" condition in the table is deleted in the target for a "Data Push" or in the source for a "Data Pull" before the new data is inserted. This option is only available with the processing option of Standard Mode and Setup Data. |
Record |
Select a table to synchronize. Note. For transaction data, the key values on the parent record must exist in all child records. This option is only available with the processing option of Standard Mode. |
Fields |
Select to determine whether to synchronize all fields on the record or a list of fields. Options include: All Fields: All fields on the record are synchronized. List of Fields: Enables a subset of the fields on the record to be synchronized. When selected, you can create rows and search for each field on the selected record. However, the key fields for a record are always synchronized. Note. If fields are sent in a "Data Push" that do not exist in the target database(s), then these extra fields are ignored. However, if specific fields are selected within a "Data Pull" that do not exist in the target database(s), then data will not be synchronized. |
Filter |
Create a filter or WHERE clause to subset the data to be synchronized. If not entered, then the entire record is used. This field is not required. |
Target Nodes
Target SetID |
Determines the Target Set with which to synchronize the integration. If you don't select at least one Target Set, then the integration will be sent based on the Integration Broker service operation defined for the SAC_BBIX_MESSAGE message. |
Map Set ID |
Enter the map set ID for which you want to map the integration. |
This section provides an overview of XML Mapper and discusses how to set it up.
XML Mapper enables you to map values between your database and an external trading partner database. For example, if you are integrating to a computer hardware vendor, if you use a field called business unit, and the vendor uses a field called BU, you can set up a mapping relationship where your outbound purchase order XML transaction automatically converts data in business unit fields to BU fields.
Before you being using XML Mapper, you must:
Activate service operations set up in Integration Broker.
Set up an integration broker relationship including transaction modifiers for the node associations.
See Also
Enterprise PeopleTools PeopleBook: Integration Broker
Page Name |
Definition Name |
Navigation |
Usage |
SAC_MAP_DEFN |
SCM Integrations, XML Mapper, Define Maps |
Use to define the type of transformation and to which message, records, and fields it applies. |
|
SAC_MAP_DEFN_DTL |
SCM Integrations, XML Mapper, Define Maps, Map Detail |
Use to specify the map type detail. |
|
SAC_MAPSETDEFN |
SCM Integrations, XML Mapper, Define Map Sets |
Use to group maps together, order them, and specify in which directions they apply. |
|
SAC_NODE_ASSOC |
SCM Integrations, XML Mapper, Define Node Associations |
Use to associate a source node and a target node with a map set. All maps in an associated map set will then execute using the node association. Before defining a node association, set up an Integration Broker service operation routings for your nodes. See Enterprise PeopleTools PeopleBook: Integration Broker |
Access the Define Maps page (SCM Integrations, XML Mapper, Define Maps).
Map Type |
Select to specify a map type for this map. The value you select determines the options available on the Map Detail page. Options include: Application Class: maps data using an application class that you specify. Selecting this makes the application class ID and application class path fields available on the Map Detail page. Specify an extension of class SCM_SAC_XMLMAPPER:Maps:MapBase, and be certain the specified class implements method TransformXMLString(). Attribute Value: maps the values associated with a specific XML attribute. Selecting this makes the internal value and external value fields available on the Map Detail page. Field Alias: enables the renaming of fields, such as renaming a field called business unit to BU. Selecting this makes the internal field name and external field name fields available on the Map Detail page. Field Value: enables the revaluing of fields. For example, externally, a business unit could be called NY Operations, internally, it could be called US007. Selecting this makes the internal value and external value fields available on the Map Detail page. Field Value — SQL: maps field values using a SQL object. The SQL objects should return two values: internal value and external value, in that order. Selecting this makes the SQL object identifier field available on the Map Detail page. Record Alias: enables the renaming of records. Selecting this makes the internal record and external record fields available on the Map Detail page. Values Only: sets up a simple list of mapped values that you can use from code. Selecting this makes the internal value and external value fields available on the Map Detail page. Note. This map type is never run automatically. XSL: maps data using XSL that you provide. Selecting this makes the XSL field available on the Map Detail page. |
Map Level |
Select All Messages to apply this map to all active messages, or Specific Message to apply this map to one message only. This option is only available if you select a map type of application class, attribute value, field alias, field value, record alias, or XSL. |
Message |
Enter the specific message to map to if you selected the specific message mapping level. |
Map Match Criteria
Attribute Name |
Enter a name for the attribute. The system displays this field only when you have selected an attribute value map type. |
Criteria |
Enter criteria used to map the data. This is only available if you have selected a field alias, field value, field value — SQL map type. Options include: None: no criteria will be used to map the data other than that found on the Map Detail page. Note. This value is for system use only. You must select a value other than None. Record/Field: to map data by a specified record or field. You can choose All Records, Specific Record, and select a Record, or select a Field. XPath: select to enter an XPath expression that will specify everything BUT the values you would like to map. Additional XPath text will be appended to your XPath based on the values specified on the Map Details page. For example, if A and B are specified as Internal and External values, respectively, the XPath expression //RECORD_NAME/FIELDNAME would become //RECORD_NAME/FIELDNAME/text()[.='A'] for an outbound transaction. If you select this option, enter a Pattern. |
Access the Map Detail page (SCM Integrations, XML Mapper, Define Maps, Map Detail).
Application Class Path |
Specify an extension of class SCM_SAC_XMLMAPPER:Maps:MapBase. Be certain the specified class implements method TransformXMLString(). The system displays this field only when you have selected an application class map type on the Define Map page. |
Application Class ID |
Select a valid application class ID that is available at the specified application class path. The system displays this field only when you have selected an application class map type on the Define Map page. |
Internal Value |
Enter the value you wish to convert to on an inbound transaction or convert from on an outbound transaction. The system displays this field only when you have selected an attribute value, field value, or values only map type on the Define Map page. |
External Value |
Enter the value you wish to convert from on an inbound transaction or convert to on an outbound transaction. The system displays this field only when you have selected an attribute value, field value, or values only map type on the Define Map page. |
Internal Field Name |
Enter the value you wish to convert to an inbound field name or from an outbound field name. The system displays this field only when you have selected a field alias map type on the Define Map page. |
External Field Name |
Enter the value you wish to convert from an inbound field name or to an outbound field name. The system displays this field only when you have selected a field alias map type on the Define Map page. |
SQL Object Identifier |
Select a SQL Object Identifier. The system displays this field only when you have selected a field value — SQL map type on the Define Map page. |
Internal Record Name |
Enter the value you wish to convert to on an inbound record or convert from on an outbound record. The system displays this field only when you have selected a record alias map type on the Define Map page. |
External Record Name |
Enter the value you wish to convert from an inbound record name or to an outbound record name. The system displays this field only when you have selected a record alias map type on the Define Map page. |
XSL |
Enter your own custom XSL transformation. The system displays this field only when you have selected a map type of XSL on the Define Map page. |
Access the Define Map Sets page (SCM Integrations, XML Mapper, Define Map Sets).
Map Set ID |
Create a map set ID to designate each map set. |
Active |
This option must be selected for the XML mapper to complete data transformations. |
Map ID |
Select a Map ID to associate with this map set. You can associate multiple map IDs with a single map set. |
Direction |
Enter the direction for which the selected map should apply. Options include Inbound for inbound transactions, Outbound for outbound transactions, or Both if you want the map set to be used for inbound and outbound transactions. |
Arrows |
Choose the order in which the maps should be run. |
Access the Define Node Associations page (SCM Integrations, XML Mapper, Define Node Associations).
Map Set ID |
Enter a map set ID to use with the source node and target node. |
Arrows |
Choose the order in which the map sets should be run. |