Oracle eCommerce Gateway Overview

The Oracle Gateway resides between the Oracle Applications and the EDI Translator. The Gateway processes data between Oracle Applications and the EDI Translator using ASCII interface flat files. The EDI Translator accommodates the standards and all the monitoring of transmitting standard formatted data between Trading Partners. For outbound data, the EDI Translator maps data from the Oracle interface flat files to any standards of choice. For inbound data, the EDI Translator maps data from the standards of choice to the Oracle interface flat file. The format and content of this flat file can be easily adjusted using the open interface definition table within the Oracle Gateway, though any changes that are made should also be implemented within the EDI Translator set-up. The Gateway processes data via an interface file which is received from or sent to the EDI Translator. The Gateway is independent of all standard formats since only the business data is found in the Oracle Gateway defined interface files. Additionally, the Oracle Gateway provides general code conversion functions for data such as Unit of Measure, Shipping Codes, Payment Terms, and determines the Trading Partner EDI validation/authorization between the Oracle application and the EDI Translator. Inbound Transactions For inbound transactions Oracle Gateway populates the Application Open Interfaces within the Oracle Application products. All of the necessary application logic to validate and load data is provided by the Application Programming Interface code (APIs), i.e. not by the Gateway. The Gateway only populates the relevant Application Open Interface tables recognized by the APIs for the specific EDI message/transaction. Process Flow The Oracle Gateway performs the following functions during an inbound transaction process after it receives an interface file from the EDI Translator or other process: • Gets Trading Partner validation processing parameters • Applies code conversions (if set up and activated). • Loads valid data into the appropriate Oracle Application Open Interface tables for the transaction. • e-Commerce Gateway captures transaction data exceptions. These exceptions can be reviewed on-line from the staging tables to examine the exception condition. The correction action is performed in a trading partner set up or other application set up. The transaction can then be revalidated. Outbound Transactions For outbound transactions, the Gateway extracts the data from the base Application tables. Also, it may optionally extract data from other files/tables using the built-in extensible architecture using ‘Extension’ tables. The use of Extension tables requires customization of standard code packages provided with the Oracle Gateway if the user has need of this function. Process Flow The Oracle Gateway outbound transaction process creates interface data files to support any EDI Standard that is available from the EDI Translator. The Oracle Gateway collects all of the business data needed to map to a standard EDI transaction/message which the receiving Trading Partner can interpret properly into their receiving application using their equivalent of the Gateway/EDI Translator set up. The Oracle Gateway does the following: • Gets Trading Partner processing parameters, e.g. location codes, allowable/enabled EDI transactions/messages, etc., • Extracts data from the Oracle base applications tables relevant to the EDI transaction/message being processed. • Optionally, retrieves data from customer defined extension tables (requires some customization). • Applies code conversions (when set up and activated). • Populates Oracle Gateway interface tables with all the data gathered. • Sets the data extract flags in the base Oracle Application table to prevent subsequent extraction. • Produces an interface data file for use by the EDI Translator. Note The Oracle Gateway does not have communication software to transmit the standard formatted data between Trading Partners. The Oracle Gateway relies on the EDI Translator being connected to third party communication service providers to transmit data to, or receive data from, Trading Partners after the data is mapped to the desired standard format.

Integrating Oracle 11i with SSO

Setup Oracle Single Sign-On System ( iAS 10g, OID, SSO Server etc.,) It is required to install and configure Oracle Single Sign-On system as per the metalink note: 233436.1 (Installing Oracle Application Server 10g with Oracle E-business suite R11i). Following are the components which are essential in this process: · Oracle Applications Server 10g (10.1.2.0.2) · Oracle Single Sign-on (10.1.2.0.2) · Oracle Internet Directory (10.1.2.0.2) Detailed instructions are provided in the above mentioned metalink note. Integrate Oracle SSO Server with Oracle 11i Applications By default Oracle Applications is not single sign-on enabled. To make it enabled, there is a series of tasks to be done as mentioned in the metalink note: 233436.1. As pre-install tasks, one needs to install DBMS_LDAP on E-business suite if it is not done already. Detailed instructions are given in the note. It is also required to register Oracle 11i Applications as the partner application to SSO as per the instructions given. Once SSO is enabled for Oracle 11i Applications, SSO server takes care of the user authentication process instead of Oracle Apps FND USER local login. One can verify if SSO integration is done correctly or not by accessing the following URL to sign into applications. http://[host]:[port]/oa_servlets/AppsLogin Here [host] and [port] reflect the correct values for your environment. Integrate Oracle SSO Server with Oracle 11i Applications It is essential to register any custom applications and Oracle Applications as partner applications with SSO server to enable single sign-on. Guidelines for registering the Oracle Apps as partner application is described in the metalink note: 233436.1. Also, one needs to register custom applications as partner applications to make them SSO enabled by Oracle SSO server. SSO Server Admin guide has more details to achieve the same in Chapter 4 (Configuring and Administering Partner Applications). In OracleAS release 10.1.2, one use mod_osso, an authentication module on the Oracle HTTP Server, to enable applications for single sign-on. mod_osso is a simple alternative to the single sign-on SDK, used in earlier releases to integrate partner applications. mod_osso simplifies the authentication process by serving as the sole partner application to the single sign-on server. By doing so, it renders authentication transparent for OracleAS applications. mod_osso interoperates only with the Oracle HTTP listener. You can use OracleAS SSO Plug-in to protect applications that work with third-party listeners such as Sun One and IIS. Migrate Customer Master File to TCA/FND Customer Master Current customer data resides in the custom table structures. The same needs to be migrated to Oracle Applications TCA/FND schemas to enable the 11i Applications access for the customers. Following table maps the column names between OID, FND_USER, TCA tables. From OID to Oracle E-business suite (FND/TCA) From Oracle E-business suite (FND_USER) to OID Create OID Customer Directory Following is the process to create the accounts for those who have access to Oracle applications. An Oracle E-Business Suite administrator can use AppsUserExport to export a selected set of application accounts from the Oracle E-Business Suite Release 11i native user directory (FND_USER) into an intermediate LDIF file. An Oracle Internet Directory administrator then uses the Oracle Internet Directory ldifmigrator utility to convert this intermediate LDIF file into a final LDIF file, based on Oracle Internet Directory deployment choices. The Oracle Internet Directory administrator then loads the final LDIF file into Oracle Internet Directory. Following is the process to create the OID customer data for those customers who would access only the custom applications but still require single sign on. Task 1: Create an Intermediate Template File Applications generating data in national languages must store that data in AL32UTF8 in the intermediate template file as specified in the IETF RFC 2849, "The LDAP Data Interchange Format (LDIF) – Technical Specification" available at http://www.ietf.org. dn: cn=jdoe, %s_UserContainerDN% sn: Doe %s_UserNicknameAttribute%: jdoe objectClass: inetOrgPerson objectClass: orclUserV2 title: Member of Technical Staff homePhone: 415-584-5670 homePostalAddress: 234 Lez Drive$ Redwood City$ CA$ 94402 Task 2: Run the OID Migration Tool Once you have set up the intermediate template file, the OID Migration Tool enables you to bring all pertinent data from the application-specific repository into Oracle Internet Directory. Once the data is migrated, one can update whatever portion of it is relevant to the application by synchronizing that application with Oracle Internet Directory. You synchronize by using the Oracle Directory Synchronization Service. More details can be found in the Chapter 23 – Migration of Data from Other Directories in OID Admin Guide 10g R2. Setup Sync process for OID and TCA/FND Customer Directory After the Oracle Single Sign-On integration is complete, user information exists in two places: Oracle Internet Directory and Oracle E-Business Suite Release 11i: · A GUID uniquely identifies a user across multiple systems. · Both Oracle Internet Directory and Oracle E-Business Suite store GUID information for each single sign-on user. · During the authentication handshake between Oracle Internet Directory and Oracle E-Business Suite Release 11i, Oracle Single Sign-On passes the authenticated user information in the form of GUID to Oracle E-Business Suite, which then uses the GUID to locate the corresponding application account. · Once a GUID is generated and stored in both a single sign-on account in Oracle Internet Directory and an application account in Oracle E-Business Suite Release 11i, the two accounts are said to be linked. User provisioning between Oracle E-Business Suite Release 11i and Oracle Internet Directory · New users created on either system can be provisioned into the other via the provisioning process. The provisioning system consists of components of both Oracle Internet Directory and Oracle E-Business Suite Release 11i that queue user events on each system, plus an Oracle Internet Directory process that periodically pushes or pulls these events to or from Oracle E-Business Suite Release 11i. · The provisioning process establishes the GUID link for provisioned accounts. During this process, single sign-on accounts are automatically linked to Oracle E-Business Suite Release 11i application accounts. · Once linked, user changes from either system can be provisioned into the other. · The provisioning process between Oracle Internet Directory and each Oracle E-Business Suite instance is determined by a provisioning profile. · The provisioning profile controls which user events are provisioned, the direction of provisioning, and the user attributes included in each event. Oracle E-Business Suite Release 11i is said to be a provisioning integrated application with Oracle Internet Directory when a provisioning profile is created for it. Strategy for user management After the initial migration, you may choose to allow new users to be created either from Oracle Internet Directory or from Oracle E-Business Suite, and then provision them into the other system. This is achieved by enabling either the SUBSCRIPTION_ADD event from Oracle Internet Directory to Oracle E-Business Suite Release 11i, or the IDENTITY_ADD event from Oracle E-Business Suite Release 11i to Oracle Internet Directory. Whether new users are created in either Oracle Internet Directory or Oracle E-Business Suite Release 11i, they must have the appropriate Applications responsibilities assigned to them, via the Applications Security forms. More details can be found in the document, Integrating Oracle E-Business Suite Release 11i with Oracle Internet Directory and Oracle Single Sign-On located in metalink.

Introduction to Oracle Single Sign-On System

Introduction Single sign-on Server (SSO) provides a mechanism that allows a number of different Applications common to an enterprise to share a user authentication service. With Oracle's enterprise-wide Single Sign-On, a user is required to log on, or authenticate once. That verification of the user identity is valid for the duration of the user session, and for every Application participating in the Single Sign-On framework. The user session ends, across every Application, when the user logs out of any partner Applications. User authentication process will be delegated to SSO and it will manage user credentials (password, digital certificate, etc.) Key Components in the Single Sign-On System OracleAS Single Sign-On interacts with the following components: 1. Single Sign-On Server 2. Partner Applications 3. External Applications 4. mod_osso 5. Oracle Internet Director 6. Oracle Identity Management Infrastructure Single Sign-On Server The single sign-on server consists of program logic in the OracleAS database, Oracle HTTP Server, and OC4J server that enables you to log in securely to applications. These applications take two forms: partner applications and external applications. In both cases, you gain access to several applications by authenticating only once. Partner Applications OracleAS applications delegate the authentication function to the single sign-on server. For this reason, they are called partner applications. An authentication module called mod_osso enables these applications to accept authenticated user information instead of a user name and password once you have logged in to the single sign-on server. A partner application is responsible for determining whether a user authenticated by OracleAS Single Sign-On is authorized to use the application. External Applications External applications do not delegate authentication to the single sign-on server. Instead, they display HTML login forms that ask for application user names and passwords. Each external application may require a unique user name and password. You can configure the single sign-on server to provide user names and passwords to external applications on users’ behalf once they have logged in to the single sign-on server. The server uses the single sign-on user name to locate and retrieve application names and passwords and to log the user in. mod_osso mod_osso is an Oracle HTTP Server module that provides authentication to OracleAS Applications. It replaces the single sign-on SDK, used in earlier releases of OracleAS Single Sign-On to integrate partner applications. Located on the application server, mod_osso simplifies the authentication process by serving as the sole partner application to the single sign-on server. In this way, mod_osso renders authentication transparent to OracleAS applications. The administrator for these applications is spared the burden of integrating them with an SDK. After authenticating a user, mod_osso transmits the simple header values that applications may use to authorize the user: · User name · User GUID · Language and territory Oracle Internet Directory Oracle Internet Directory is the repository for all single sign-on user accounts and passwords: administrative and non-administrative. The single sign-on server authenticates users against their entries in the directory. At the same time, it retrieves user attributes from the directory that enable applications to validate users. Oracle Identity Management InfrastructureOracleAS Single Sign-On is just one link in an integrated infrastructure that also includes Oracle Internet Directory, Oracle Directory Integration and Provisioning, Oracle Delegated Administration Services, and OracleAS Certificate Authority. Working together, these components, called the Oracle Identity Management infrastructure, manage the security life cycle of users and other network entities in an efficient, cost-effective way.