How to Installing the Patch Set for ORACLE DB

A).Installing the Patch Set interactively

1.Log on as a member of the Administrators group to the computer on which to
install Oracle components.
If you are installing on a Primary Domain Controller (PDC) or
a Backup Domain Controller (BDC), log on as a member of the Domain Administrators group.
2.Start Oracle Universal Installer release 10.1.0.4 located in the unzipped area of the patch
set. For example, Oracle_patch\setup.exe.
3.On the Welcome screen, click Next.
4.On the Specify File Locations screen, click Browse next to the Path field in the Source section.
5.Select the products.xml file from the stage directory where you unpacked the patch set files,
then click Next. For example:
Oracle_patch\stage\products.xml
6.In the Name field in the Destination section, select the name of the Oracle home that you want to update from the drop down list, then click Next.
7.If you are installing the patch set on an RAC cluster, click Next when the Selected Nodes screen appears.
8.On the Summary screen, click Install.
This screen lists all of the patches available for installation.
9.On the End of Installation screen, click Exit, then click Yes to exit Oracle Universal Installer.

B).Installing the Patch Set Noninteractively

1.Log on as a member of the Administrators group to the computer on which to install Oracle
components.
2.Copy the response file template provided in the response directory where you unpacked the
patch set archive file.
3.Edit the values for all fields labeled as "Value Required">as described by the comments
and examples in the template.
4.Enter a command similar to the following to start Oracle Universal Installer in noninteractive
mode. If Oracle Universal Installer is located in Oracle_patch\setup.exe, then pass the full
path of the response file template you have edited locally as the last argument:
C:\Oracle_patch> setup.exe -silent -responseFile response_file_path
where Oracle_patch is the location of the patch set you downloaded and
response_file_path is the full path of the locally edited response file.

Read-only methods (PRAGMA methods)

Methods can be divided into two types:

• Normal methods

These methods is methods that manipulates data in the database.

• Read-only methods (PRAGMA methods)

These methods are methods that are connected to a PRAGMA that guarantees that the method never writes to the database.
This means that PRAGMA methods always are read-only. All PRAGMA methods is automatically granted when the package is granted.
There are a few methods that are considered to be PRAGMA methods by naming standard in IFS Applications (even if they are not connected to a PRAGMA in the code).
These methods are:
ENUMERATE
EXIST
EXIST_DB
LOCK__
LANGUAGE_REFRESHED
INIT
FINITE_STATE_DECODE__
ENUMERATE_STATES__
FINITE_STATE_EVENTS__
ENUMERATE_EVENTS__
Views

How to use Crystal Report for IFS Application

step by step as below:

1)Report Design thru Seagate CryStal Reports (xxx.rpt)

2)To add the xxx.rpt in Quick Report
thru IFS/Admin/Fnd1 AdMin/Quick Report

3)To Find Report id thru IFS/Admin -> Installation-> SQL Query tool
by using sql as belos:
select quick_report_id,description from quick_report;
(let quick_report_id is 99 as a example)

4)To add quick_report_id to Customer-Menu
Thru IFS/Admin - Fnd1 Admin\CustomMenu\CustomMenu-Detail

ActionType: SAL Code
Windows :enter the window identity – like :tbwPurchaseOrderLinePart
Parameter :InfoServer.QuickReportStart(SalNumberToStrX(99,0)//'@')
//please note :the number 99 is quick_report_id

5)To activate In IFS Application & enabled Custom Menus

the form ‘Properties’ – Window tab pop-up details
have enabled Custom Menus (tick the box).

History of IFS Foundation1 (2005-2006)

2005

The Edge project continued during 2005. The work with client technologies for the "next level user productivity" took on more concrete forms. The platform was used for the OEE and system administration modules was given the name IFS Rich Web Client. Implemented with .Net technology it offers the possibility to build rich and innovative user interfaces, whilst at the same time providing a fully web based, zero install, deployment solution. In the later half of the year research was initiated to see how this new client platform could be applied to larger areas of IFS Applications.

Work on the system administration modules resulted in the creation of IFS Solution Manager - a new easy-to-use administration and configuration tool for IFS Applications. One important aspect of IFS Solution Manager was the ability to perform admin tasks as any normal user, with individually grantable tasks. Enabling clear segregation of administrative duties this would make it easier to comply with SOX and other regulatory requirements.

During the year a lot of work was also done on the IFS Web Client. In particular the web client got the same possibilities to configure the screen layout as the windows client had received the year before. Combined with a new implementation of user profiles that was shared across all clients this turned out to be very powerful.

Another key theme effecting all parts of F1 development during the year was security. Following the tag line "secure by design and secure by default" frameworks were reviewed, new security concepts added, and configurations changed. Important improvements included the move to JAAS (Java Authentication and Auhtorization System) for middle-tier authentications, the introduction of security privileges, and establishing a more secure default configuration.


2006

April 2006 saw the release of IFS Applications 7 - the result of the Edge project.

The next project - Sparx - has just started. Under that project Foundation1 will continue to be developed with both short and long term goals in mind. A lot of improvements are planned for service packs on IFS Applications 7.

At the same time work development of some key features for IFS Applications 9 has arleady started.

History of IFS Foundation1 (2004)

2004

In 2004 IFS started the Edge project which was to be a longer-than-usual development project for the next core version of IFS Applications. Where this project was largely about vertical industry functionality, a key theme for Foundation1 was to be usability and user productivity.

The goal was to achieve a leap forward and deliver a level of user productivity never before seen in business applications. To this end IFS started serious research and prototyping into everything from user centric design methodologies to new ways of visualizing information.
The result was a series of prototypes demonstrating new concepts. Taking this one step further an application project called "1st Solution" was started.
The mission for this project was to put the new innovations and techniques into use in a real application. After a first approach to build a complete business solution the scope was changed to deliver a new version of the Overall Equipment Effectiveness (OEE) and System Administration modules.
In parallel with the work devoted to usability research and development of new client technologies, a lot of time was also spent defining the second generation of the services layer in IFS Service Oriented Component Architecture.
In particular the logical model was being extended to provide a closer alignment with BPEL concepts, as it was becoming increasingly clear that BPEL would become the de-facto standard to describe processes oriented software components. Further enhancements were also made to the storage model to enable more flexible and efficient reuse of and integration with the application core layer. IFS Developer Studio saw significant improvements, in particular to make the RAD process more productive as well as improving the support for development teams.

Because of the longer than usual development cycle, a fair amount of time was also dedicated to improving IFS Applications 2004. Work on supporting high availability, scalability, and secure deployments continued with new product certifications and support for more advanced deployment topologies. Significant updates were also made to the two newest components in Foundation1, namely IFS Report Designer and IFS Mobile Client. These updates incorporated feedback and improvement suggestions from early adopters.

The highlight of improvements on IFS Applications 2004 was however service pack three, which in the fourth quarter brought new possibilities for configuring the screen layout.
Now it was possible to move and hide fields, as well as changing the tab order and marking certain fields as mandatory or read only. With the possibility to adjust screen layout to specific user groups and the task at hand, user productivity could be increased and training costs lowered.
For the existing customer base this functionality was the first clear result from IFS' increased investment into usability.

History of IFS Foundation1 (2003)

2003

The Chhiri project progressed as planned and in May the migration work and the RAD tools were completed. In the mean time the hype around web services had led to discussions in the software industry, highlighting the benefits of Service Oriented Architectures (SOA) when it comes to ease of integration and application extension.

This, combined with a desire from IFS to provide easier-to-use and well documented interfaces for partners and customers alike, led to the decision to incorporate the architecture (which was service oriented), techniques and tools originating from the Ti22 project (and now moved to J2EE by the Chhiri project) into the core Foundation1 architecture. In practice this meant splitting the business logic tier into two sub tiers - one application core tier containing the existing business logic, and one services layer, where service-oriented interfaces to the business logic are placed. This change not only allowed restructuring, consolidation, and simplification of the entire Foundation1 platform - it also created the architecture platform on which IFS could initiate key development investments for the coming years.
The extension of the architecture with a services layer, and the incorporation of a new RAD tool for that layer, was such a big step forward that it deserved giving the architecture a new name. And so the Open Layered Architecture (OLA) from 1995 was now officially superseded by IFS Service Oriented Component Architecture (SOCA).

The Handshake project working on a platform for mobile clients continued throughout the year. The framework itself, as well as the mobile applications, were developed completely according to the SOCA architecture. In October the first beta release was ready.


Following IFS principle of continuously updating and replacing technologies, 2003 also became the year when one of the oldest parts of Foundation1 would see its first big overhaul. Under the umbrella of the "Bayonet" project a new architecture for operational reporting was developed. Existing reports would be complemented to produce XML data.
A new WYSIWYG report layout tool - IFS Report Designer - was developed.
The new solution was based entirely on open standards, where IFS Report Designer created an XML style sheet that would transform the XML report data into a XSL/FO (Formatting Object) file, which was then rendered into PDF for viewing/printing. As all new development of Foundation1, the new solution was built according to SOCA and made good use of the services layer.

In the second half of the year a lot of work went into consolidating Foundation1 in order to lower the cost of deploying and operating Foundation1 based applications. Things like installation, configuration, authentication, were homogenized throughout the different parts of the platform, and bits were "merged" to reduce the number of parts in the platform. Combined with the move to a standard J2EE middleware this resulted in a Foundation1 platform that was significantly easier to understand, install, and operate.

In November Foundation1 2004 was released together with IFS Applications 2004. The entire web and middle tiers were now fully on the J2EE architecture, with support for all leading application servers. The consolidation meant that there was now a single component where all runtime and development tools for the services layer of SOCA were collected - "Extended Server". The "original" Foundation1 component with runtime, tools, and services for the application core was renamed "IFS Base Server". All the new parts (services, mobile clients, XML reports) now used the common RAD environment created by the Chhiri project. Because of it's central part in current and future versions of Foundation1 this environment was given the ambitious name of "IFS Developer Studio".

History of IFS Foundation1 (2002)

2002

IFS Applications 2002-2 was released 19 April - and with that also Foundation1 2002-2 which includes most of the functionality developed by the Ti22 project during the previous years. This includes the CORBA middleware, BizAPI development framework, new Connect integration framework, and the client access technology.
The Web Kit and IFS Applications web interface had been moved to the J2EE platform and IFS Applications 2002-2 no longer used ASP technology.
The new, easier way to integrate using XML BizAPI interfaces and IFS Connect to publish these as web services was of the main news in IFS Applications 2002-2.

2002 was also the year when the consolidation of application server technologies really started to happen. Out of a sea of quasi-compatible CORBA and Java application servers, came the J2EE 1.3 specification and a set of J2EE application servers that were mature, compatible, and fast enough to be considered for a wider use with business applications. At the same time Microsoft was really beating the drum for .Net and the .Net Framework. It became clear that it was only a matter of time before application servers became commodity. This was confirmed when some vendors started to give their products away for free, and with the availability of high-quality open source J2EE servers.

Realizing that sooner or later it would not be economically sensible to use anything other than standard J2EE also in the middle tier, and having experienced first hand the challenges of working with CORBA, IFS decided to do the change sooner rather than later. The Chhiri project was initiated to phase out CORBA in favor of J2EE. IFS tradition of encapsulating infrastructure in Foundation1 and thus hiding it from the application meant that it was only the Foundation1 frameworks that needed to be changed.

As IFS Applications 2002/3 and the new service based IFS Connect gained momentum, the need for a more productive and better integrated development environment to build services and other Java artifacts became apparent. Consequently the Chhiri project was given the additional directive to produce a highly productive RAD development environment.

Anticipating a rapid increase in the use of mobile devices (PDA:s, mobile phones) in a couple of years time, IFS had early in the year started an effort to extend the architecture, frameworks and tools of Foundation1 to cover volume production of mobile clients (user interfaces) for functionality in IFS Applications. This would be known as project "Handshake". The project set out to solve two key issues facing mobile business applications at the time.

The first was to avoid device lock-in by building a platform that allowed the mobile applications to run on multiple current and future devices.
The second was to create a solution that would work "online when available".

The first task for the project was to survey the market for mobile infrastructure (micro databases and the likes) to use. In the end IBM technologies were chosen - the J9 virtual machine, DB2e database, and MQe message manager. And creation of the frameworks could start.