This chapter covers the following topics:
This chapter contains information on implementing and maintaining user management and site registration functionality in Oracle iStore.
User management is the process of registering a user and thereafter maintaining the user in the system by granting or revoking privileges, accounts, customer profile information, and party relationships based on a set of business requirements. User management involves registering new users, modifying existing users, approving or rejecting user approval requests, setting up enrollments and registration templates, assigning users to business accounts, and more. For self-service registration (such as provided through Oracle iStore's Customer Application), the following two options are available for setting up roles, registration processes and system-administrator-level user maintenance:
Oracle CRM System Administration Console (accessible by logging in as System Administrator through the JTF login interface)
Oracle User Management (accessible by logging in as System Administrator through the AppsLocalLogin interface)
Leveraging the above user management framework applications, you can use Oracle iStore to register users, configure registration pages, approve users, manage user profile information, and more.
This chapter discusses the capabilities and functionalities of user management within Oracle iStore, with some summarized information about using Oracle CRM System Administration Console. Other than one section on integrating with Oracle User Management (UMX), no information is provided about UMX. For complete information on utilizing the capabilities of these other user management framework application, see:
Oracle E-Business Suite CRM System Administrator's Guide
Oracle E-Business Suite Security Guide
This section provides key terms and definitions related to user management. Note that the functionality described here is the functionality of either Oracle iStore or Oracle CRM User Management, not that of Oracle User Management.
Approval Definition: Approval definitions use Oracle Workflow to track and route request(s) to the approvers. An approval definition can deliver an e-mail notice to the approvers. Both user types and enrollments can share the same approval definition. The e-mail notifies what types of requests are being requested (user type or enrollment) and what action the approver needs to take.
Business User: Business-to-business (B2B) users represent companies whose information is stored in Oracle Trading Community Architecture. Typically, when B2B users self-register, they enter an Organization ID (Registry ID) created when the first user from that company registered.
Enrollment: An enrollment is a set of add-on services that you can receive during or after registration. "Services" include responsibilities, roles, approval definitions, and registration templates. One enrollment corresponds to zero or one responsibility, zero or one enrollment template, zero or one enrollment approval and zero or more roles. Enrollments are application specific and can be tied to user types.
Permission: A unit of privilege that is granted to a user within his user role. It usually serves to grant a certain type of access to a resource. Resources are application elements such as objects or methods of objects. A resource can have unique permissions for each way that it can be accessed.
Primary User: An administrative B2B end-user charged with fulfilling user management functions for his company. Typically, when the first B2B user registers from a company, an Organization ID (Registry ID) is created.
Responsibilities: When a registered user initially logs in, the system checks the user's current responsibility and then passes the user into the menu structure associated with the HTML application to which that responsibility is linked. In this way, different user types can have different responsibilities and therefore can have different menus assigned to them. Responsibilities can either be granted automatically upon registration, through the user management framework, or on a case-by-case basis by an administrator.
Roles: Within each HTML page, granular permissions control which resources on a page a user is allowed to access. These resources may be a button, a data manipulation permission, a view permission, and so on. In Oracle HTML applications, permissions are grouped into roles which can then be granted to users. Roles are granted either automatically (depending upon your configuration) or on a user-by-user basis by an administrator.
User Profile: User profiles, which are associated with responsibilities, are sets of user interfaces that give users access to their personal data and preferences.
User Profile Menus: User profile menus are groupings of user profile pages which are relevant to a particular responsibility. User Profiles are user interfaces to users' personal data and preferences. A number of responsibilities can share the same user profile menu.
User Type: A category of users that caters to the specific needs of an application's business requirements. User types allow flexible and extensible ways for defining, categorizing and implementing behavior of users. A user type is associated to only one template, one responsibility, zero or one approval, zero or more enrollments, and zero or more roles. Examples include: Register your company, Register as individual, and Register as a user of an existing company. For all Oracle iStore seeded user types, roles and responsibilities are not directly associated to the user type; rather, they are always bundled into enrollments, which in turn are attached to the user types.
User Type Templates: Applications require varying pieces of information to register different types of users. User Type templates refer to JSP files that are used to capture the registration information that is special to a particular user type, and the registration handler for the specific user type. Oracle iStore user types are associated to specific user type templates, defined in the Oracle iStore Template Manager, and do not use Oracle CRM User Management registration templates.
Oracle iStore offers support for allowing customer registration through the Oracle User Management framework.
To allow you to use Oracle User Management with Oracle iStore, the following data is supplied:
Seeded user management grant: iStore Registration Guest Grant
Seeded user management menu: iStore Registration Menu
Seeded user management function: iStore Registration
Following are high-level steps to enable registration through Oracle User Management:
Set the profile option, Local Login Mask, to 127 to enable the registration feature.
Create a registration process (for example, iStore Registration) in Oracle User Management.
Set the profile option, UMX: Register Here Link: Default Registration Process, at server level.
In the above setup, the Register Here link takes users to an Oracle User Management central registration page. In addition, the system uses the Oracle User Management Forgot Password feature and related e-mail notification instead of Oracle iStore's own Forgot Password feature/notification. Oracle User Management is accessible by logging in as System Administrator through the AppsLocalLogin interface. For more information on Oracle User Management, see the Oracle E-Business Suite Security Guide.
Customers who wish to access Oracle iStore's Customer Application must register and be approved (if your implementation requires approval) before they have full permissions in the sites. Oracle iStore provides registration and user management screens for customer users; however, most user registration setups and associated processes are provided through a common registration and user management framework supplied by the Oracle CRM System Administrator Console.
The Oracle CRM System Administrator Console is accessible by logging into the Oracle CRM Login Servlet (JTF login) as system administrator. System administrators have the ability to configure user types, roles, enrollments, registration templates, and approval processes. See the online help accessible from the System Administrator Console for more information.
Users begin registration by selecting the Register link, and then select their user type from a list of user type choices. The user framework supports a variety of user types and approval scenarios. In addition, you can use enrollments to automatically tie specific registration data to user types.
Note: Do not use the Oracle CRM System Administrator Console to register users of Oracle iStore. Use Oracle iStore's registration pages and user management pages instead. These pages are available in the Customer Application after your setup of Oracle iStore is complete. See the section, "Registering Using Oracle iStore", for details.
Registration involves filling in personal and company data (if applicable), and then waiting for approval (if required) before accessing the Web sites. Depending upon the approval mechanisms in place, users are either automatically approved or approved by an administrative user. Note that in a multiple-approver scenario, all approvers must approve a user before he is granted access. Integration with Oracle Workflow (using both Oracle CRM Technology Foundation and Oracle iStore workflows) provides e-mail notification of user registration events and pending approvals.
Users of Oracle iStore, Oracle iSupport, and Oracle Partner Management can attain an integrated user registration and management experience through the common registration framework and Oracle iStore's site management capabilities. These capabilities are summarized in this section. Also see the following chapters:
The highlights of the common registration framework are discussed below.
The framework lets implementers provide common registration pages for integrating applications. A common registration page displays all of the user types available for integrating applications' users.
Brandable registration pages and common look and feel can be achieved through Oracle iStore Template Manager. Oracle iStore provides common registration screens for Oracle iSupport, Oracle iStore, and Oracle Partner Management that support a brandable and customizable look and feel and leverage existing Oracle CRM Technology Foundation APIs.
The framework utilizes the user type definition capabilities of the Oracle CRM User Management Framework, but the registration screens are created and managed through Oracle iStore's Template Manager. Merchants can customize and brand these screens using the existing capability provided by the Template Manager.
Oracle iStore provides support for users to register through a common Oracle User Management registration page.
The framework features the ability to enable and disable the user types that display in the registration page. The registration page can be configured to display user types associated to the Oracle iStore framework that are not self-service-enabled. For each user type, specific enrollments automatically award sets of roles and responsibilities. In addition, you can activate additional seeded enrollments which award more responsibilities and/or roles.
The site and user management integration allows implementers to create Oracle Partner Management partner sites and support partner functionalities, utilizing the Oracle iStore Customer Application as the entry point for partner registration and partner program enrollments.
Using the framework, implementers can offer self-registration and approvals for non-primary users.
The framework understands the Oracle CRM User Management Framework approval processes. It also understands the enrollments (explicit and implicit) associated to user types, and can launch approval processes if required.
Oracle iStore also supports mapping content to three left and three right bins on registration and user type selection pages. In this way, the same content can be shown on both of these pages. Or, each bin could be mapped to different content per user type. See the chapter, Implementing the Catalog, for details.
Integrated user management across applications provides registration and support for several user types within the Oracle iStore framework. Setup of user types is performed in the Oracle CRM System Administrator Console. A table listing the seeded user types, enrollment keys, and default responsibilities and roles can be found in the topic covering user type definitions in the appendix, Seeded User Data. Following are the seeded enrollments for common user types.
Individual users: Individual (B2C) users are associated to the default Oracle iStore and Oracle iSupport B2C user responsibilities and roles, via the following enrollments:
iStore (Individual User) --- This enrollment contains the seeded iStore customer responsibility. It is active by default.
Support Site: Individual User --- This enrollment contains default Oracle iSupport B2C user responsibility and roles. It is not active by default; you must enable it.
These two default enrollments give B2C users the required ability to access Oracle iStore sites and Oracle iSupport via the Oracle iStore Customer UI (if the Support Site: Individual User enrollment is activated). By default, these users do not require approval. No roles are assigned to this user type, or to the enrollment, out-of-the-box.
Non-administrative business users (B2B users): Typically, non-administrative B2B users are associated to the default Oracle iStore and Oracle iSupport non-primary B2B user responsibilities and roles, via the following enrollments:
iStore (Business User) --- This enrollment contains the seeded Oracle iStore customer responsibility and the non-administrative business user role.
Support Site: Business User --- This enrollment contains default Oracle iSupport non-administrative B2B user responsibility and roles. It is not active by default; you must enable it.
These two default enrollments give these users permission to access Oracle iStore and Oracle iSupport as regular business users. By default, these users require approval by a primary user within their company.
Primary business users (primary B2B users): Typically, primary users are associated to the default Oracle iStore and Oracle iSupport B2B primary user responsibilities and roles, via the following enrollments:
iStore (Primary User) --- This enrollment contains the seeded iStore customer responsibility and the administrative business user role.
Support Site: Primary User --- This enrollment contains default Oracle iSupport administrative B2B user responsibility and roles. It is not active by default; you must enable it.
These two default enrollments give these users permission to access Oracle iStore and Oracle iSupport as primary users for their companies. By default, these users do not require approval.
Oracle Partner Management primary users: By changing the default user type setup, Oracle Partner Management primary users can be associated to primary B2B Oracle iStore responsibilities and roles via the iStore (Primary User) enrollment. This default enrollment gives these users permission to access the Oracle iStore sites as partner primary users. By default, these users do not require approval.
Oracle Partner Management non-primary users: By changing the default user type setup, Oracle Partner Management non-administrative B2B users can be associated to the non-administrative business user responsibilities and roles via the iStore (Business User) enrollment. This default enrollment gives these users permission to access the Oracle iStore sites as regular partner users. By default, these users require approval.
Note: Oracle Partner Management user types are not enabled by default. You must enable the user types in the Oracle CRM System Administrator Console. See the chapter, Integrating Oracle iStore with Oracle Partner Management, the online help available in the CRM System Administration Console, and the Oracle Partner Management Implementation Guide for details.
Any custom user types: See the custom user types setup information in the "Ensuring Proper Dependency Setup for User Management" section within this chapter
See this chapter's "User Type Registration Selections" section for details about the seeded Oracle iStore registration page.
Oracle iStore supports placing URL parameters appended to page URLs. For example, implementers can append the Oracle iSupport application ID to the end of the application entry page, ibeCZzpEntry.jsp.
ibeCZzpEntry.jsp?go=reg&app_id=672
Following are the supported parameters and their impact on functionality:
app_id: This parameter tells the system which application the registration page is associated to.
cancel_url: This parameter, if present along with app_id, causes a Cancel button to be displayed in the registration page.
bpage: For iSupport integration, this parameter displays the bottom portion of the registration page.
mpage: For iSupport integration, this parameter displays the top portion of the registration page.
ref: This parameter determines the target page after registration. For example, if a guest user has created a cart and attempts to check out, the ref parameter can specify that the Billing and Shipping page URL be the next page the user is taken to after registering. If the ref parameter is not provided, then iStore takes the user to the Site Selection Page directly after registration.
Leveraging integration with Oracle Workflow, the Oracle iStore registration framework supports several notification events which inform users via e-mail of registration events. If integrating with Oracle iSupport and/or Oracle Partner Management, the system substitutes specific Oracle CRM user management notifications for the iStore notifications. See the chapter, Integrating Oracle iStore with Oracle Workflow, for details.
The following application context benefits are provided to users of integrating applications:
Ability to keep the application context when registering and logging in from an application
Ability to select the application context when registering and logging in from a generic Web site or login page
See the chapter, Implementing Site Management, for more information.
Deep linking from external web sites to the registration page is supported. See the deep linking information in the chapter, Advanced Display, for more information.
See the chapter, Integrating Oracle iStore with Oracle Single Sign-On.
The Oracle iStore user management framework leverages the Oracle CRM Technology Foundation user management framework through the Oracle CRM System Administration Console. Therefore, you must ensure that the technology stack is properly set up before beginning user management operations. Follow the steps in the Oracle E-Business Suite CRM System Administrator's Guide , to set up Oracle CRM Technology Foundation (or see the online help available through the System Administration Console). Also perform the setups listed in the chapter, Verify Mandatory Dependencies, and the remaining sections within this section, if your business requirements dictate.
Customer registration for users of Oracle iStore's Customer UI is enabled by default -- however, Oracle Applications requires that the guest user password profile option be set, as outlined below. All of the other steps are optional.
Oracle Applications requires that the guest user password profile option be set. For Oracle iStore functionality, if this profile is not set at site level, user registration will fail. Therefore, set the profile, GUEST_USER_PWD, at site level. The value should be the username/password of a valid applications user account. It is recommended that this account is not assigned any actual responsibilities, but assigning IBE_CUSTOMER responsibility is required so that iStore can display the catalog for guest users.
The default roles and responsibilities awarded to users who register through Oracle iStore's Customer UI are controlled through the user type definitions in the Oracle CRM System Administrator Console. For more information, see this chapter's sections: "User Type Support Across Applications", "Registering Using Oracle iStore", and "User Types Overview". Also refer to the appendix, Seeded User Data.
Be sure to check the values of the following Oracle CRM user management profile options:
Signon Password Length
Signon Hard to Guess
Signon Password Custom
These profile options can affect the restrictions that apply when users initially enter password and username information during registration.
A user's default language preference for e-mail notifications is set from the user's session language during registration. The user can change this default setting in the Profile, Preferences page. See the "Personal Profile Pages" section later in this chapter for more information.
In order for Oracle iStore registration processes to work properly, the Customer profile class, "Default", needs to be in Active status. Setting this class to an Inactive will cause Oracle iStore registration to fail. Customer profile classes are set up in Oracle Accounts Receivable.
Several additional setups may be required, depending on your implementation. See the following sections within this chapter for more information:
"Registering Using Oracle iStore"
"Oracle iStore User Types"
"User Types for Integrating Applications"
"Managing Business Users with Oracle iStore"
In addition to the information found in this chapter, if integrating with Oracle iSupport or Oracle Partner Management, see the chapters, Integrating Oracle iStore with Oracle iSupport, and Integrating Oracle iStore with Oracle Partner Management, for specific user management information related to these applications.
See the appendix, Seeded User Data, for more information regarding user type definitions seeded in Oracle CRM Technology Foundation.
For users registering through Oracle iStore, a financial account is automatically created for them upon approval if the profile option, JTA: User Management: Automatic Account Creation, is set to Yes at site level. This is the default setting for this profile option. It is recommended that you leave this profile option set to Yes. If set to No, no account will be created for users upon approval, and thus newly approved users will not be able to log in to the Customer UI.
Note: By default, this profile option is No at Oracle iSupport application level, as users created through iSupport need not have a financial account.
In the event a user's registration is approved without an account number being assigned to him, a primary user or the system administrator can assign accounts after approval. See the section, "Account Assignment After Approval", for more information.
Oracle iStore supports the ability to launch approval processes for enrollments for its users. Enrollments and approval processes are defined in the Oracle CRM System Administration Console.
If a user registers, and the selected user type is associated to an enrollment that requires approval, a primary user needs to approve the enrollment request. Once the enrollment request is approved, the user can be assigned to the corresponding responsibility.
Note: Only after the user type registration request is approved are the pending enrollment requests shown to the primary user.
For information about seeded user data, see the appendix, Seeded User Data.
By default, the Oracle CRM System Administrator is the only user registration approver. It is recommended that you change the seeded approval process so that a primary user or users approve other B2B users within their organizations. See the online help available through the System Administration Console for more information.
In addition, as a best practice, set up an approval group to monitor and approve user registration requests. See the section, "Best Practice: Set up Approval Group", in this chapter, for more information.
See also: the sections, "Explicitly Approving B2B Users" and "Approval of Self-Registered B2B Users"
Business users can be approved by:
Designated primary user of the company
Any primary user of the company
Multiple primary approvers of the company, set up in a hierarchical order
System Administrator in Oracle CRM Technology Foundation
As a best practice, it is recommended that you set up an approval group structure for user registration approvals. In an approval group, several primary users can be designated as approvers who view all of the pending approvals in the same approval queue. Following are high-level steps for setting up the approval group structure:
Set up an approval group.
Create a dummy user and set the approval group profile to point to the dummy user.
Make the dummy user the approver for a single organization or for all of the organizations registered as customers of a Web site.
When setting up approvers for any of the Oracle iStore user types (including Oracle iSupport and Oracle Partner Management users), ensure that the FND users who have been chosen as approvers have been assigned the Oracle iStore Primary User permissions. These permissions enable approvers to access the Pending Approval page in the Oracle iStore user management pages. For a list of these permissions, refer to the appendix, Seeded User Data.
See the online help available through the System Administration Console for more information.
If business requirements dictate that you have a single primary user as the sole approval for an organization, you may use the following high-level steps to accomplish this setup:
In Oracle Forms as system administrator, create a new user (for example, create a user named DUMMYAPPROVER). Ensure that the user has been given a valid e-mail address.
Set profile option, JTF_PRIMARY_USER, to the username (for example, DUMMYAPPROVER) at site level.
In the Oracle CRM user management module, add the JTF_APPROVER role to DUMMYAPPROVER user.
In the Oracle CRM user management module, update the JTF User Approval approval definition to use the newly created user (for example, DUMMYAPPROVER) as the default and only approver.
For more information on setting up user approvals, see the Oracle E-Business Suite Security Guide.
E-mail notifications are automatically sent for approved or rejected user registrations. Primary users receive a notification indicating that a new user has registered in the system and has requested access. Additionally, a notification is sent to the new user to confirm that the registration is complete, but an approval is required. See the section, "Ensuring Proper Dependency Setup for User Management", within this chapter, for more information.
For e-mail notifications to function, you must integrate with and properly set up Oracle Workflow. See the chapter, Integrating Oracle iStore with Oracle Workflow, for Oracle iStore-specific information on this application. You also must set several notification-related profile options listed below.
You must set the Oracle CRM Technology Foundation user management profile options. The following steps summarize the Oracle CRM Technology Foundation profile options that affect Oracle iStore's registration e-mail notifications functionality. Note that this section contains limited, Oracle iStore-specific information on these profile options.
JTA UM Application URL (JTA_UM_APPL_URL): This profile option provides the name of the Oracle iStore application entry JSP, ibeCZzpHome.jsp, in the welcome notification sent to newly approved customers. Set this profile as follows: JSP:OA_HTML/ibeCZzpHome.jsp
. Set the profile at iStore application level. The value is null by default, and a site-level takes precedence if application level is not set. Note that implementers may need to replace OA_HTML/ with the virtual directory mapped to the JSP file location.
JTF_UM_APPROVAL_URL: This profile is used to display a link in the Oracle CRM Technology Foundation's registration approval e-mail notification sent to registration approvers. When an approver clicks on the link in the e-mail, after login, he is taken directly to the Pending Approval screen in Oracle iStore. Set this profile option at iStore application level to the approval login page URL, JSP:OA_HTML/ibeCAcdLogin.jsp?ref=ibeCUmdPApproval.jsp. Note that implementers may need to replace OA_HTML/ with the virtual directory mapped to the JSP file location. Implementers integrating Oracle iStore with other Oracle applications using iStore registration flow should set the profile at the appropriate product's application level as well. For example, implementers integrating with Oracle iSupport would set the profile at iSupport application level to the above JSP value. The Oracle iStore JSP, ibeCUmdPApproval.jsp, is by default mapped to display template, STORE_UM_PENDING_APPROVAL_SUMMARY_D (which is the Pending Approvals page). Implementers who have customized this display template to point to a different JSP should provide that JSP name (in place of ibeCUmdPApproval.jsp) in the JTF_UM_APPROVAL_URL profile option.
JTF_UM_MERCHANT_NAME: Set to the name of the company owning the system. This will be used in the e-mails sent out to notify customers of approval/rejection.
JTA: Support Contact (JTA_UM_SUPPORT_CONTACT): Set to the name of the support contact who can be contacted by users upon registration.
JTA: Sender of the email (JTA_UM_SENDER): Set to the sender of the e-mail received by users after registration; for example, set it to your company name.
JTF_UM_APPROVAL_TIMEOUT_MINS: Determines the time-out in minutes used by the JTF Approval workflow before a reminder is sent to an approver or the request is rerouted to the next approver. Zero (0) means it never times out.
JTF_PRIMARY_USER: Set this profile option to the value of the username which will be the universal primary approver.
An enrollment is a set of add-on services that users can receive during or after registration. The purpose of an enrollment is to associate with new registrants the required responsibilities, roles, enrollment approval definitions, or enrollment registration templates determined by your business needs.
Each enrollment can be associated to:
Enrollment Key, Name and Description
Responsibility
Roles
Application
Approval processes for this enrollment
Registration template for this enrollment (not supported by iStore)
Delegation Role (not supported by iStore)
Oracle iStore supports both automatic (implicit) and explicit enrollments. Self-Service, Delegation and Self-Service-Delegation application modes are not supported.
For more information, refer to the online help available through the System Administrator Console.
You can create custom user types using the Oracle CRM System Administration Console and assign the user types to roles, responsibility, and enrollments. During setup, you must associate a registration template to the user type. Further, if you create a new registration template handler, it must be coded per Oracle iStore coding guidelines. (You must refer to several seeded registration templates. Refer to Oracle.apps.ibe.um.RegisterIndividual.java used in the template, IBE_INDIVIDUAL.)
Create Custom User Type
This example creates a "Custom Business Registration" similar to Register as user of an existing organization.
Create a new template, for example, CUSTOM_BUSINESS, with the following attributes:
Template Key --- CUSTOM_BUSINESS
Template Type --- USERTYPE TEMPLATE
Template Handler --- Create a new template handler, similar to oracle.apps.ibe.um.RegisterBusiness.java. Further, any additional custom processing can also be done here.
Template Name --- For example, "iStore Custom Business User"
Page Name --- ibeCZzpGetTemplateFile.jsp?tmp=STORE_REG_CONTAINER_D&usertype_template=STORE_REG_CREATE_CUSTOM_D where, STORE_REG_CREATE_CUSTOM_D is the programmatic access name for the registration Display Template, which is mapped to the custom registration display JSP page, coded as per requirements.
Sample code --- ibeCRgdBusinessCreate.jsp. Similarly, the corresponding processing page also needs to be coded. Note: iStore coding guidelines need to be followed, similar to the sample code provided.
Application --- iStore
Description --- Used to register users for existing organization (custom handler)
Create a new user type, for example, IBE_CUSTOM_BUSINESS (similar to IBE_BUSINESS), with the following attributes:
User Type Key --- IBE_CUSTOM_BUSINESS
Registration Template --- iStore Custom Business User. Here, associate the new, custom registration template created above.
Application --- iStore
Approval by --- Select either No approval is required, if the users registered through this user type need not go through an approval process, or select from the approval processes available.
Enable self service registration --- Uncheck this option.
Assign the desired application roles and enrollments to this user type. Assigning the user type to a responsibility is not mandatory.
Set the user type as Active, and it will automatically appear in the iStore registration page without any customization.
Implementers can also set up e-mail notification configurations for custom user types. For more information, see the section, "Mapping New Notification Configurations", in the chapter, Integrating Oracle iStore with Oracle Workflow.
Depending upon whether approval is enabled/disabled for the user type, the following FND messages would be used:
Approval enabled --- IBE_APPRVL_REQD_CUST
Approval disabled --- IBE_APPRVL_NOT_REQD_CUST
Note the above FND messages are used for all custom user types exposed through iStore.
Any custom user types should also be added to the appropriate user type lookup (i.e., to IBE_UM_PRIMARY_USER_TYPES or to IBE_UM_SECONDARY_USER_TYPES). If the custom user types are not present in the applicable lookups, the registration handler will fail to distinguish the user types. Note that the same registration handler is used for both primary and non-administrative (secondary) B2B user types. For details about the lookups, see the section, "User Type Lookups", in the chapter, Implementing Messages and Prompts.
User type definitions are stored and maintained through the Oracle CRM User Management Framework. In general, each user type is tied to an Oracle Applications responsibility. The default responsibility for the Oracle iStore Customer Application is IBE_CUSTOMER.
Roles can be awarded on top of the responsibilities to further control access to the HTML applications. Each HTML application usually has its own set of users within these basic user types.
For additional information, see:
"User Type Support Across Applications"
"Oracle iStore User Types"
"Site Management User Type Definitions" in the appendix, Seeded User Data
Each user type in the CRM User Management Framework is associated to:
User type name, with corresponding key and description
Default application (Oracle iStore)
User type registration template that defines the registration flow
Approval process
Default role(s) and responsibility
In addition, for every user type, there is a long name and a short name shown in the Oracle CRM System Administration Console. The long name displays in the Oracle iStore user type Registration listing page, and the short name displays in the Oracle iStore Pending Approval screens.
For a list of how the user types map to the links in the user type listing Registration page, see the "Site Management User Type Denitions" section in the appendix, Seeded User Data.
In addition to the administrative users described in the chapter, Implementation Tasks for Oracle iStore, Oracle iStore also supports the following customer user types:
Guest users
Business-to-business (B2B) users
Business-to-consumer (B2C) users
B2B Primary users
B2B Reseller users
Oracle iStore guest users (also called walk-in users) can browse Customer UI catalogs and create shopping carts. However, they cannot:
Set up a user profile
Save a shopping cart
Share a shopping cart
Create a shopping list
Submit an order
Search or view order details
Walk-in users who visit your specialty sites are automatically logged in with the guest user name. If a guest user makes any changes, such as modifying the preferred language or currency, or adding items to the shopping cart, the changes are saved in the cookie so that different guest users cannot see each other's changes.
See the chapter, Implementation Tasks for Oracle iStore, for details on how to implement guest user access.
Registered business-to-consumer (B2C) users are individual customers not associated with a company. By default in Oracle iStore, B2C users do not require approval; they are always approved automatically -- however, you can use the Oracle CRM System Administrator Console to set up B2C users to require approval.
Unlike B2B users, for B2C users, out-of-the box you cannot assign roles.
Business-to-business (B2B) non-administrative users represent companies whose information is stored in Oracle Trading Community Architecture (TCA). Typically, when non-primary B2B users self-register, they enter a Registry ID created when the first user from that company (the primary user) registered. All B2B user information is stored in the Oracle TCA schema.
Non-administrative B2B users are awarded the business user role by default. See the "Business User Role Seeded Permissions" section in the appendix, Seeded User Data, for a list of permissions seeded within the Oracle iStore business user role.
Primary users are B2B users who are responsible for creating and managing other users within their companies. Typically, the first user who registers his company in Oracle iStore is considered the primary user. When a primary user registers his organization for the first time, a Registry ID (Organization ID), a primary company financial account, and a primary company address are created in Oracle TCA. This first financial account for the company cannot be changed by the primary user. Subsequent users from the company should use the Registry ID when registering, in order to be associated to the company in Oracle TCA.
See this chapter's "Managing Business Users with Oracle iStore" section and the "Primary User Role Seeded Permissions" section within the appendix, Seeded User Data, for more information about the abilities of these users.
The seeded IBE_RESELLER_ROLE is appropriate to assign to users who sell your products but are not internal to your company. If you are integrating with Oracle Quoting, Reseller Users can create shopping carts, but cannot view all customer accounts in your records, bill to anyone other than the sold-to customer, or sell to customers who are not in your records.
Oracle iStore supplies several user types in the Oracle CRM user management framework. See this chapter's "User Type Support Across Applications" section and the "Site Management User Type Definitions" section within the appendix, Seeded User Data, for details.
When registering through Oracle iStore, to begin registering, users can select:
The Register icon at the top right of the Site Selection Page or Site Home Page
The Register link in the Welcome Bin
Users must complete the required information, and are either immediately approved or must wait for approval before accessing the Customer Application, depending upon the approval mechanisms implemented.
Implementers can specify the landing page that occurs after registration by inserting the "ref" parameter in the URL. See the "Support for URL Parameters" section within this chapter for more information.
Following registration, administrative B2B -- known as primary users -- can fulfill user management functions for their companies in Oracle iStore's Customer UI. These functions can include: approving users, creating new users, assigning accounts, resetting passwords, and awarding and managing user roles.
Additional Information: Implementers can disable the ability for primary users to create other users by setting a profile option, APPS_SSO_USER_CREATE_UPDATE, to Disabled. See the section, "Ability to Disable User Creation", below, for more information.
When a user's registration request is submitted, the username entered is created in Reserved status in the Oracle Technology Foundation table (FND_USER table). Only upon approval is the username enabled in the system. If the approval is rejected, the username is released and all details of the contact are inactivated. The username is removed from the system and can be re-used by this or another user. Also, since the contact is inactive, it is not selectable to be the sold-to, bill-to, or ship-to contact by any other user, nor by sales representatives.
In addition to the above noted behavior, the system sets rejected users' Oracle TCA data to inactive. If the user is a business contact of an existing B2B organization, the party of type, contact, associated with the user is set to inactive status. If the user is the primary user of a new, registered company, both parties – organization and contact – are set to inactive, as long as there is no other contact associated to the organization. If the user is a B2C customer and is registering for the first time, the new party of type, person, is set to inactive status. Following are the specific records that are inactivated for the two main user types (B2B and B2C):
B2B User:
Organization record (only if there is no other active contact/employee of this organization)
Person record
Party relationship record
Party site record
Contact points (address, phone, e-mail)
Preference record
B2C User:
Person record
User contact points (phone, e-Mail)
User preferences
The following are exceptions to the above rules:
When a user gets created from Central Account Provisioning system (CAPs) registration page, an FND_USER record always get created in Active status, and hence, upon rejection, TCA data will not be inactivated.
When a user gets created via the Online Access to Existing Account functionality, his TCA data is never set to inactive, since the user already has valid transactions in the system.
When an incomplete user completes Partial Registration using a user type requiring approval, and his request is rejected by a primary user, his username is not released (as it would have already been active), and also his TCA contact details are not inactivated.
If the implementation requires that a user's TCA data never gets flagged as inactive, disable the subscription with IBE_JTA_INTEGRATION_GRP.postRejection as the function name. Use the following steps:
Log into Oracle Self Service Web Applications as system administrator and select the responsibility, Workflow Administrator Web Applications.
Navigate to Business Events and then select Events.
Search for the event, oracle.apps.jtf.um.rejectUTEvent.
For the above event, select Subscription.
Update the subscription with IBE_JTA_INTEGRATION_GRP.postRejection as the function name.
Change the status to Disabled and save the changes.
When a user registers through Oracle iStore, the system automatically checks, before registering the username, whether the username is already in use in Oracle CRM Technology Foundation (FND_USER table), Oracle Internet Directory (OID), and any other third-party application. Following is the behavior during the checks:
During self-service registration, if the username is already in use, the system displays a "username already used" message to the user.
During delegated user creation (e.g., when a primary user is creating another user), if the username already exists in OID, but not in FND, the registration is allowed to be completed, as long as the profile option, Link Applications user with OID user with same username, is turned on. In this case, the system creates the username in FND and links the username to the OID username. If this re-linking profile option is off, and if the user exists in FND, the system displays the "username already used" message.
If integration with Oracle Single Sign-On Server is turned off, the system only checks the FND_USER table for the presence of the username.
The following table further illustrates the behavior.
Username Not in FND or OID | Username in FND and OID | Username in FND But Not in OID | Username in OID But Not in FND Re-linking Not Allowed |
Username in OID But Not in FND Re-linking Allowed |
|
---|---|---|---|---|---|
Self- Registration | Username creation allowed; username created in FND and propagated to OID | “Username already used” error message is shown | “Username already used” error message is shown | “Username already used” error message is shown | “Username already used” error message is shown |
Delegated User Management | Username creation allowed; username created in FND and propagated to OID | “Username already used” error message is shown | “Username already used” error message is shown | “Username already used” error message is shown | Username creation allowed |
The user type selection Registration page groups users into three main types:
Individual (B2C)
Business (B2B)
Oracle Partner Management (Partners)
An additional group, titled Others, displays for user types that do not match any of the above categories. This scenario may occur when a new iStore user type is introduced that is not included in any of the existing lookups that categorize the user types; in this case, the Others group automatically appears in the user type listing page, and the new user type is shown under that group.
The grouping for the three main types is achieved using the following user type lookups:
IBE_UM_INDIVIDUAL_USER_TYPES, for B2C users
IBE_UM_STORE_USER_TYPES, for B2B users
IBE_UM_PARTNER_USER_TYPES, for Partner users
Each of the lookups shown above contains additional lookups (child lookups) that enable the specific registration links for the different user types. For example, the IBE_UM_STORE_USER_TYPES lookup contains child lookups for primary, non-administrative B2B, and Need Online Access users. The codes of the child lookups match the user type keys present in Oracle CRM user management module. The standard user types are enabled by default. To enable an additional user type, enable the user type in the Oracle CRM Technology Foundation System Administrator's Console.
For a list of the child lookups within each user type lookup, see the chapter, Implementing Messages and Prompts.
Additional Information: While displaying the registration user type listing page, if the system returns only one user type, then the user will be directly taken to the registration page for that user type.
Following is the business flow for users selecting a user type in the registration page:
The user accesses the Registration page using one of the methods described in the section, "Registering Using Oracle iStore", above.
In the Registration page, users select one of the following hyperlinks (which map to the user types lookups and to user types in the Oracle CRM user management module):
Register as individual --- This link is for registering B2C users.
Register your company --- This link is for registering a company for the first time. Note that this registers a primary user for the first time. An Organization ID (Registry ID) is created. When the primary user registers his company, the company is registered as a customer of the site where he registers, and the user is created as the primary user for that organization.
Register as a user of an existing company --- This link is for registering a non-administrative B2B user whose company has already been registered.
Register as a partner --- This link is for registering an Oracle Partner Management application company that will be accessing Oracle iStore's site management functionality.
Register as a user of an existing partner --- This link is for registering a partner business user (a user affiliated with the Oracle Partner Management application) whose company has already been registered.
Also note the following:
Additional links are available if Online Access to Existing Account has been enabled. Different links also display depending upon whether Partial Registration is invoked. See the sections, "Online Access to Existing Account" and "Partial Registration", below, for more information.
The partner links are not enabled by default. Implementers only set up the Oracle Partner Management links if integrating with Oracle Partner Management. See the Integrating Oracle iStore with Oracle Partner Management, chapter for more information.
For a list of the e-mail notifications sent with user registration for the various user types, see the chapter, Integrating Oracle iStore with Oracle Workflow.
Depending upon the type of registration selected and whether your implementation supports integration with Oracle SSO Server, Oracle iSupport and/or Oracle Partner Management, several other flows are possible. See the following chapters for more information:
The following figure shows an example of how the Registration page might look in an implementation of Oracle iStore.
Oracle iStore Registration Page Example
Note: The above page is shown only when the implementation is not using a Central Access Provisioning system (CAPs). If CAPs is enabled, a different page is shown. See the chapter, Integrating Oracle iStore with Oracle Single Sign-On, for more information.
Remember that the Partner registration links are inactive by default. You must activate these user types in the Oracle CRM System Administration Console. See the chapter, Integrating Oracle iStore with Oracle Partner Management, and the Oracle Partner Management Implementation Guide for more information.
The following use cases can aid your understanding of the Registration page behavior under various conditions. These use cases assume at least one Online Access to Existing Account user type is enabled.
In this scenario, Oracle iStore is integrated with Oracle Single Sign-On Server (SSO), CAPs is disabled, and user creation/update is allowed. Since CAPs is disabled, the user type registration selection page will display all existing user types, grouped under the user type groups.
In this scenario, Oracle iStore is integrated with Oracle Single Sign-On Server (SSO), CAPs is enabled, and user creation/update is not allowed. Since CAPs is enabled, the user type registration selection page will display the following:
A New User section with the link, Register as a new user
An Existing User section, with the following Online Access to Existing Account links:
Individual Link: Need online access to your existing individual account?
Company Link: Need online access to your existing corporate account?
Note that if the Online Access to Existing Account user types are disabled, the system will direct the user to the CAPs registration form.
You can set up the Registration user types listing page to show only a subset of the available user types. You can set up a site-specific user type listing or set up a deep link to a specific user type(s) registration from an external page. This functionality is achieved by using the parameter, group_ut.
To set up a site-specific link scenario, map the JSP, ibeCRgdRegContainer.jsp (the registration listing page), appended with the parameter, group_ut=<list of comma separated user type keys>, to the Display Template, STORE_REG_CONTAINER_D.
Example: The implementer has added a template mapping for the Display Template, STORE_REG_CONTAINER_D, which is the user type Registration listing page. The template has the following URL mapped to a Oracle Partner Management specialty site:
ibeCRgdRegContainer.jsp?group_ut=IBE_PARTNER_BUSINESS:IBE_PARTNER_PRIMARY
With this setup, when a user selects that Partner specialty site and then selects the Register link within the specialty site, the system will show only the enabled Partner user types in the Registration page.
To set up a deep link to a specific user type(s), create the deep link in the external site, as in the following example:
http://<host>:<port>/OA_HTML/ibeCAcpSSOReg.jsp?a=b&group_ut=IBE_PARTNER_PRIMARY:IBE_INDIVIDUAL
In the above example, the Registration page would only show the Register as Individual and Register as a partner listings (grouped, of course, into the Individual and Partner areas).
Also note the following:
If only one user type is enabled, or if group_ut has a known, enabled iStore user type key, the system will auto-direct the user to the user type registration form of the specified user type key.
If no user type is enabled, or if group_ut has a user type not present in the enabled user type list, the system shows an appropriate error message.
This section discusses the user registration pages available with standard registration.
The individual user (B2C) registration page is available by selecting the Register as individual hyperlink on the Registration page. It includes the following data entry fields:
Name: Fields are present for first, middle, and last names.
E-Mail Address: The system validates the format of the e-mail address entered.
Telephone/Fax Numbers: Fields are present for business and personal phone numbers as well as fax number. Country code is supported in the user interface also.
Username: The system checks whether a duplicate (active) username exists, and if so, the user is prompted to enter a different username.
Password: Fields are present for entering and re-entering a password.
Opt-in/Opt-out of Marketing: The checkbox field, Please send me e-mail about special offers and products., captures the user's preference in terms of receiving marketing materials via e-mail. The checkbox is un-checked by default.
The B2C user is not required to enter address information to register.
The user registration page for primary (administrative) business users is available by selecting the Register your company hyperlink on the Registration page. It includes the following data entry fields:
Business Information Section:
Company Name --- This information becomes the company (organization) name in Oracle TCA. After registration is submitted, Oracle TCA creates a Registry ID for the organization which subsequent (non-administrative) users then use during registration.
Country --- This field is a list-of-values showing all countries defined in Oracle TCA.
Address --- Four lines are provided for street address, plus fields for City, State, County, and Zip code.
Telephone/Fax Numbers --- Fields are present for company phone number and fax number. Country code is supported in the user interface also.
Personal Information Section: This section contains the same fields as the Individual user registration page.
The user registration page for non-administrative business users is available by selecting the Register as a user of an existing company hyperlink on the Registration page. It includes the following data entry fields:
Business Information Section: This section includes only one field, for Registry ID (organization ID).
Personal Information Section: This section contains the same fields as the Personal Information section on the primary user registration page.
Non-administrative business users are not required to enter address data, since the company address is related to them in Oracle TCA.
Note the following additional details common to the registration pages:
You can mandate the entry of a business telephone number in the registration pages by setting the profile, IBE: Mandate Contact Business Phone, to Yes. See the appendix, Profile Options, for more information on the profile option settings.
In the telephone fields, Country Code is validated against the country codes present in the phone_country_code in the HZ_PHONE_COUNTRY_CODES table.
By default, when a user selects the Cancel button in a Registration page, the system takes the user to the Site Home Page (if site context is available) or to the Site Selection Page. However, if the cancel_url parameter is provided, then selecting Cancel takes the user to the URL specified. Additionally, if the app_id parameter is provided (for example, during Oracle iSupport registration flows), the Cancel button only displays if the cancel_url parameter is provided.
Merchants have the ability to offer Customer Application access to customers who already have placed an order with them through a selling channel other than Oracle iStore (e.g., through a call center). This functionality, known as Online Access to Existing Account, lets customers register for access to Oracle iStore site(s) without the need to duplicate existing accounts. Since these customers have a pre-existing business relationship with the merchant, they generally already have a financial account in Oracle TCA which Oracle iStore can use to recognize and validate them. Once registered, these customers have full access to the sites; they can place orders and view the progress of orders (even if placed through another channel).
Following is the business process flow:
A B2C or B2B customer has placed an order with the merchant company through some other avenue than Oracle iStore.
The customer navigates to the Oracle iStore Customer Application in order to view the status of his order or other relevant order information.
Oracle iStore displays the standard user type selection page which displays additional links for Online Access to Existing Account for B2B and B2C users. The customer selects one of the links, depending upon the user type he wishes to register as.
Oracle iStore displays the Online Access to Existing Account registration page that maps to the user type selected. The customer enters information which validates him as an existing customer (see the section, "User Interface Details", below, for more information). If the user is unable to enter the required information, he will not be allowed to proceed with the online access request.
The user enters the required information and submits the request, which is validated and treated as follows:
B2C User Data Validation: The system validates the following: (1) Whether the account number is not already associated with an existing user account; (2) Whether the zip code provided is a valid billing zip code associated to the account and was used in any previously placed order; (3) Whether the phone number provided is associated with the account number; and (4) Whether the username is unique and the password valid. If any of these items cannot be validated, the system displays an error message and returns the user to the registration page.
B2B User Data Validation: The system validates the following: (1) Whether the account number is valid and belongs to a B2B organization, and the order was placed using the account number entered; (2) Whether the contact, who is the sold-to contact in the order, is already associated with an existing user record; (3) Whether the order date matches the order number entered; and (4) Whether the username is unique and the password valid. If any of these items cannot be validated, the system displays an error message and returns the user to the registration page. Note that for order date, the system will perform a search between one day before and one day after the order date entered by the user.
Username Validation for B2C: If the username is already active, the following error message is displayed: "The account information provided already has an online username. Please login." If the username is inactive, the following error message is displayed: "Your online account has been inactivated. Please contact the System Administrator to activate it."
Username Validation for B2B: If approval status is not Rejected and the existing username is active, the following error message is displayed: "The account information provided already has an online username. Please login." If approval status is not Rejected and the existing username is inactive, the following error message is displayed: "You already have a user account. Please contact the System Administrator or the Primary User of your organization to activate it." If the approval status is Rejected, the user can register using a different username.
E-Mail Address Treatment: If the e-mail address entered is not the primary e-mail address stored for the user, the system marks the newly entered e-mail address as the primary e-mail address. The system retains the demoted e-mail address.
Inactive User Treatment: If a B2B user is found to already exist but is inactive, he is shown a message telling him to contact the primary user of his organization. If a B2C user is found to already exist in the system but is inactive, he is shown a message telling him to contact the system administrator.
If no registration approval is required, the user is logged in and shown the Customer Application default landing page. Oracle iStore sends a registration confirmation e-mail to the customer (see the chapter, Integrating Oracle iStore with Oracle Workflow, for e-mail notification details). If approval is required, the customer is shown a confirmation page and will need his registration approved before accessing the application, following standard user registration functionality.
Since the candidate already possesses a financial account, the system does not create a new financial account for Online Access to Existing Account registrations.
Additional Information: Usernames created through Online Access to Existing Account functionality are associated to sold-to contacts only.
When Online Access to Existing Account functionality is enabled, the user type selection page displays two additional links, one under the Individual user section and one under the Company section. Following is the wording of the links:
Individual Link: Need online access to your existing individual account?
Company Link: Need online access to your existing corporate account?
The registration pages are described below.
Note: The validation logic to verify the user's identity can be customized by mapping customized display and processing JSPs to STORE%PARTIAL%
display template keys, as appropriate. The processing page, after successful validation, must pass the following JSP parameters: username, password, e-mail and contactid, to the forwarded JSP (jtftmplh.jsp), where, contactid is the validated party_id of type, person (for B2C), and the validated party_id of type, party_relationship (for B2B).
The Registration For Individual Customer page displays after a customer selects the Need Online Access individual link. In this screen, the customer must enter the following information used for validating his customer status:
Verify Identity Section:
Account Number --- This is the account number used with the order.
Billing Zip Code --- The customer can enter any of the billing zip codes associated with the account number.
Business or Home Phone Number --- The customer can enter either his business or home telephone phone number associated with the account number. This should be the active telephone number attached to the party of type person (however, this phone number is not mandatory to place an order through other channels).
Create Username Section:
Username --- This field is validated against existing Oracle iStore usernames. If there is a duplicate match, the user is prompted to enter a different username. If the customer is recognized as an existing user, an error message will display.
Password/Confirm Password --- The customer enters a unique password.
E-Mail Address --- The customer enters his e-mail address, which is not validated against any record, but is validated for proper e-mail format.
The Registration For User of An Existing Company page displays after a customer selects the Need Online Access company link. In this screen, the customer must enter the following information used for validating his customer status:
Verify Identity Section:
Account Number --- This is the account number used with the order.
Order Number --- The customer must be the sold-to contact on the order.
Order Date --- This is the date that the order was placed. Note that when the customer enters a date, system will also search for the order date between previous date and the next date.
Create Username Section:
Username --- This field is validated against existing Oracle iStore usernames. If there is a duplicate match, an error message will display. If the customer is recognized as an existing user, an error message will display.
Password/Confirm Password --- The customer enters a unique password.
E-Mail Address --- The customer enters his e-mail address, which is not validated against any record, but is validated for proper e-mail format.
In each of the screens, the customers are given the option to opt-in/opt-out of marketing materials being sent to them.
With Online Access to Existing Account functionality, the following general user management assumptions are made:
Online Access to Existing Account is supported for B2C and B2B (including Oracle iSupport) users who have placed an order with the merchant (the B2B user must have placed the order as the sold-to customer).
Oracle Partner Management users are not candidates for this registration avenue. However, they can register as standard B2B users and then their primary user can add permissions at a later time.
Out-of-the-box, primary users cannot be registered with Online Access to Existing Account.
This functionality may not be available under certain conditions if your implementation is utilizing a Centralized Account Provisioning system (CAPs); see the chapter, Integrating Oracle iStore with Oracle Single Sign-On, for more information.
Oracle iStore lookups determine the grouping and display of Oracle iStore user types (B2C, B2B primary, B2B contact, partner primary, partner contact) in the registration or partial registration screens. The lookup code of these lookups should be mapped to the User Type Key of the Oracle CRM Technology Foundation user types. For a list of the lookups, see the chapter, Implementing Messages and Prompts.
While displaying the registration user-type listing page, if the system returns only one user type, then the user will be directly taken to the registration page for that user type.
The following table show the entities required for Oracle iStore individual (B2C) user types:
Individual User: B2C Entities | Required? | Comments |
---|---|---|
Active Username | Yes | If username is end-dated, an error will display. |
Active Person Party (i.e., an active record in hz_parties table with party_type as 'PERSON') | Yes | If this record does not exist, the user will have to do partial registration. If a party record exists but is inactive, an error message is shown. |
Record in Oracle CRM Technology Foundation (JTA) registration table (jtf_um_usertype_reg) for this user | Conditional | If the logged-in user has all of the above entities as valid or active, then:
|
The following table shows the entities required for Oracle iStore organization (B2B) user types (includes Oracle Partner Management user types):
Individual User: B2B Entities | Required? | Comments |
---|---|---|
Active Username | Yes | If username is end-dated, an error will display. |
Active B2B related TCA records (i.e., active records in hz_parties, hz_relationship tables, which identify and associate the B2B contact to his organization) | Yes |
|
Active Oracle TCA Account (i.e., active record in hz_cust_account_roles table for this party) | Yes | If this record does not exist OR exists but is inactive, the user will have to do partial registration. |
Record in Oracle CRM Technology Foundation (JTA) registration table (jtf_um_usertype_reg) for this user | Conditional | If the logged-in user has all of the above entities as valid or active, then:
|
Partner Profile for the Company | Yes | This association is essential for the Organization to be treated as a Partner Company. |
Permission PV_PARTNER_USER | Conditional | This permission determines whether the logged-in user is identified as a “partner business user” (if permission assigned) or “B2B business user” (permission not assigned) |
To implement Online Access to Existing Account functionality, you must enable the appropriate user types in the Oracle CRM System Administrator's Console user management module. Following are the user types that must be enabled:
IBE_INDIVIDUAL_PARTIAL: Activating this user type enables the Need online access to your existing individual account? link on the Registration page.
IBE_BUSINESS_PARTIAL: Activating this user type enables the Need online access to your existing corporate account? link on the Registration page.
For more information on the text lookups that correspond to these user types, see the chapter, Implementing Messages and Prompts. For more information on user data, see the appendix, Seeded User Data. For information on Oracle CRM System Administrator's Console, see the online help available through the System Administrator Console
Note that Online Access to Existing Account functionality is disabled when a Centralized Account Provisioning system (CAPs) is being used and the profile option, APPS_SSO_USER_CREATE_UPDATE, is Disabled.
Partial Registration allows users who are incomplete from an Oracle iStore perspective to complete registration and gain access to the sites. With Partial Registration, users who do not have an account or party associated with them can access Oracle iStore sites after entering some user data and having it validated. These users may have been created through some other avenue integrated with the Oracle E-Business Suite (e.g., through a Central Access Provisioning system used with the Oracle Single Sign-On Server) and may only have a username associated with them.
Before going through Partial Registration, these users can only perform guest user activities with in the Oracle iStore Customer Application (e.g., browse the catalog, add items to the cart); when they attempt to perform some activity that requires login (e.g., check out), they will be shown one of the user types corresponding to their user status. The user then selects the appropriate user type and registers for full access to the Customer Application.
Partial registration can be used in an implementation integrated with the Oracle Single Sign-On (SSO) Server or used in a non-SSO scenario. It is applicable to B2B, B2C, and Partner users.
Following is the process flow for Partial Registration. This flow assumes a Central Access Provisioning system (CAPs) is not being used.
As a prerequisite, a customer has been registered with a username in the Oracle Internet Directory (OID) or Oracle Technology Foundation (FND) tables. Additionally, it is assumed that the user data synchronization Oracle E-Business Suite and OID has been setup appropriately.
An authenticated (logged in) user approaches the Oracle iStore Customer application and browses the catalog. He attempts to perform a secure activity, such as checking out.
The system checks the user session to gather user information associated with the user, such as whether he is a B2C user, a Partner user, etc.
Based on the user information gathered, the system displays the user registration page with the appropriate links showing (see "User Interface Details", below).
The user selects one of the user types. The Confirm Registration page displays, with known user data pre-populated into the registration form. The user enters the remaining registration data.
The user submits the registration request. If auto-approval is being used, the user is taken to the page he was attempting to access before the system invoked Partial Registration. If his registration requires approval, he is shown the pending approval page and must wait for approval before accessing secure areas of the sites.
If a user's account is later revoked, he will be directed again to the Partial Registration flow.
When Partial Registration functionality is enabled, the user type selection page displays different user type selection links depending upon the known user data (e.g., which type of party, if any, is associated with the user, or if the user has any Oracle Partner Management responsibilities). The following table shows the behavior.
Known User Data | Link(s) Displayed |
---|---|
User with no party or B2C user | All user type links |
B2B user of a B2B company | B2B non-administrative and Partner primary links |
B2B user of a Partner company | B2B non-administrative and Partner non-administrative links |
Partner user of a Partner company | Partner non-administrative links |
Just as with other types of registration, each link on the Partial Registration screen is associated to a specific user type in the Oracle CRM System Administration user management console.
With Partial Registration, customers enter their registration data in the Confirm Registration screen.
The following tables show which content is displayed in the Oracle Workflow e-mail notifications with Partial Registration, when registration is set to either automatic approval or to require approval. The first table is for standard registration; the second and third tables, presented for comparison purposes, are for delegated user creation (e.g., when a primary user creates a user in the iStore user management pages). The last table shows the Partial Registration e-mail information.
Approval | Approval Required Section | Approval Not Required Section | User Credentials Section | User Credentials Section with Username Only |
---|---|---|---|---|
Required | Y | N | Y | N |
Automatic | N | Y | Y | N |
Approval | Approval Required Section | Approval Not Required Section | User Credentials Section | User Credentials Section with Username Only |
---|---|---|---|---|
Required | Y | N | Y | N |
Automatic | N | Y | Y | N |
Approval | Approval Required Section | Approval Not Required Section | User Credentials Section | User Credentials Section with Username Only |
---|---|---|---|---|
Required | Y | N | N | Y |
Automatic | N | Y | N | Y |
Approval | Approval Required Section | Approval Not Required Section | User Credentials Section | User Credentials Section with Username Only |
---|---|---|---|---|
Required | Y | N | N | Y |
Automatic | N | Y | N | Y |
Assuming the user types are enabled in the Oracle CRM System Administration Console, Partial Registration is already set up for use in your sites.
With the existence of a Central Access Provisioning system (CAPs), or for some other business reason, it may not be necessary to allow the creation or updating of users by primary users in the Customer Application. Implementers can disable the ability of primary users to create other users by setting the profile option, APPS_SSO_USER_CREATE_UPDATE, to Disabled. When this profile option is set to Disabled, the following occurs in Oracle iStore:
If CAPs also is disabled, all registration icons and links are disabled. If CAPs is enabled and APPS_SSO_USER_CREATE_UPDATE is disabled, the registration links are available. Selecting a link takes the user directly to the CAPs registration page.
In the user management pages, the primary user cannot create a new user in the Create Contact screen
All user data fields (such as start/end dates and password) are read-only; the primary user cannot update any user data.
If a user tries to invoke the Registration page by typing a URL or from a deep link, the system will show an error message in all cases except when a CAPs is implemented. If a CAPs is implemented, the system will take the user directly to the CAPs registration page.
If the Application SSO Login Type is set to SSO and the Application SSO Change Password URL profile is set to the URL of the specified password reset JSP for OID, the Profile icon will link to the central JSP instead of a link to the password JSP. In this case, instead of showing textboxes for password reset in the Profile, Personal Information screen of the Customer Application, iStore displays a link pointed to by the Application SSO Change Password URL profile. Ideally, this is done when SSO is enabled and this profile can point to the OID-DAS URL, as shown in the example below:
http://<oid-server-name>:<oid-server-port>/oiddas/ui/oracle/ldap/das/mypage/ChgPwdMyPage
See the Oracle CRM System Administrator's Guide for more information about the profile option.
Oracle iStore leverages a common Oracle Technology Foundation login screen where users can enter their usernames and passwords to access the Customer Application. The Login page is displayed under the following circumstances:
Registered user selects the Login icon
Registered or user guest user is prompted to sign in
Logged in user is prompted to re-authenticate (with re-authentication, no new session created or altered; just the password is checked)
The Login page displays the user name field, a password field, a Login button, a link to the forgot password feature, and a link to the new user registration page.
For information on the forgot password feature, see the "Setting up Self-Service Login Assistance" section within this chapter.
If a user attempts to log in and his password is expired, the Reset Password screen is launched.
An error message is displayed when the following information is invalid:
Username is inactive or end-dated
Password is invalid
User's account is invalid
User's organization is invalid or inactivated
Error messages may contain a reference code that the merchant can use to identify the problem.
Oracle iStore users can choose whether or not to receive marketing communications based on their registration with Oracle iStore. Users can specify their preference at registration and modify it later in their Profile, Preferences menu.
The opt out state is assumed unless a user explicitly opts in by selecting the Please send me e-mail about special offers and products checkbox and saving the preference (updating the page).
Opt in/opt out preferences are stored at the party level (party_id in TCA schema), using the table, HZ_CONTACT_PREFERENCES.
In Oracle iStore, there are two locations where users can select opt in/opt out preferences:
Unregistered user arrives at the Registration page; or,
Registered user navigates to the Preferences page within the Profile menu
In addition, primary users can update users' marketing opt-in/opt-out preferences in the user management screens.
By default, the opt in/opt out preference checkbox always is unchecked.
The label on the opt in/opt checkbox is Please send me e-mail about special offers and products, which has the AOL message key, IBE_PREF_OPT_IN_OUT.
Following is the opt in/opt out action in the HZ_CONTACT_PREFERENCES table, according to specific actions on the part of the user:
User Explicitly Opts In: If the user explicitly elects to Opt In and updates the page, then the Opt In preference is stored automatically in HZ_CONTACT_PREFERENCES table, Preference Code column, as a DO entry.
User Explicitly Opts Out: If the user elects to Opt Out and updates the page, then the Opt Out preference is stored automatically in HZ_CONTACT_PREFERENCES table, Preference Code column, as DO NOT
entry.
This section contains information for managing B2B users in the Customer Application.
In a typical setup, primary users manage other business users in their companies. Access to all of the user management screens is provided within the Profile, Administration pages. The Administration screens support the following functionality:
Contact and user management
User registration approvals
Role management
Account management
This functionality leverages Oracle TCA schema and the Oracle CRM Technology Foundation user management framework.
Contact and user management functionality provides primary users of a company with the ability to search contacts and users, create contacts and users for their companies, assign roles and sites that have access restricted by responsibilities, and assign accounts for users within their company. If you are integrating Oracle iStore with Oracle Partner Management, partner primary users can define partner profile attributes for a contact.
Both primary and non-primary users can self-register themselves. Once a user has registered, depending on the user type, an approval task will be generated and assigned to an approver. The approver is notified through Oracle Workflow that there are users that require approval. For a list of notification events related to registration, see the chapter, Integrating Oracle iStore with Oracle Workflow.
Primary users utilize the Pending Approvals page within the Customer Application Administration menu to approve and reject user registration requests for their companies. If a primary user is a part of an approval group, he will see all pending approvals within his approval group. Once all required approvals are granted, the user is notified via e-mail and given access to the system.
In the Oracle CRM System Administration Console, implementers can set up B2B user registration to require approval or not. Whether or not a user is automatically approved depends on the Approval by flag in the user type definition. In the sysadmin console, the Approval by flag can be set to:
No approval required: In this case, users are automatically approved
JTF User Approval: This is the default approval setup for B2B users.
Custom approval setup: You set these up by organization in the Approvals menu.
If you have set up B2B registration to require approval, then these users must be explicitly approved. Typically, a primary user (or multiple primary users) from the B2B user's company submits the approvals in the Oracle iStore user management pages.
New B2B users created by a primary user from the Contact Management screens will be automatically approved, if one of the below is true:
The primary user is the lone approver in the approval hierarchy. If there are any other approvers in the hierarchy, their approval is also necessary before the user is designated as approved.
In the approval hierarchy, only the user who is the JTF Primary User is set up as the approver, and the iStore primary users have the JTF_PRIMARY_USER_SUMMARY permissions (seeded by default in the primary user role).
When a user's registration request is submitted, the username entered is created in Pending status in the Oracle Technology Foundation tables (FND_USER table). Only upon approval is the username enabled in the system. Upon rejection, the username is removed from the system and can be re-used by this or another user. However, if a Partial Registration request is rejected, the username is not removed, nor is the user's contact information inactivated. If an Online Access to Existing Account user is rejected, the username alone is removed; the user's contact details will remain active.
For additional setup information, see the section, "Ensuring Proper Dependency Setup for User Management", within this chapter.
Users also can be created in the Oracle CRM System Administrator Console. See the online help available through the System Administrator Console for details.
Implementers can mandate that a business phone number is required when users are registered or a contact is created by setting the profile option, IBE: Mandate Contact Business Phone, to Yes. If the profile option is Yes, the company phone number is required in all of the user management screens that relate to registering, creating, or updating contacts and users. It is also mandated on all self-registration screens in the Customer Application. Relevant fields will be marked with an asterisk (*). See the appendix, Profile Options, for more information on the profile settings.
Non-administrative and primary B2B users can use the steps below to self-register using Oracle iStore's registration pages.
For Oracle Partner Management steps, see the Oracle Partner Management documentation and the chapter, Integrating Oracle iStore with Oracle Partner Management.
Note that this flow is the default setup for B2B users registering through Oracle iStore framework. See the section, "Ensuring Proper Dependency Setup for User Management", within this chapter, for information about changing the default configuration.
In the following flow, it is assumed that a Central Account Provisioning system (CAPs) is not implemented. For more information on registration in the event of a CAPs, see the chapter, Integrating Oracle iStore with Oracle Single Sign-On.
Steps
The user navigates to the Registration page via one of the methods described in the section, "Registering Using Oracle iStore".
The user selects the appropriate registration link, as described in the section, "User Type Registration Selections".
The user fills in the required registration data.
Optionally, the user checks the Opt In/Opt Out checkbox, Please send me e-mail about special offers and products.
The user submits the registration request. Subsequent activities are different for non-administrative and primary users:
For non-administrative users: Both the primary user for the registering user's company and the user himself receive an e-mail notifying them of the registration request. The primary user's e-mail informs him that the user has requested registration and needs approval or rejection. The registering user's e-mail informs him that his request has been received.
At this point, the user still needs to be approved before he has any access to the Customer Application. The primary user for the user's company can follow the steps in the section, "Approval of Self-Registered B2B Users", to approve or reject the user.
Following approval, the B2B user receives another e-mail notification informing him that his approval has occurred. If his registration has been rejected, he also receives an e-mail notifying him.
For primary users: By default, when this user submits his registration request he is automatically approved and immediately has full primary user permissions in the Customer Application.
Upon approval, a new Registry ID is created for the primary user's company in Oracle TCA schema. To find out his Registry ID, he can log into the Customer Application and navigate to Profile, Company Profile. The Registry ID is also sent to the primary user by e-mail, in the registration confirmation.
A new financial account also is generated for the primary user's company. To find financial accounts available for use, he can navigate to Profile, My Profile, Accounts.
The primary user receives an e-mail notification about his approved registration.
In the context of Oracle iStore, roles typically apply only to B2B users. B2B users can be either regular B2B or primary B2B users (unless integrating with Oracle Partner Management, in which case you may have partner regular and primary users; or if integrating with Oracle iSupport, similarly you may have iSupport regular and primary business users). Primary users have administrative abilities, including user management permissions and the ability to update company details in the profile pages. Regular B2B users have view-only permissions in the company Profile pages.
See the appendix, Seeded User Data, for a list of seeded roles and permissions.
If the seeded B2B user roles do not meet your business needs, you can create new roles with any combination of permissions.
Oracle iStore primary users can use the Contact Management and Role Management pages within the Customer UI Profile, Administration menu to create and manage users within their companies.
Rules Regarding Primary User Abilities:
Note: The following rules will not apply, of course, if you have customized your setup to support a primary super-user charged with managing users across organizations.
By default, a primary user can only perform user management tasks for other B2B users within his company.
A primary user can only award to others the roles that he possesses.
A primary user can only assign sites to others that he also can access.
The primary user can view and assign accounts belonging to his company, even if he is not assigned to them.
The Pending Approvals page allows primary users to:
Search for users requesting approval, request names, and approval types
Approve user registrations and enrollment requests
Reject user registration and enrollment requests
The pending approval table displays the following information:
Request Date: This is the date the request was initiated.
Requester Name: This is the username of the user requesting approval.
Contact Name: This is the name of the contact associated to the username.
Email Address: This is the e-mail address associated with the contact record.
Request Name: This is the registration name or enrollment name of the user type.
Approval Type: This will show either User Registration for a registration request, or Enrollment for an enrollment request.
Details Icon: Primary users can select this icon to view a summary of the user's information in a pop-up window.
Approvals displaying in the Pending Approvals page will be one of two types:
User Registration: This approval is initiated when a user self-registers
Enrollment: This approval is initiated when an enrollment has been created through the sysadmin console and needs approval
Note: Enrollment requests are not shown until the user registration request is approved.
Following are the conditions for the approvals to display in the Pending Approvals page:
Pending approvals display in the Pending Approvals based on the following criteria:
Only display approvals assigned to the logged in primary user.
Only display approvals of the same company as the logged in primary user.
If Approval Groups are being used, only display approvals assigned to the Approval Group (filtered by user's company) of which the logged in user is a part, and only if the user has JTF_PRIMARY_USER_SUMMARY permission. Out-of-the-box, the iStore primary user enrollment already is seeded with a role containing this permission. See the section, "Best Practice: Set up Approval Group", for more information.
If Approval Groups are being used, in addition -- if there are any approvals assigned directly to the user -- these are also displayed.
Primary users can approve user registrations and enrollments only if they are defined as approvers for their companies, for the approvals defined at the user type and enrollment level.
Primary users only have access to the Pending Approvals screen if they are associated to the permission, IBE_INT_PENDING_APPROVAL.
When approving users, if the user does not already have an account, by default, the system will generate an account for the user, in case of B2C users; in the case of B2B users, a new account is created for the organization, and further, account roles are created for the user. The primary user also can assign additional accounts to the user. Oracle iStore also allows primary users to remove accounts from users. See the section, "Approving B2B Users Who Have Self-Registered", for more information.
For information on assigning or removing accounts for B2B users in a post-approval scenario, see the sections, "Account Assignment After Approval" and "Removing Accounts from Users".
For registration rejection information, see the "Rejecting a Request" section, below.
To approve users:
Primary users sign in to the Administration page available within the Profile menu of the Customer Application (the user may first need to select a specialty site to access this menu). The Pending Approvals page lists pending user registration and enrollment requests in the Requests Summary table. Note that the Requests Summary table displays only requests that are associated to an approval process that the primary user has been assigned to. If the user belongs to an approval group, then pending approvals for the group also are displayed.
To approve a user request, the primary user first selects the request and presses the Approve button. This retrieves the Submit Approval Request page, which shows the user's information at the top and a list of available account numbers down below. The primary user can enter comments and associate the user with one or more financial accounts before submitting the request. If the request type is an enrollment, the Submit Approve Request page displays the appropriate enrollment information instead of user information.
Note: In the Approve Request page, the primary user can enter comments into the Comments textbox. In the case of an established approval hierarchy, if this user has already been approved by a different approver, the last approver's comments are displayed. If no hierarchy is set up, then no comments by other users are shown.
Once the primary user submits the approval, a confirmation message is displayed (if other approvers are required, a message displays to this effect) and the primary user is shown the Update User page, where he can continue to modify details about this user, including updating contact information and passwords and assigning roles, accounts, and site access. If there are multiple approvers, the system will display to the primary user the Update User page with a message indicating that the user request still needs to be approved by other users; in this case, the approval status will remain as pending in Update User page.
If the approval is for a user registration, the user is created and an e-mail sent to the user notifying him of his approval. If the approval is for an enrollment, the parameters defined in the enrollment are accomplished, and the primary user(s) are e-mailed about the approval.
To reject a pending request, in the Pending Approvals page, the primary user selects the radio button of the applicable request and then presses the Reject button. This retrieves the Reject Request page, which displays relevant user information (e.g., name, e-mail address) at the top and a Comments textbox down below. Any information the primary user enters into the Comments textbox is included in the e-mail notification sent to the user.
Upon rejection, the request is removed from the pending requests queue. However, the user still shows up as a contact in the Contact Management page.
The Contact Management page within the Profile, Administration menu allows a primary user to perform the following tasks:
Create new contacts or users
Search for users
Update user contact information and reset passwords
Modify the marketing materials opt-in/opt-out flag for users
View and modify role assignments
Approve or reject user registration requests
Assign accounts
Assign users to specific sites
Note that in a typical implementation, primary users can only view and modify users within their own organization. The Contact Management page displays all users who are parties belonging to the relationship types "contact of" and "employee of" for the primary user's company.
The Contact Management page presents user and contact information in the Contacts Summary table:
Contact Name: This is the combination of the first and last name of the party as defined in Oracle TCA.
User Name: This is the username associated to the contact.
E-mail Address: This is the e-mail address entered by the user during registration, or supplied for the user by the primary user.
Approval Status: This column reflects registration approval status and will show either Approved, Rejected, or Pending. It will be empty for a user who is a contact and not yet a user.
Status: This column, indicating whether the user is active or not, will show either Active or Inactive.
Update: The Update icon is a link to the contact/user details. The primary user can use the update pages to update contact/user information, and to convert registered contacts into registered users by awarding roles and accounts to them. For users whose registration approval is in pending status, the Update icon will be inactive. Those whose Partial Registration approvals have been rejected can still be updated as contacts by primary users; however, their user information is read-only. Those whose standard registration requests have been rejected will be shown as inactive contacts.
Note: In the case of Oracle Partner Management integration, a link to the Partner Profile for partner contacts and users is provided. Primary users can use the pages within this link to associate the user to a partner profile. The link to Oracle Partner Management is shown only when a Contact is selected and the Update Contact/User page is displayed.
In the Contact Management page, primary users can search for contacts and users with their companies. Following are the search options:
Contact Name or User Name --- The Search By LOV can filter the search by contact name or user name. The percent (%) sign can be used as a wildcard in the textbox.
Non-registered users filter -- Selecting the Show contacts not registered as users checkbox limits the search results to only contacts of the company that are not registered as users.
Note that primary users cannot find their own usernames, etc., in the search mechanism.
Primary users select the Create Contact button in the Contact Management page to access the Create Contact page where the can create a contact. Following are the data entry fields in this page:
First, middle, and last name
Email address
Business and personal telephone numbers, and fax number
Send e-mail about special offers and products checkbox to opt the contact in or out of being sent marketing materials
To register the contact as a user, the primary user would select Yes under Do you want to register this contact as a user?. See the "Creating B2B Users" section, below, for more information.
In the Contact Management page, primary users can select the Update icon for a specific use or contact to update details for that person. Following is the information the primary user can update:
Name: First, middle, and last name is updateable.
Telephone Numbers: Business and personal telephone and fax numbers are updateable.
Marketing Opt-in/Opt-out: The Send e-mail about special offers and products checkbox is updateable.
Default Currency: This LOV displays for partner users only.
Username and Password: If a username is already associated with this user, the primary user can only reset the password, and the username is read-only. If the user is not registered, then the primary user can assign a username and password to the user, after choosing to make the contact a user.
User Start Date and End Date: In the update screen, a start date and (optionally) an end date for the user are displayed.
Primary users can create new B2B contacts for their companies, if they have the IBE_INT_MANAGE_CONTACT permission in their user role.
For a list of permissions, see the appendix, Seeded User Data.
The primary user has the option of creating a contact or a user. A contact is characterized by contact information only; no username, password, roles, or responsibilities are awarded. When a user is created (with username and password defined), the party ID of the company is associated with an FND_USER. In Oracle TCA, contacts and users are created with an "employee of" relationship type of the primary user's company.
Steps
The primary user signs in to the Customer Application and selects a specialty site.
The primary user selects Profile, then Administration to retrieve the Contact Management page.
The primary user selects Create Contact.
The primary user enters the contact information.
Depending upon whether he is creating a contact or a user, the primary user selects either Yes or No for the option, Do you want to register this contact as a user?
If creating a contact, the primary user selects No and then selects Apply to save changes.
Note: To convert a contact to a user, the primary user accesses the Update icon for the user and follows the steps below.
If creating a user, the primary user selects Yes and then fills in the user information in the Registration area of the Update Contact page:
User Type: The administrative user selects either Administrator or Business user. When a primary user create a new user with the Administrator user type, the new user receives the standard privileges of this user, as defined by your implementation.
Note that the user types displayed in this page come from the extensible user type lookup, IBE_UM_STORE_USER_TYPES (if the primary user is a B2B user) or IBE_UM_PARTNER_USER_TYPES (if the primary user is a Partner user). An exception to this rule is that Need Online Access user type lookups are filtered out of the page. If you create custom user types, you can link them to the lookup and display the user type in this page, so that the primary user can also select the custom user type for the new user, and, therefore, assign the corresponding responsibilities and roles to the user. See the chapter, Implementing Messages and Prompts, chapter for the lookup seeded values.
Username: Username should be unique across all users, whether or not they belong to the same B2B organization.
Password: When a user is created, the password is set to immediately expire. When the new user logs in, he will be prompted to reset his password.
Primary Account: The primary user selects the primary account for the new user. If only one account is associated with the company, then only one account will display in the LOV.
Default Currency: Default Currency appears for partner users only. This field defines the default currency displayed in the opportunities summary tables.
Start Date and End Date: Start Date defaults to system date. End Date is optional. Note that a username can be end-dated and the contact associated with the record can still be active. Users cannot log in using end-dated usernames. If the selected user type requires approval, until the user is approved, start date and end date are set to GMISS_DATE; in this case, the user cannot log in until approved.
Note that the primary user can choose to inactivate the contact and continue creating the user. The user will not be allowed to log in as long as his status is Inactive.
The primary user selects Apply to save the changes. The user is automatically approved (if the implementation is set up for auto-approval), and an account number is assigned to him based on the primary account of the primary user. The default business user role and customer responsibility are assigned to the new user. The creation of the user generates the new user approval notification e-mail for the user; the approval e-mail displays username and password. If there are still other approvers above the current, logged-in primary user in the approval hierarchy setup, the new user created will still be pending for approval by the approvers in the hierarchy.
The user will be asked to enter a new password on attempting to access the Customer UI areas which require sign-in.
If Oracle Partner Management is implemented: The partner primary user can select View Profile to launch the partner profile page, where Partner primary users can view and update the contact partner attributes. This button is displayed only if a contact belongs to a partner company and is a primary user for the partner company.
Important: In the case of Oracle Partner Management integration where the user belongs to a partner company, the user must also be created as a CRM Resource. This is required to have this user recognized in the Oracle Sales framework. The Resource needs to be assigned to a Resource role, and the partner contact Resource needs to be defined as member of the partner company group. To achieve this automatically, Oracle iStore calls an Oracle Partner Management API; there is no need to do this manually.
For more information on setting up user approval functionality, refer to the following sections within this chapter:
"B2B User Registration Approval Options"
"Setting up Approval Denitions"
"Conditions for Approving Users"
Since the default business user role is automatically assigned when a B2B user is approved, then this procedure would be used to add additional roles to a user. Be sure the primary user granting the roles also has the new roles himself.
Steps
The primary user signs in to the Customer UI and selects a specialty site. He navigates to Profile, then selects Administration.
In the Contact Management page, the primary user selects the Update icon for the user, and then he selects Roles, Assign Roles.
Note that the roles available for assignment are limited to those not yet assigned to the user but already assigned to the primary user.
After marking the desired roles for selection, the primary user presses Select. The user to whom the roles are awarded can immediately utilize those roles.
Note that additional custom roles also can be removed from B2B users, as well as deleted from the application.
Primary users can associate other users in their companies to Oracle iStore sites. The sites that a user is associated with initially depend upon the responsibility associated to his user type and sites that have already been restricted by responsibility --- when a site responsibility and a user's responsibility match during registration, the user is assigned to the site.
The permission IBE_ASSIGN_SITES controls the appearance of this functionality. Partner primary users are not assigned this permission, since Partner Management does not allow manual assignment of sites access, because they assign responsibility programmatically through partner memberships.
Steps
The primary user signs in to the Customer UI and selects a specialty site. He navigates to Profile, and then selects Administration.
In the Contact Management page, the user selects the Update icon for the user, then selects Sites, Assign Access to launch the Select Sites page, where the primary user can view a list of candidate sites.
After marking the desired sites for selection, the primary user presses Select to apply the assignments.
The following rules apply when assigning sites:
Only sites that have access restrictions by responsibility are displayed in the list of sites for a user. Public (non-restricted) sites are not included in the list, since users can always access these sites, even when they are not assigned the appropriate responsibility.
Sites available for assignment are limited to those also available to the primary user.
The Search and Select Sites page performs a default search on sites assigned to the primary user.
If access is removed for a site, the responsibility assignment for the user is end-dated. If this responsibility is also associated to other sites, the user's access to these sites is removed. A warning message is displayed when this occurs.
In the case of Oracle Partner Management primary users, these primary users will not have access to this page, since the access to the partner sites is controlled through membership.
Account creation is not explicitly supported in Oracle iStore. No user can create accounts. Accounts are automatically generated by default, when users are approved. Primary users assign accounts to business users at approval time or through the Contact Management screens after approval.
Note: The primary user can assign all accounts for his company, even if the accounts are not assigned to him.
Use the following steps to assign accounts to Oracle iStore B2B users after approval.
For steps to assign accounts during approval, see the sections, "Account Assignment During Approval" and "Approving B2B Users Who Have Self-Registered".
Steps
The primary user signs in to the Customer UI and selects a specialty site. He navigates to Profile, and then selects Administration.
In the Contact Management page, the primary user selects the Update icon for the user, then selects Accounts, Assign Accounts. The accounts displayed are all those available and active for the company. The primary user will not be able to select account numbers already assigned to the user.
After marking the desired accounts for selection, the primary user presses Select to apply the selection.
Note that a user must possesses at least one account number to complete transactions.
To remove accounts from users within his organization, the primary user can do the following:
The primary user signs in to the Customer UI and selects a specialty site. He navigates to Profile, and then selects Administration.
In the Contact Management page, the primary user selects the Update icon for the user, then selects Accounts. All assigned accounts display for the user.
To remove an account, the primary user selects the Remove icon for the account number. A warning message is displayed, the primary user must confirm the remove action.
The Role Management pages let primary users:
View available roles and role permissions
Create new roles and assign permissions to these roles
Create, modify, and delete custom roles
Primary users can create new roles and assign permissions to these roles. Following are points of behavior:
The permissions assigned to custom roles can be altered.
After creation, the name and description of custom roles are non-changeable.
Seeded roles cannot be altered.
New custom roles are automatically assigned to all the primary users of the company
Steps
The primary user signs in to the Customer UI and selects a specialty site. He navigates to Profile, Administration, Role Management, Create Role.
The primary user enters a name for the role, optionally enters a description, and moves the desired permissions to the Assigned Permissions window.
Note that only those permissions assigned to the primary user will be available for him to select. For a complete list of permissions, see the appendix, Seeded User Data.
The primary user selects the Apply button to save the changes. A confirmation message is displayed.
To remove roles from users within his organization, the primary user can do the following:
The primary user signs in to the Customer UI and selects a specialty site. He navigates to Profile, and then selects Administration.
In the Contact Management page, the primary user selects the Update icon for the user, then selects Roles. All assigned roles display for the user.
To remove a role, the primary user selects the Revoke icon for the role. Note that no warning is given before the revoke action.
User and company information (for example, names, addresses, and phone numbers) is stored in the profile pages of the Oracle iStore Customer UI. Profile pages allow users to view, change, and maintain their user information. In the case of B2B users, access to their company's profile pages allows them to view organizational information, such as Organization ID/Registry ID, web site address, annual revenue, and a list of administrators -- and primary users of the company are allowed to update such data.
Profile page data is stored on the back-end in the Oracle customer model, Oracle TCA.
B2B access to many of the profile pages can be controlled through permissions within a user's role. See the section, "Configuring Profile Menus", within this chapter, for more information.
Note: By default, any user registering using Register as individual, Register your company, and Register as a user of an existing company user types will receive the same level of Profile page permissions in Oracle iStore.
Two important aspects of the profile pages are their consistent look and feel between integrating applications and their ability to be configurable by application. For example, if you are integrating Oracle iStore with Oracle iSupport and/or Oracle Partner Management, your end-users' profile pages will access a common set of screens provide by Oracle iStore, plus allow you to customize your own display of a subset of the profile screens. This customization ability is provided through Oracle iStore Template Manager -- since each profile page is derived from an Oracle iStore template, you can configure the display of the profile pages to suit your business needs.
For users of the integrating applications, the profile pages present and allow updating of personal and company information whether the users are logged into Oracle iStore, Oracle iSupport, or Oracle Partner Management.
This section contains information about the personal profile pages accessible through the Profile navigation icon.
Note: All information in this section related to storage of Oracle TCA data is relevant only to B2B users. B2C users' information is always stored at the person party ID level.
Within the Details link of the Personal Information page, users can record and update their own personal details, including:
Name -- This information is stored under HZ_PARTIES in Oracle TCA schema.
E-mail address -- Address entered will be the primary e-mail address for the user; stored under contact point of the party in Oracle TCA schema.
Password -- Users can reset their passwords in this screen.
Note on SSO Integration: If Oracle Single Sign-On (SSO) is enabled, this page will only display and allow update of the user's name and e-mail address -- password reset is provided through SSO; see the chapter, "Integrating Oracle iStore with Oracle Single Sign-On", for more information.
Note on Partner Management Integration: If integrated with Oracle Partner Management, two submenus display within the Personal Information page: Details and Profile. The Details page contains the functionality listed above, while the Profile page allows partners to update their profiles. The Profile link is enabled only for users possessing the required permissions (for example, those belonging to a partner company and associated to a partner profile).
The Contact Information page contains three submenus: Address Book, Email Address, and Phone Book:
Address Book --- Users can create, update and delete addresses in the Address Book page. Address information is stored in HZ_LOCATIONS, is associated to a party site in HZ_PARTY_SITES, and for B2B users is linked to the party ID or party relationship ID (Registry ID) in HZ_PARTIES.
Note on Address Usages: Oracle iStore supports only creating billing or shipping address usage types; however, other usages created in other applications (for example, a delivery address) will display and show their correct usage in Oracle iStore. Users can identify whether an address is preferred for that usage or not.
Address creation --- When B2B users create a billing or shipping address, it is related to the company. The primary address is defaulted into the shopping cart.
Preferred addresses -- Users can flag one billing and one shipping address as preferred. Oracle iStore then uses the preferred addresses when data is defaulted into shopping carts during checkout. Note that if a new address is created and marked as preferred, the previous preferred address is unmarked as preferred.
Deleted addresses --- Deleted addresses are end-dated in the database, not actually removed.
Note: If the B2B user does not have the IBE_CHANGE_BILLTO_CUSTOMER_ADDRESS permission, the address cannot be used as a preferred address, or for billing.
Email Address --- Users can create new e-mail contact points, or update existing e-mail contact points. Functionality is provided to allow users to set a primary e-mail address. If a primary e-mail address already exists and a user marks a new one as primary, the current primary e-mail address is unchecked and the new one becomes primary. If only one e-mail address is created, it is set as primary by default. Users also can select whether they prefer to receive an e-mail in HTML or text format. If not specified by the user, the primary e-mail address is the e-mail address first used during registration. Users can delete a primary e-mail address if they create another one and mark it as primary.
Phone Book --- Users can create new telephone number contact points, or update existing telephone number contact points. Functionality is provided to allow users to specify the type of number entered, such as mobile, fax, business, or home number, and to specify the country code used in the number. Users are allowed to flag one number as the primary number. Users can delete a primary telephone number if they create another one and mark it as primary.
In the Payment Book, users can create, update, and delete preferred credit card information. Oracle iStore validates the credit card information upon entry. The preferred credit card is used in defaulting in the checkout phase. Credit card information is stored in Oracle Payments schema, in the IBY_SECURITY_SEGMENTS table. Credit cards potentially can be organization-striped. If a user deletes a credit card marked as primary and then creates a new credit card, the new card number will be marked as primary automatically. The iStore user must turn off encryption and then switch it on to obtain the credit card information.
Oracle iStore supports multiple financial accounts per user, which can be viewed in the Accounts page. Users also can see and switch accounts in the Welcome Bin in the Customer UI. Only active accounts assigned to the user are displayed, as stored in the HZ_CUST_ACCOUNTS table.
Oracle iStore allows users to set a primary account in the Accounts page. The primary account is used as the default account for any transactions performed in the Customer UI. If the customer does not explicitly assign a primary account, then the account used as primary will be the account assigned during registration, with the first account number created taking precedence.
The account used during a user's session is called the session account. B2B users with multiple accounts can switch session accounts in the Customer UI pages through the Welcome Bin. Switching session accounts can allow a customer to complete and view transactions associated to other accounts. The session account for a B2B user is used at checkout and in viewing order details. However, even if an account number is used by the application as the account number for the user's login session, the user still must explicitly mark an account number as primary before it will be stored in TCA as the user's primary account number.
Note that because they do not have multiple accounts, B2C users will not see the Accounts page, nor will they be able to switch accounts in the Welcome Bin.
The Preferences page allows users to set communication preferences, orders preferences, and more.
Important: The Preferences page may include links to Sales and Support pages, if integrating with Oracle iSupport or Oracle Partner Management, and the user has the required permissions.
Following are the Preferences pages:
General Preferences --- This link always displays, regardless of any integration with other applications. The following options are available:
Date format -- A drop-down menu allows the user to select a date format for dates displaying shopping cart expiration values.
Preferred language for e-mail communications -- This preference sets the preferred language for e-mail notifications and enables smooth functioning of the Workflow directory. The preferred language is stored in the HZ_PERSON_LANGUAGE table. Initially, the language is the one defaulted during registration from the user's session language.
Marketing preferences -- Users can choose whether to receive marketing communications.
Order Preferences --- This link always displays, regardless of any integration with other applications. The following options are available:
Order Preferences --- Users can select a preferred support level and a preferred shipping method. Users also can create shipping and billing addresses to be used when placing orders. Note that if a B2B user changes a shipping or billing address and there is no value in the Contact column, this means that the address is a company address and not a personal address.
Express Checkout Preferences --- The Enable Express Checkout checkbox allows users to turn on or off Express Checkout. Note that users must first set up preferred shipping and billing addresses and record valid credit card data in the Express Checkout Preferences area before Express Checkout will function properly. The preferred shipping method set in the Order Preferences page is used as the default shipping method for Express Checkout. If Express Checkout is enabled and the preferred shipping method is not selected, a warning message displays, telling the user to select a preferred shipping method.
Support Preferences --- Provided by Oracle iSupport, this page allows users to select subscriptions, indicate preferred days to receive e-mails, and set the user signature for forums. A user must have the required permissions to see this page.
This section describes the company profile pages accessible through the Profile navigation icon.
Note that in the case of integration with Oracle iSupport or Oracle Partner Management, B2B and partner users can access the same company profile screens, whether logging in from iStore, iSupport, or Partner Management.
Note: All information in this section related to storage of Oracle TCA data is relevant only to B2B users. B2C users' information is always stored at the person party ID level.
Business and partner users (if Oracle Partner Management is integrated) can view company details in this page, if they have the permission IBE_INT_ORG_DETAILS in their user role.
Note that B2B users with the IBE_INT_UPDATE_ORG_DETAILS permission in their user roles can also update the company details information.
The following is displayed for company information:
Company Name --- The company name is stored as the party name of party type organization, in HZ_PARTIES.
Registry ID --- This read-only field displays Organization ID/Registry ID in the Oracle TCA schema. Stored as party number in HZ_parties for the party of type, organization. TCA for the All B2B users can view the Organization ID. This would be useful, for example, if primary users need to communicate this information to non-primary users who wish to register.
Annual Revenue --- This field, updateable by primary users with the required permission, shows annual revenue of the company.
Currency --- Primary users can select a currency to associate to the annual revenue entry. The currency drop-list will show all currencies enabled in Oracle General Ledger, along with the description of each currency.
Total Employees --- This field, updateable by primary users with the required permission, shows total employees in the company.
Year Established --- This field, updateable by primary users with the required permission, shows the year the company was established.
Web site --- This field, updateable by primary users with the required permission, indicates the website URL of the customer's company. If defined, the website icon is enabled and user can select the icon and launch the website in a new browser window.
Important: In the case of integration with Oracle Partner Management, the Profile link also appears, allowing access to partner profile attributes. (Partner profile attributes are configurable at implementation time; see the Oracle Partner Management documentation for details.) B2B and partner primary users can update the company details and the partner profile attributes if assigned the appropriate permission. Non-primary users should not be assigned this permission.
In the Contact Information page, business and partner users (if Oracle Partner Management is integrated) can view the company address book, e-mail addresses, phone numbers, and telex numbers.
Notes Regarding This Functionality:
View permissions for company contact information are awarded through the following permissions: IBE_INT_ORG_DETAILS, IBE_INT_ORG_ADDRESS_BOOK, IBE_INT_ORG_EMAIL_ADDRESSES, IBE_INT_ORG_PHONE_NUMBERS, and IBE_INT_ORG_TELEX_NUMBERS.
Only B2B users with the IBE_INT_MANAGE_CONTACT_INFO permission can create, update, and delete addresses and company contact points. Users without this permission will not see the corresponding create, update, and delete functionality.
Note that with addresses, preferred and primary have different meanings -- preferred is a user-defined preference for use, while primary is associated to the usage of the company address in Oracle TCA. When a company's primary user registers the company for the first time, the address he uses as the company address is marked as the primary address for the company.
One primary identifying address must always be available in the corporate address book. Users are never allowed to delete the primary company address, and the Delete icon is disabled for the primary identifying address.
Contact information includes:
Company addresses --- Displays address information of the company. The address list displays all addresses associated to the party organization, regardless the usage of the address. Displayed are:
Address -- The address list displays all addresses associated to a user's party, regardless the usage of the address. At least one address needs to be defined as primary for the company. To update or delete an address, users with the required permission will be able to access the Update and/or Delete icon in the address table row.
Address type -- Stored in HZ_PARTY_SITE_USES, this field displays all the business purposes of the address and indicates whether they are primary or not.
City, state and zip code
Country -- The country selection determines the address style the user needs to follow when creating a new address.
Company e-mail addresses --- Business and partner users can view, update and create new e-mail addresses for a company if they have the correct permission in their user roles. Users are allowed to set a primary e-mail address. If a primary e-mail address already exists and a user marks a new one as primary, the current primary e-mail address is unchecked and the new one becomes primary. If only one e-mail address is created, it is set as primary by default. Users also can select whether they prefer to receive e-mail in HTML or text format.
Note that e-mail addresses created for B2B users are not the same as those created for a company.
Company phone and telex numbers --- Business and partner users can view, update, delete, and create new phone and telex numbers for a company.
Business and partner users can view the list of their company administrators, if they have the permission IBE_INT_ADMINISTRATORS. The list of administrators includes only those users who are primary users of a company.
Partner users can view the list of channel managers assigned to their companies, if they have the permission, PV_CHANNEL_TEAM, in their user roles. This screen is provided by Oracle Partner Management, and this link is provided only if your implementation is integrated with Oracle Partner Management.
Partner users can view the list of partner programs related to their companies, if they have the permission, PV_VIEW_MEMBERSHIPS, in their user roles. This link is provided only if your implementation is integrated with Oracle Partner Management.
Oracle iStore's user framework allows you to configure the user Profile and user management menus to suit your business needs. This flexibility is useful for implementers who wish to control access to specific screens by specific user types and for users of different applications.
Access to functionality within each screen is controlled through roles associated with each user. Each permission within a user role is associated to a function which renders a portion of a menu. Roles are collections of privileges, and by creating custom roles and then limiting the permissions within these roles, administrators can control access to page elements. In addition, the menu rendering framework supports syntax which can restrict or allow users by users type (B2B or B2C).
At runtime, Oracle iStore's menu rendering framework filters out all functions to which the user has no access.
Each function linked to the Profile menus can have specific levels of access control. Oracle iStore supports the access control scenarios shown in the following table. This table also shows the syntax to use for web HTML functions in the supported scenarios.
Case | Scenario | Web HTML Syntax for Functions |
---|---|---|
1 | No permission check | a.jsp |
2 | No B2C users can access the page Only some B2B users (with correct permissions) can access the page |
a.jsp?pcc=<permisson _code>&utc=b2b |
3 | All B2C users can access the page B2B users (with correct permissions) can access the page |
a.jsp?pcc=<permisson_code>&utc=b2c |
4 | All users (regardless of B2C or B2B) with specific permissions can access the page | a.jsp?pcc=<permisson_code> |
Use the following guidelines to assist your setup:
In order for the Oracle iStore menu rendering framework to know which permission and which user type is linked to each function, each function should append the permission code and user type to its web_html definition. See the above table for supported scenarios and syntax. For security reasons, when the Oracle iStore framework renders the menu, it hides the permission code in the UI.
Profile menus are consistent across all sites, regardless of which responsibility is associated to the site. Therefore, if you configure the Profile menus, the configuration will affect all of your sites.
You cannot entirely turn off a user's ability to see some Profile information. At a minimum, users will be able to see the My Profile menu within the Profile area.
Common screens associated to common permissions (those with INT in their names) can be assigned to Oracle iStore, Oracle iSupport and Oracle Partner user roles.
Profile screens that are application-specific should only be associated to permissions and roles owned by the integrating applications. For example, only Oracle iStore users who have been granted the business user role can access the company profile screens. Only Oracle iStore users that have been granted the primary user role can access the administration screens.
All Profile pages are identified as secure pages.
You may use the following steps to configure the profile menus for different responsibilities. For complete information on Oracle Applications menus functionality, see the Oracle E-Business Suite Setup Guide.
Using Oracle Applications (FND) menus functionality, create a new profile menu tree.
Link the profile menu to the user menu of the responsibility, IBE_CUSTOMER.
For performance reasons, the profile menu root must be set up directly under the responsibility menu root, at the second level of the entire menu tree.
Set the profile option, IBE: Use Profile Menu, at site level to the new profile root menu. This will override the seeded Oracle iStore profile menus attached to IBE_CUSTOMER responsibility.
If customers forget their user names or passwords, they can select the Forgot Your Username/Password information? link in the Login page to retrieve their login information. Oracle iStore Alert Workflow sends the seeded Forget Login e-mail notification to the user with his username and password.
Important: If your implementation is integrated with Oracle Single Sign-On (SSO), then the password assistance feature is provided through the SSO server. In this case, Oracle iStore's Forgot Password e-mail notification is not used. See the chapter, Integrating Oracle iStore with Oracle Single Sign-On, for more information.
Following is the process flow for Self-Service Login Assistance:
The user selects the Forgot your Username/Password information? link in the Login page. The Login and Password Assistance page opens.
In this page, the customer can enter:
Username
E-mail address
Username and e-mail address
Note that if Oracle iStore cannot find a unique match for either username or e-mail address, then the user must enter both values.
If a user does not remember either username or e-mail addresses, he must contact the site administrator to reset the password.
User submits the request.
If the user has entered username only, Oracle iStore validates the username in the database. If a record of the user name exists, the application resets the password and e-mails it to the customer using the seeded Forget Login notification message. If a record of the user name does not exist, an error message displays.
If the user has entered username and e-mail address, Oracle iStore validates the user name and e-mail address combination in the database. If a record with the combination exists, the application resets the password and e-mails it to the customer using the seeded Forget Login notification message. If a record with the combination does not exist, an error message displays.
If the user has entered an e-mail address only, Oracle iStore validates the e-mail address in the database. If only one record with the e-mail address exists, the application resets the password and e-mails it to the customer using the seeded Forget Login notification message. If no record with the e-mail address exists, an error message displays.
If more than one record with the e-mail address exists, the application prompts the customer to enter a username. The application then validates the user name and e-mail address combination in the database. If the combination exists, the application resets the password and e-mails it to the customer. If the combination does not exist, an error message displays.
The following diagram shows the process flow that Oracle iStore follows to retrieve a user's login information.
Process Flow for Self-Service Login Assistance
See the chapter, Implementing Messages and Prompts, for details on how to access and modify the messages associated with this process.
Here is an example for the setup steps used for creating additional contact and customer relationships. In this case, using Oracle iReceivables as a reference application to perform the data relationship setup.
Prerequisites: The IBE: Enable Multicustomer Access profile option must be enabled at the Site, Application or Responsibility level.
Use the following steps to assign existing contacts to additional customers as a self service user.
Navigate to the Customer Maintenance page in Oracle Receivables.
First, identify the customer which employs the existing contact. This contact would be designated as the From Customer Contact. In Customers tab, select Customer Type, enter search criteria and click Go. The search result is displayed.
Select a customer. The Accounts section displays accounts available with the customer. Click Details for more information on an account.
Select Communication tab. The Account Contacts list is displayed.
Click Details of the account contact to be used. Note the details of the account contact identified as the From Customer Contact. You would now assign this contact to another customer.
Navigate back to the Customers tab. Search for an existing customer, the To Customer, that would receive the new Self Service User relationship with the From Customer Contact.
The available accounts for the To Customer are displayed below.
Click Details icon for more information on an account for the To Customer. Select Communication tab.
Click Create Contact. Enter the same contact details as the From Customer Contact.
Click Apply. The Create Account Contact page appears.
Click Use Existing Person. In the resulting Select Focus region, select the option which corresponds to the From Customer Contact.
In the Account Contact page for the To Customer, click Add Another Role in the Contact Roles region. Select Self Service User from the Role menu.
Click Apply.
In the Account Detail page, click Apply to save the account and contact role relationship for the To Customer.
Using Oracle Customers Online as a reference application, you can verify the data setup for a Self Service Contact Relationship:
In the Customers tab, Organizations subtab, enter details of the To Customer defined earlier in the Simple Search region and click Go.
Click To Customer link.
The customer overview page appears. Click Visualize Relationships.
The From Customer Contact now displays a Has Contact relationship with the To Customer.
When accessing the iStore application as a From Customer Contact B2B user, the Welcome Bin displays the default customer to which you have access. If you have been granted access to more than one customer, a magnifying glass icon is displayed in the Welcome Bin to switch customers and accounts, provided the IBE: Enable Multicustomer Access profile option has been set appropriately by the System Administrator.
Use the following procedure to switch the customer and account context for the current iStore application session:
Log in to the iStore Customer application as a B2B user.
The Product Catalog page appears. The Welcome Bin displays the default customer and account.
If you have access to more than one customer, click the magnifying glass icon in the Welcome Bin. The Search and Select Customer page appears.
Search and select a customer and account. The selected customer and account becomes the active customer and account for the current iStore application session. You can now place orders and view order history on behalf of this new customer account.
On returning back to the Product Catalog page, the Welcome Bin displays your current customer and account context.
Note: The switch-to customers and accounts relationship is used only in the duration of your current iStore application session. When you log out and log in later into the iStore application, your default customer and account is used. The switch-to customers and accounts are not saved from the prior iStore application session.