Last Updated ( Monday, 13 May 2013 22:13 )
In this article, you will get a flavour of Fusion Applications in action and we will draw some comparisons with the Oracle EBS/R12. Of course the book on Fusion Applications Development is work in progress, and you can pre-order it from Amazon website or from this link. Keep in mind, its good few months before it will be released.
During the implementation phase, you first need to know which modules the client wants to implement. In our traditional Oracle EBusiness suite, we used a terminology called module.
However, in case of Fusion Applications, you can compare this with R12 as Module [Offering in FA] and SubModule [Option in FA].
In EBS, General Ledger, Payables, iExpenses were modules. However in Fusion Applications, the parent module is Financials. This parent module is called the offering. Therefore Financials is the offering, HCM is the offering. Within this offering you have Options. For example, within Financial offering you can implement Payables or Receivables or iExpenses or all the above. Now within the options, you have features. For example, iExpense has a feature of importing expenses straight from excel. Another feature within iExpense is to implement corporate credit card integration.
To make the job of doing implementation easy, Fusion Financials generates a task list on the basis of combination of Offering, Option and feature that you have selected during the implementation.
These initial screenshots will give you a flavour of Fusion Applications.
When you login to Fusion Applications, you will see a Navigator link.
When you click on Setup and Maintenance, you can then search for any page/screen. This is called Task, inherently due to ADF application UI being called Task [bounded/unbounded].
Last Updated ( Wednesday, 11 July 2012 01:39 )
Yield curve is nothing but a set of interest rates across different durations for example 1 week, 1 month, 2 months, 1 Year, etc. When you plot these rates on the Y Axis and with Term durations on X Axis, the graph takes the shape of a curve showing yields. This curve gives a relation between interest rate and the time for which the money is being deposited. This time duration is also known as term. In UK for example, LIBOR rate is considered to be the benchmark yield curve. This is the average rate at which banks in London lend to one another
OFSAA allows us to define as many yield curves that we desire.The OFSAA’s cash flow engine can use the yield curve term rates to reprice the interest rates sensitive financial instruments.
The changes to the interest rates in yield curves can also trigger the repricing of financial instruments. For example if the Adjustable type Code Flag in instrument table contains a value of 30 or 50 and if the Reprice Frequency is greater than 0, then the reprice dates are driven by forecasted yield curve rate changes rather than by the reprice frequency.
The interest rate variance also allows OFSAA to perform stress testing because a bank will usually always have both the borrowings and the lendings, which are sensitive to the interest rate changes. For stress testing new yield curves can be defined in OFSAA.
In OFSAA, there are primarily three types of currencies. These are the transactional currencies, reporting currencies and functional currency. A reporting currency is a currency into which the balances from other currencies can be consolidated. After consolidation has been performed, then reports can be generated in the reporting currencies. The balances from the reporting currencies can be further consolidated into the functional currency.
For example, a large European bank might consolidate its holdings in Asian currencies to the Japanese yen (reporting currency) and its balances American continent into USD (reporting currency) after which it might consolidate these reporting currencies to the Euro (functional currency).
After having implemented the field level validation in ADF in this link, in this article you will learn how to implement record level validations. For the performance reasons, the record level validations must be preferred over the field level validations. Similar to attribute/field level validations, these record level validations can be configured within the Business Rules section of the entity object.
Sometimes during the validation, you have a need to execute a SQL statement. For example, in the Receivables Invoice entity object might want to execute a SQL statement to check if the customer site is still active. Of course, the customer site table itself might have an entity object that can be used for validation, but that entity object will have all the columns in the table. For the purpose of our example, the SQL issued for validation should be very simple such as “select ‘x’ from hz_cust_site_accounts where status = ‘A’ and cust_site_account_id = :1. For these kind of validations VVO’s [ validation view objects ] can be created. These VVO’s can then be attached to the Entity Object in the business rules section. Please note that VVO’s do not have to be attached to the application module, because Application Module does not manage the state of these objects, nor are the results of these VVO’s cached in the middle tier.
The video below explains the steps for implementing the record level validations in ADF Fusion Apps, by leveraging VVOs.
After having understood data controls linked here, let us move on to validations in ADF.
In case of ADF, the recommended location for business logic is same as OA Framework, i.e. the entity objects.
A table will typically have only one entity object and therefore all the validations pertaining to that table should reside within the entity object.
Unlike OA Framework, ADF in Fusion Apps allows us to configure a wide variety of validations.
The video tutorial in this link explains how field level simple validations can be implemented in ADF.
These are equivalent to WHEN-VALIDATE-ITEM in Oracle Forms.
The link to this video is as shown below.
Use the HD option to see this demonstration in clear text full screen.
Before we get on with building screens in ADF, it is important for you to understand what data control means.
Last Updated ( Sunday, 01 July 2012 18:15 )
In Oracle Forms, the data is made visible to the screen via a database table or a database view or a synonym or a stored procedure.
In other words, Oracle Forms simply can show the data in the screen via a database object.
However ADF is much more powerful. In ADF Fusion Apps, a database table/view etc can be of course exposed to the User Interface screen via BC4J view object.
However in order to use the view object in the screen, that view object must be registered as a Data Control. ADF registers the view objects as a data control automatically for you.
However, ADF also allows you to register any custom java class that you may develop as a data control.
Moving on from the previous article linked here, in this article, you will see how you can expose the BC4J objects as a web service in ADF.
Last Updated ( Sunday, 01 July 2012 18:13 )
In order to practice this session, it is assumed that you have implemented the preceding articles.
Typically, you may have a custom student management applications whereby a university may create and update student records using an ADF Application.
The ADF BC4J API’s used by the student application can be exposed to Governing Educational institures that might enrol students on behalf of a university.
In such scenario, it is useful to expose the student management API’s as web service. This is very easily done in JDeveloper, as shown in screenshots below.
Please find the video that summarizes all the steps executed in the previous articles starting from Article 01 to Article 07.
Last Updated ( Sunday, 01 July 2012 18:08 )
Before you run this video, ensure that
1. You have downloaded latest version of JDeveloper from Oracle website. Simply google on Download JDeveloper
2. Downloaded and installed Oracle XE Database, again google to download this, and install the database.
3. Ensure following tables have been created in the hr schema of your database
After having created a View Link ( linked here ), now in this article we will test the View Link between Department View Object and the Employee View Object, to see how the parent child relationship works
Last Updated ( Sunday, 01 July 2012 18:04 )
We will also add further columns to the tables in DB and synchronize those with the Entity Objects.
A view link allows us to create a relationship between view objects. The relationship can be one-to-one, one-to-many, many-to-one, or many-to-many. The View Link Wizard and Editor lets us specify source and destination view objects, and links them using attributes selected.
Last Updated ( Sunday, 01 July 2012 17:55 )
To create a view link, we first need to have all the underlying view objects in place.
A view link is also like a Oracle Forms Block relation, that allows you to join two objects.
If you wish to create a master detail relation screen in ADF, then you must create View Links. As the user sets focus to the master row, the detail rows can be automatically queried using view link. This becomes possible when two view objects are related through a master-detail view link, and are in an application module, the iterator for the master view object automatically changes the detail rowset when the master row changes.
View links can optionally be created based on entity association [see this link for EO Assoc], but an association is not mandatory to create a view link.
A view link is similar to an association, but more flexible. It allows more relationships than equality between attributes and supports automatic master-detail synchronization.
Now, let us create a DepartmentVO.
After having created and tested the BC4J objects in this link
, now we can create entity associations. Entity associations allow you to create joins between tables in the Java layer. In other words, entity associations create a relationship between two entity objects. In this article, you will see how to create a master detail relationship between the Department Entity Object and the Employee Entity Object in the Fusion Apps tech stack. One single instance of the Entity Object java class will be created for each record in the underlying table.
Right click on the package to create a new Enity Object, of course this will be created on the table.
After having created the BC4J components using this link, in this article you will be testing the Application Module to create new Employee records or to query existing employee records without a screen.
Last Updated ( Sunday, 01 July 2012 15:16 )
This is possible in Fusion Apps tech stack, via jDeveloper, using Application Module test workbench.
Ensure that EmployeeVO is attached to the EmployeeAM.
You will see the instance name is EmployeeVO1, which means that every single programmatic reference to EmployeeVO will be using text EmployeeVO1.
After having created an offline database as per this link and synchronised that into Oracle DB, we are now ready to create BC4J objects.
Last Updated ( Sunday, 01 July 2012 15:17 )
In this article, you will create ADF BC4J objects for Fusion Apps tech stack. By end of this exercise, you will be able to create Entity Object, View Object and Application Module for ADF.
Let us begin by creating the Application for Database related development.
Note - This article will also be followed by a Video demo to summarize all the steps for BC4J object creation.
Further to the previous article of creating an offline database, in this artivle you will see how custom database objects can be added to offline database. The previous article on offline databases can be accessed from this link.
Last Updated ( Sunday, 01 July 2012 15:16 )
This article is subsequent to the article in which you downloaded JDeveloper and installed FOD Schema for Fusion Order Demo. The earlier article can be accessed from this link
Last Updated ( Sunday, 01 July 2012 15:16 )
When working with offline database definitions in JDeveloper, you can design the database model for your custom objects. These objects are stored as XML files, but can at any point in time be synchronized into the database schema, so as to deploy the objects to the database. You can convert offline database definitions to live database connections to create, alter, or drop database objects.
JDeveloper provides offline database tool to create and edit database objects such as tables and constraints outside the context of a database. When your Fusion Applications custom project is complete, the entire ADF Artifcats alongwith the custom DB components in offline DB can be deployed to UAT or the production instance.
You can create new tables and views and generate the information to a database.
You can create new tables and views and generate the information to a file, which you can edit and later run on a database connection.
Conversely, you can also import tables and views from a database schema, make the changes you want and then generate the changes back to the same database schema, to a new database schema, or to a file that you can run against a database at a later date. JDeveloper allows you to manually reconcile changes before committing them to a database.
You can use the modeling tools in JDeveloper to visualize your offline database objects on a diagram.
In this article you will see the steps for building the offline database.
Ideally, you should have installed the JDeveloper as per the instructions in this link
In Fusion Apps, the concept of Business Event & subscription is still in place, however it has become easy to raise business events in Fusion Apps, with lesser programming. In addition to this, the listener of the business events is implemented in SOA. In case of 11i and R12, we have a Workflow Event listener that runs within the R12 tech stack itself.
In case of 11i and R12, we used to raise the business events using
1. WF_EVENT.RAISE API from PL/SQL Layer
2.oracle.apps.fnd.wf.BusinessEvent.raise from Java/OAF Layer.
In Fusion Apps, we can raise business events from the BC4J layer as well, for example Entity Objects in ADF model layer. To do something similar in R12 you will have to write a piece of java code as shown in appendix of this article. However Fusion Apps provides a configurable solution for raising the event.
These business events can be picked up by the SOA Layer. Of course you will need a SOA project in place, with a SOA component named mediator that can listen to your business events. The mediator needs to be configured to listen to the specific business events of interest. After the event is identified, mediator can route the flow for further downstream processing in SOA, typically using a BPEL process component.
Alongside the name of the Business Event and the conditions, you can raise payload for the business event that will be available as parameter to the SOA Layer.
The image below shows Entity Object, which has a tab for Business Events.