Main

April 03, 2007

Implementing Oracle Applications i Modules

Implementing Oracle Applications i Modules

The latest release of Oracle Applications 11i and the current Release 12 include a number of i modules which have been included. These of course may require separate licenses before you can implement them.In my current post today i will talk about implementing these imodules from an APPS DBA view point.
imodules are de abbreviated as internet modules. As the name suggests these modules are internet enabled out of the box. They are mostly developed on the in line with the Oracle Self Service Web Applications. These modules are essentially targeted at the external customers of the organization who use the Oracle ebusiness suite, though at times we do have internal users 
also accessing these imodules.

Each of these imodules belong to a family of Oracle Applications product for example isupplier belongs to the purchasing family.

The various imodules that release 12 offers are

  • iStore (Order Management)
  • iSupplier (Purchasing)
  • iProcurement (Purchasing)
  • iReceivables (Financials)
  • iExpenses (Financials)
  • iAssets (Financials)
  • iRecruitment (Human Resources)
  • iLearning (Learning Management)
  • iSupport (Service)

DMZ Configuration
DMZ stands for a De Militarized Zone. It is that portion of an organizations network that is outside the internal firewall or outside the Secure or Militarized Zone. Since the main users of your imodules would be the external users. you would require to implement a DMZ configuration with Oracle Applications so that your external users can access your E Business Suite. There various methods and architectures which can be used to implement at DMZ within Oracle Applications. You could also have multiple URLs for your internal and external users in a DMZ configuration. For more details you can refer to the metalink Note Oracle E-Business Suite 11i Configuration in a DMZ Note ID (287176.1).

Security
A major and immediate risk of exposing your applications to the external users is of security. Once you have setup up your  applications to be internet enabled, you must take immediate steps to secure your applications before going live. There are various certified methods of implementing security in a DMZ environment. like Implementing SSL, Implementing an external 
firewall, implementing a reverse proxy between the external users and the external web server. To know more about securing your Oracle Applications environment you could refer to the metalink note Best Practices for Securing Oracle E-Business Suite - v2.1 (Doc ID: 189367.1).

Pre requisites
If you are on the latest release of Oracle Applications then generally the only pre requisite you have before you can implement the imodules is that you must have the corresponding family fully installed and setup. For example to  implement iSupplier in Oracle Application 11.5.10.2 is that you must have first installed and implemented Oracle Purchasing. In previous releases of Oracle Applications you might have to apply additional patches using adpatch or splice in new products through adsplicer.

User Administration
Since the imodules will also be accessed by external users the administration for the external users can be setup differently. Generally you can have a customized self service user registration screen for registering your external users. An example of an iSupplier Self Service registration is shown below.



Users Access
You must set up responsibilities for your External and Internal users explicitly. You must flag the external users responsibility. In this case only these set of responsibilities would be accessible to the external users thereby enhancing your application security. The imodules also comes with seeded responsibilities for the internal users like the iSupplier Portal Internal View. In case you want to give your internal users access to these imodules you must assign them these 
responsibilities manually.

November 03, 2006

Oracle Application Implementation Methodology

Oracle Application Implementation Methodology

To achieve a successful implementation of Oracle Applications a number of methodologies have been formulated. These are driven by industry case studies and past experiences. Many of them are based on the rich user experiences shared in various user groups and special interest groups. Among them Oracle's Application Implementation Methodology is one of most mature and 
proven one. Although AIM is not the only approach vouched by Oracle. It also has a Oracle Fast Forward approach which  focuses on rapid implementation of Oracle Applications. During one my recent projects i had a chance to work with the  Application Implementation Methodology approach, and i must say at the end of the day i was pleasantly surprised.

The Oracle Application Implementation Methodology (AIM) is a proven approach for implementation Oracle Applications across  business domains. This approach has been developed by oracle in constant collaboration within its partner network.

According to oracle "AIM provides the tools needed to effectively and efficiently plan, conduct, and control project steps to successfully implement new business systems."

The AIM is delivered in the form of a software bundle that packages the various document templates which have been identified as deliverables under the AIM approach. These are in the form of easily editable Microsoft documents like word, excel and mpp documents.

The Software is currently available only to Oracle Partners through the Oracle Partner Network (OPN).The software installation itself is quite simple and gets running within a few clicks.
The software presents a graphical user interface running within a web browser allowing you to browse though the various  deliverables.

Although most of the deliverables are focused on the functional domain areas. There also quite a few deliverables for  the Oracle Applications DBA /Technical Architect which have been identified in AIM.In my current post i will be focusing on these deliverables only.

The AIM approach has been divided in the various phases, which are

  • Definition
  • Operational Analysis
  • Solution Design
  • Build
  • Transition
  • Production

Below i will discuss the deliverables required under each of these phases from the Applications DBA/ TA .

Definition

The main deliverables that are defined under this stage are

TA.010 Define Architecture Requirements and Strategy
The focus of this document would be to provide the technical architecture and strategy that will be implemented to achieve a  successful implementation of the project.

TA.020 Identify Current Technical Architecture
The scope of this document included to understand and identify the existing application. interfaces networks and hardware  configurations.

TA.030 Develop Preliminary Conceptual Architecture
The objective of this task is to develop a conceptual architecture that will best fit the business objets taking into consideration the project constraints.

Operations Analysis
The main deliverables that are defined under this stage are

TA.050 Define System Availability Strategy
The focus of this document/task is to identify a system availability strategy for business. in case business require high  availability a strategy should be specified here to address it.

TA.070 Revise Conceptual Architecture
Under this task you revise the conceptual architecture you delivered as part of your TA. 30 to incorporate new requirements or findings.

Solution Design
The main deliverables that are defined under this stage are

TA.080 Define Application Security Architecture
The objective of this document is to incorporate application and database level security requirements in your architecture that have been identified by the business.

Build
The main deliverables that are defined under this stage are

TA.090 Define Application and Database Server Architecture
In task you design the new logical and physical architectures for the database tier and the application server tier, which has been conceptual so far.

TA.100 Define and Propose Architecture Subsystems
This document should focus on the requirements for additional components which may not have been a part of the initial plan.

TA.110 Define System Capacity Plan
Under this document you define the capacity plan for your system bearing in line with the business growth.

TA.120 Define Platform and Network Architecture
This document takes care of your Operating system and network architecture of your system.

TA.130 Define Application Deployment Plan
This document covers the deployment plan and installation of your application as according to the defined architecture.

TA.140 Assess Performance Risks
This document should cover the potential risk to your applications and ways to mitigate them.

TA.150 Define System Management Procedures
The scope of this document includes to cover the procedures maintenance of the application .

Transition
The transition phase does not have any deliverable particular to the DBA/TA.

Production
The main deliverables that are defined under this stage are

PM.140 Propose Future Technical Direction
The focus of this document is to identify innovations and software enhancements with respect to performance efficiency and functionality. Ideally the project manager and the DBA would work in collaboration to deliver this document.

While concluding the post i will like to reiterate that the scope of AIM approach is much more than what has been described in this post. The main aim has been to concentrating on the DBA/TA deliverables within AIM.