KentW Limited

This article applies to version 12.0.4.

I recommend you to start with this article to get R12 up and running.

Download

• Oracle E-Business Suite – EBS
  from http://edelivery.oracle.com/
• Rapid Install patch 6919017
  from http://metalink.oracle.com

Transfer Files

Boot into Ubuntu and transfer files to the /oracle partition for example /oracle/install

Unzip

Boot into OEL and login as oracle.

Alternatively you can unzip from NTFS to /oracle using Ubuntu but be sure to set file ownership correctly when in OEL:

$ chown –R oracle:oracle /oracle

Unzip EBS files into /oracle/stage:

$ ./unzip.sh V*

Unzip patch 6919017 into /oracle/stage

$ ./unzip.sh p6919017*

I used this script (unzip.sh):

Also I had a bug once caused by security issues in the stage directory – to fix do this:

$ chmod –R 777 /oracle/stage/startCD

Install

Always do this in OEL as the oracle user.

Many other people has described this process for example:

http://newappsdba.blogspot.com/2008/10/walk-through-installing-r12.html

Use /oracle as base directory though. This will create EBS in /oracle/VIS.

This directory can easily be moved around to different disks as long as you keep the mount point to /oracle.

I call the rapidwiz using a script – useful if you have to restart:

This article applies to OEL 5.3.

I recommend you to start with this article to get R12 up and running.

This flavour of Linux is based on Red Hat Enterprise Linux 5 (RHEL5) so if you can’t find the answer here google for RHEL issues instead.

Having played around with this operating system for a while I have to say the only reason I would use this is to get EBS up and running. For any desktop work I will stick to Vista SP1. If you are bitten by a mad Linux I would recommend Ubuntu – but I would not try to install EBS on Ubuntu – stick to OEL. OEL installation failed to recognise video, sound, wireless and Network card amongst others when installing directly on my laptop. Got network up and running by downloading and installing a driver though.

I can recommend installing VirtualBox and installing on an external USB drive to avoid overwriting your existing operating system by accident.

Files

Put all below in same directory on your laptop:

Download:

• Oracle Enterprise Linux 5.3 – OEL (yes, it is certified and all that)
  Enterprise-R5-U3-Server-i386-disc1.iso
  Enterprise-R5-U3-Server-i386-disc2.iso
  Enterprise-R5-U3-Server-i386-disc3.iso
  Enterprise-R5-U3-Server-i386-disc4.iso
  Enterprise-R5-U3-Server-i386-disc5.iso
  from: http://edelivery.oracle.com/linux
• OEL additions (have no idea why they didn’t include this in OEL)
  openmotif21-2.1.30-11.EL5.i386.rpm
  xorg-x11-libs-compat-6.8.2-1.EL.33.0.1.i386.rpm
  binutils-2.17.50.0.6-6.0.1.el5.i386.rpm
  from: http://oss.oracle.com/projects/compat-oracle/files/Enterprise_Linux

Extract OEL libraries from OEL discs (easily done by mounting ISO image in VirtualBox):

• Enterprise-R5-U3-Server-i386-disc3.iso
  libXp-1.0.0-8.1.el5.i386.rpm
  sysstat-7.0.2-3.el5.i386.rpm

From metalink get:

• Download p6078836_101330_LINUX.zip
  from http://metalink.oracle.com search for p6078836

Virtualbox

Create a VirtualBox machine and add all ISO as CD images and select first CD image:

Note the active filter for external USB hard disk.

If you downloaded the files on XP or VISTA then create another Virtualbox machine and install Ubuntu on this so you can transfer files between NTFS and EXT3 partitions.

Install

Start the OEL Vbox machine and boot into the CD:

Click next a few times (pick the options that suit you) until you get to the Partitioning screen:

If you use default setup you will get Logical Volume Manager setup which is less compatible.

I recommend to create 3 fixed partitions:

/ (boot): 10Gb

Swap: 5Gb

/Oracle: around 240Gb (180Gb for VIS and 40 Gb for stage directory)

If you also want the downloaded ISO disc EBS files and OEL files on this add 40Gb and 3Gb

Click next a few more times and pick “software development” as default installation type.

One more next click and the installation starts.

When done OEL want to restart.

Don’t do that – yet.

Shut down the OEL virtual machine.

Patching

This is where it gets complicated.

I used Ubuntu on a USB 8Gb stick to move files around with between NTFS and EXT3 – but you can also use Ubuntu on Virtualbox.

What you need to do is to put the installation and patch files on the new /oracle partition.

I use a subdirectory: /oracle/install

So copy like this is you use Virtualbox and Ubuntu:

BOOT Ubuntu and mount the shared folder:

$ sudo mkdir /mnt/oraclesrc
$ sudo mount –t vboxsf oracle /mnt/oraclesrc

Then copy to the external USB drive.
$ sudo cp –au /mnt/oraclesrc /media/oracle/install

The OEL partition /oracle gets auto mounted into /media

Or if you boot using a Ubuntu USB stick:

$ sudo cp –a /media/oraclesrc /media/oracle/install

REBOOT and boot into OEL

Login as root

All OEL installation should be done as the root user.

You need to install the additional components needed according to Oracle® Applications Installation and Upgrade Notes:

The following i386 packages are not part of the OS distribution media and must be downloaded separately (from http://oss.oracle.com/projects/compat-oracle/files/Enterprise_Linux for both OEL 5 and RHEL 5) and installed manually:

• openmotif21-2.1.30-11.EL5.i386
• xorg-x11-libs-compat-6.8.2-1.EL.33.0.1.i386
• binutils-2.17.50.0.6-6.0.1.i386

The following i386 packages must be installed from the OEL 5 or RHEL 5 distribution media:

• compat-glibc-2.3.4-2.26
• gcc-4.1.2-14.el5
• gcc-c++-4.1.2-14.el5
• glibc-2.5-12
• glibc-common-2.5-12
• glibc-devel-2.5-12
• libgcc-4.1.2-14.el5
• libstdc++-devel-4.1.2-14.el5
• libstdc++-4.1.2-14.el5
• make-3.81-1.1
• gdbm-1.8.0-26.2.1
• libXp-1.0.0-8.1.el5
• libaio-0.3.106-3.2
• libgomp-4.1.2-14.el5
• sysstat-7.0.0-3.el5
• compat-libstdc++-296-2.96-138
• compat-libstdc++-33-3.2.3-61

The ones I recommended to extract should be enough but if a package is missing – extract it from the CD-ROM ISO file.

You can mount the image using Ubuntu and Virtualbox.

Another way is to mount the ISO file directly in Linux using:

$ mkdir /mnt/cdrom
$ mount –o loop {isofile} /mnt/cdrom
$ cp /mnt/cdrom/server/{rpmname} /oracle/install/oel5.3

This is just tedious work using:

$ rpm –i {rpmname}

But you also need to do it in correct sequence as there is dependencies.

I created a script for this (supplied as is – as I know it is flawed) – see this link

Kernel Update

When booted into OEL you can update the OEK kernel with the following minimum parameters – again from:

Oracle® Applications Installation and Upgrade Notes

First make a backup copy of /etc/sysctl.conf and then modify.

Then to update the kernel run the command:

$ sysctl –p

Then reboot. Yes, that happens in Linux as well.

Hostname and ip

Verify that the /etc/hosts file is formatted as follows:

127.0.0.1 localhost.localdomain localhost

::1 localhost.localdomain localhost

<ip_address> <node_name>.<domain_name> <node_name>

or

<ipv6_address> <node_name>.<domain_name> <node_name>

The last ::1 line is needed for the new sqlnet in 11g – otherwise your connections will slow down making startup and shutdown take forever. All thanks to ipv6.

Verify that the /etc/sysconfig/network file is formatted as follows:

HOSTNAME=<node_name>.<domain_name>

If the /etc/sysconfig/networking/profiles/default/network file exists, remove it.

If you changed any files in the previous steps, restart the system

Patch 6078836

Unzip /oracle/install/oel5.3/p6078836_101330_LINUX.zip and:

$ cp /oracle/install/oel5.3/6078836/libdb.so.2 /usr/lib

Motif fix

Link to Motif library for Oracle Application Server 10.1.2 (on OEL 5 and RHEL 5 only)

Perform the following command (as root on your system) to update a required link to a Motif library prior to relinking or patching the 10.1.2 Application Server Oracle Home:

$ unlink /usr/lib/libXtst.so.6
$ ln -s /usr/X11R6/lib/libXtst.so.6.1 /usr/lib/libXtst.so.6

Just copy/paste the above lines into a terminal.

Open File Descriptors

In /etc/security/limits.conf  set the following parameters:

As a functional and technical consultant it is always useful to have a demo environment.

What about installing R12 VIS on your LAPTOP?

Well easier said than done.

Just the download is a daunting task – unbelievable 35Gb for 12.0.4

So check your broadband contract for any cap and excess charges before downloading this much.

Also use a download manager so you can queue all the downloads once.

I use http://www.orbitdownloader.com/ but be sure to stop the P2P ability for security.

When knowing Oracle you surely have to add patches and updates before anything works.

Lets do this the top down way.

You need to install:

• My hardware and software (optional)
• Oracle Enterprise Linux 5.3 – OEL (yes, it is certified and all that)
• Oracle E-Business Suite 12.0.4 – EBS
• Java and Firefox
• Managing R12

I will not make screen dumps of everything as I assume you can fill out a form and click next.

Also so many other people has done this already so it would be pure waste of space then.

The things I will focus on is my experiences which may help or add to the information already available.

• Strategy – High level scope of what interfaces are needed and their intended purpose. In order to establish this – an as-is and to-be system landscape is needed. Also intermediate system landscapes may be needed in case there is a transition period. The transition period may drive the need for additional intermediate interfaces as well. For SOA interfaces the source system may be unknown or multiple known. At strategy level business object complexity, prerequisites, frequency and volumes must be known in order to drive the Plan. Frequency may be driven by business events especially when its a SOA interface. This document is produced by the interface manager and must be signed-off by high level management like CIO and/or CFO and interfaces impacts business performance and controls like Sarbanes Oxley.
• Plan – Estimate in time and money based on the above Strategy including dependencies between interfaces where prerequisites must be in place. This document is produced by the interface manager.
• Functional Specification – This specifies how to interface and both manual and automated processes must be described. A process diagram may be helpful at this point indicating the intended business process. The functional specification should also sections on security and controls and how to implement these. With point to point interfaces this is normally a reconciliation of the transfer and/or regular balance check and with SOA interfaces this is typical a handshake returned to the originating system. This document is normally produced by an functional consultant.
• Technical Specification – Specification of how the above deliverables will be produced. This may include pseudo code, flow charts and entity relationship diagrams. This document is produced by the developer or development management.

All of the documents above mainly specify functional information. Of cause some technical input may be required – however the main focus is on the functional approach and the technical part is business as usual.

Except for the Technical Design all the above documents should be owned by a functional person  – ideally an experienced person that can engage top management as well as obtaining the technical information required.

The above documents will be described more detailed in a later post.

Lets have a look at the elements of the data migration by document:

• Strategy – High level scope of the data migration agreeing to what business objects must be migrated and how they depend on each other and on the business. Also business risks, constraints and limitations must be identified. Other topics may be data retention, decommissioning targets and cut-over constraints. This document should be agreed at a high organisational level and also signed off at same level. Typical level is CFO or corporate controller.
• Plan – Estimate in time and money based on the above Strategy including dependencies between business objects. This document is produced by the data migration manager.
• Procedure Design – How to migrate each business object mentioned in the Strategy step by step. This includes data cleansing, entry methods, prerequisites and reconciliation. Reconciliation methods and needed reports must be identified early. At this point needs for functional mapping or technical extract, transformation and load or a custom report may be identified and functional and technical specification documents should be created for this.
• Functional Specification – Functional specification for needs outlined in the Procedure Design. One procedure design may result in one or more functional specifications. Functional specifications should be made for functional and technical deliverables. A typical functional deliverable could be a mapping spreadsheet. Technical deliverables are normally interfaces and reports.
• Technical Specification – Technical specification for the above Functional Specification. This document is no different than a document for a technical deliverable like a interface or a report.
• Script – How to perform the data migration step by step in accordance to Plan and Procedure Design. This is a detailed step by step guide including timings and who to do what by when to ensure the data migration is performed in a controlled manner in correct sequence and to planned time and quality. A good script can significantly reduce cut-over risk and time.

All of the documents above mainly specify functional information. Of cause some technical input may be required – however the main focus is on the functional approach and the technical part is business as usual.

Except for the Technical Design all the above documents should be owned by a functional person  – ideally an experienced person that can engage top management as well as obtaining the technical information required.

Details of the above documents will be described in a later post.

Is the process of managing data migration a functional or a technical task?

Many times I have seen the requirements for a data migration manager being mainly technical – however looking at the aspects of a data migration this may prove strong functional skills must be present.

The data migration focus should be on:

• What we migrate?
• How we migrate?
• How do we know the migration was successful?

These are all business decisions from a functional perspective.

Taking a technical approach to this may put the business at risk as the consequences are obvious if you read on.

What we migrate - is a high level business decision and should be founded in what is critical for the business to function. This often include the basis both for legal and management reporting as well as items to ensure day to day operations.

Legal requirements for data retention may also come into play if the source system is to be decommissioned.

In some businesses historic information is hugely important as this may be used for risk assessment and statistics. However historical information can sometimes be very complex to migrate as each item may include changes to multiple transactions which has to be re-created.

All these items should be agreed by upper management as failing to assess the risks and requirements could in worst case impact share price or result in legal action against the company.

How we migrate - is based on information like volume, complexity and resources. The business needs to have an idea of how to provide the data migration in terms of procedures to obtain the correct data and how to apply it in the new system. This is again a functional task to describe this.

Often the data migration is fully manual and no technical interaction is needed but due to complexity a procedure must be followed. This may include items like period closing in the source system prior to extracting data for the target system. Another topic could be how to pay off as many supplier invoices as possible to reduce volume may be a non-trivial process as this will impact cash flow and reporting especially if the data migration takes place at a quarter end.

Most modern systems accept data from spreadsheets or semi-automated typing tools so most low to medium volume migrations can be done by users as long as the process is well documented.

When volume is very high or complex data transformation is required custom programs may be required but this is no different than specifying any other customization like an interface. As with any other customization this must be described in a separate functional specification.

How do we know the migration was successful – well here the functional approach is needed again. Both verification and reconciliation is needed here.

Only a business user would know if a migrated transaction is correct in the target system. If a transaction is not fully correct represented in the target system the business user will suffer as the transaction will have to be amended or re-entered manually after going live. This verification is clearly a functional task.

The source and the target system data must also be reconciled – often by the use of standard reports or spreadsheets. This will ensure that all the required data i the source system was successfully transferred to the target system. Differences may be allowed as long as they can be explained and verified.

Before going live legal and management reporting should be run and compared to the reporting made from the source system. This may include running quarterly or year-end reports is both systems.

If the data is transformed an audit trail must be retained so the transformation can be validated. Often source system identifiers are carried across to the target system so a report can be produced from the target system but in the format of the source system.

Custom reports may be needed often due to the source system is a legacy system with limited reporting capabilities, Making custom reports is no different than any other customisation so a functional specification is needed here.

Conclusion – data migration decisions and processes are driven from a business and functional point of view. Technical resources may be needed but this is mainly for customisations but this is no different than any other interface or custom report.

If the functional consultant has some technical experience this will be handy when writing the functional specifications.

Your company is in the crunch and we need to make it through to the other side.

From a systems implementation and process point of view this is an opportunity to fix issues that nobody cared about in good times.

In my daily work I see numerous cases where both systems and processes can be improved if the business has the motivation to do so. Maybe now is the time?

How can the business adapt with minimum cost and maximum gain?

We have the normal three dimensions to work with:

• Systems
• Processes
• Organization 

Each dimension can be approached separately but any change may impact other dimensions.

Systems

Unleash your systems and make them work for you!

Just ask yourself how much functionality you know and use in Excel? This is often the same with other systems including financial systems. I have seen people extracting data into spreadsheets and creating custom reports where this could have been done using standard functionality. However nobody really understood the standard functionality so they used the tools they knew well.

Sometimes new functionality has been introduced with upgrades without changing user procedures or sometimes requirements has changed over time so users are working around this instead of changing the system settings.

Reporting can be changed or improved to focus on cost cutting and resource usage?

Processes

Often business processes are created at times where time and money is plenty however in these cash strapped times you may need to reconsider this.

Most systems has a built-in best practices however sometimes these are ignored in good times and businesses implement a exiting business process rather than to adapt to the built-in best practice. By redesigning the process and adapting to best practice the business can often benefit significantly.

You could also consider introducing new business processes especially focused on cost savings. Implement procurement software? Well no – this is a long term investment – some simple short term process changes can ensure you save money and time. A good procurement process can work almost as well on paper as in a system and when the times get better you will be ready to implement the process in a system.

Organisation

Organisational changes are often the output of changes to systems and processes however organisational changes can also drive changes to systems and processes.

In a crisis most companies immediately think – redundancies. This could be the outcome of the above approaches – however consider if receivables management or payables control could be improved by reallocating people to focus to cash flow improvement and risk reduction functions.

Improved debt management can increase cash flow and improve collections supported by systems functionality. Often collections functionality is not even implemented in good times but as a department get more staff it may need to get more organised with the help of systems.

Payables management could improve controls on suppliers – reducing the number of suppliers and also renegotiating payment terms and delivery lead times on the remaining suppliers. Often the supplier is in the same situation and by increasing the communication or co-manage the supply chain with key suppliers may put both parties at an advantage.

During an implementation it is quite often that the user documentation gets down-prioritised compared to delivering the environment and the associated setup documentation (BR100 or similar).

When done in the right way the documentation decreases the overall risk to the project and improves the quality of the delivered system and increases user ownership.

This process involves the users at a early stage so the documentation is made for the users by the users. The benefits of this is many:

• Better ownership
• Better readability
• More targeted to the individual business or department
• Proven processes at a earlier stage
• Incorporation of security and controls at a early stage
• Consultant is a teacher, coach and reviewer for the super user
• Super User is a teacher and coach for the normal users
• Improved knowledge transfer
• Less dependency on consultants post go-live

So it is also obvious then that overall costs would be reduced – especially long term.

The only drawback is increased need for local resources earlier in the project. However the cost of this is easily offset by the savings in consultancy fees.

The list of documents are long but done right the work is minimal and one document inherits the content from another.

This is what I usually recommend to produce – in terms of user related documentation:

• High Level Design (HLD) – This document is made by the consultant and outlines the requirements, scope and solution design at a high level. This document is signed-off by the business to ensure the following documents do not expand beyond the overall project scope. 
• Super User Guide (SUG) – The super user documents the agreed process as it is being implemented and setup in the development environment. The content of this document reflects early testing and decisions made during setup and process design together with the consultant – including exception handling complete with screen dumps.
• User Guide (UG) – This is the guide for normal users. More or less a direct copy of the above but without the complex exception handling and exception processes. The content is more elaborated and reflect the latest changes so new joiners easily can start operating the system – obtaining a faster time to use ratio. Chapters are the same as in the SUG to ensure ease of maintenance and consistency.
• Training  Material – this is copied from the UG for the purpose of class room training and easy browsing. Essentially this is the the UG made into a presentation where the screen dumps and charts is used for the slide pages and the body text is added as slide notes.
• User Acceptance Test (UAT) Script – Copied from the SUG with and added "expected output" and “comments” columns. Using the SUG in this way ensures the system is tested in accordance to the agreed and jointly developed procedures in a comprehensive manner. If any of the test fails it is then easy to make necessary changes to the system and the related documents as they all tie in with each other.

For the benefit of the users both User Guide and Training Material can be put on the intranet for easy access and version control. A tool like SharePoint can be used for this but a more simple approach like saving the document as a web page is better than nothing.

If the above documentation path is not followed you will find yourself faced with some of these issues:

• Documents are out of sync
• Documentation takes a lot of time
• At the integration test stage without super user documentation
• Consultants runs the integration test (and not the users)
• At the UAT stage without user documentation or/and training material
• Documents has to be re-invented or re-done each time in each phase of the project
• New documents will have to be created after go-live
• UAT scripts are sparse or not comprehensive
• Training material not available in presentation format
• Consultants are making the user guide or training material
• Users do not know how to update the documentation (try to ask them how they would)

The list could be longer but trust me you will know when something is wrong…

I’m standing on the train station waiting for the 22:16 train but now it is 20:20??? The screen still says the train is due 22:16 – weird. Just arrived on a late flight and now the train is late as well. Oh – now the speaker lady now tells me the train is 10 minutes late!!!

While waiting at least another 10-15 minutes I can’t help to analyse the situation – it might be sad but at least it makes the time fly.

I stand there and ask myself:

• Why didn’t they tell me before the train was due – time is now 20:20 of cause it is delayed then!
• The nearest station is 20 minutes away – maybe it was late already then?
• The information screens never told me they train was late
• Strange using the speaker system when they got all these screens

Without knowing anything about the company and their information systems I can guess some of the following problems are present:

• The system does not deliver to client satisfaction – me it is!
• Information was not timely – definitely not
• The information source for the screens is apparently wrong
• Surely somebody somewhere must know the train is late – at least the train driver
• Do they not track trains with GPS or similar?
• The information system is not being used for ad-hoc messages – at least not this time
• Maybe the speaker lady does not know how to announce on the information system?

The list could go on and on – but the core problem is apparent:

• I’m not timely and correctly informed!!!

So have this system actually missed its purpose? Maybe not seen from the people who made it – but how often haven’t we come across a system that misses the purpose only realised after going live? Just look at numerous websites that is unusable or extremely awkward to use or software projects failing due to usability problems for the end users. Also financial systems that deliver data too late or invalid data prior to month end close.

How can we ensure the correct requirements are met for the right people?

Look at your own development projects and check for these typical warning signs:

• Wrong definition of who is the client or the end user.
  This is key to gathering the correct requirements. Who is actually the user? Who’s input is the key to make this system a success? Often the client is confused with the customer who is paying for the system but who’s not necessary will be the end user. Keeping the customer happy is important but that may not necessary produce a good system.
• Lack of proper client/end-user involvement in the requirements phase.
  It often already fails in the tendering phase where the initial requirements are over complicated or misleading. The software supplier then tenders for an overly complicated and overly expensive system which eventually will fail after the budget has been blown. Did I mention any government projects here?
• Lack of client/end-user feedback in iterative development or pilot schemes.
  Both phased and RAD development cycles often focus on feedback from super users which may over complicate a system without reason or may request functionality which is rarely used. Many systems succeed as simple applications for later to add complexity.
• Requirements are not precise and concise.
  Do you understand all the requirements when you read them? Are they clearly stated? Are all the statements short – ideally a single paragraph? It seems obvious but quite often subject matter experts have a hard time to explain what they do in a simple way. Keep it to simple statements of truth. State what the system should do rather than how it should do it. Avoid stating what it should not do.
• Lack of ownership.
  Each requirement must have an owner or/and a sponsor. This enables the requirements to be validated and in case of changes a way to manage this involving impacted parties. This also ensures that requirements are linked to budgets which is useful when it comes to cutting the scope.
• Unclear documentation.
  Many projects fail on bad documentation. This includes documenting the requirements in the early stage of the project. Clear structure and extensive cross references are important. Requirements must be tagged with types likes legal (or external), functional and non-functional (or technical). Lack of version control, change management and traceability also adds to the documentation problems when new revisions are made.

Requirements are a necessary evil but it has to be done by professionals who ensure to involve the right people. You may think the above is obvious but in my 25 years of IT experience I have seen it going bad too many times.

The English reader might think this bad rail information system is all due to the privatisation and must be due to communication problems between providers – however this incident happened on a Danish train station and this part of the Danish railways are still in public ownership!