Thursday Aug 08, 2013

Reporting on User Roles in Fusion Applications

We often find a need to get a list of enterprise roles assigned to a Fusion Applications user, a need for a simple report. This can also be useful when there is no access to OIM screens, but only a simple read-only access is provided to the Fusion database. Below are certain simple SQL scripts that would assist in getting such a report. These scripts can be run by creating data model queries in BI Publisher if you are accessing a SaaS implementation or directly run in any SQL client if you are in an on-premise setup.

1. The SQL below can be used to get a list of roles assigned to an FA user:

SELECT a.USERNAME,
  c.ROLE_COMMON_NAME,
  c.ROLE_DISTINGUISHED_NAME
FROM PER_USERS a,
  PER_USER_ROLES b,
PER_ROLES_DN_VL c
WHERE a.USER_ID = b.USER_ID
AND b.ROLE_ID = c.ROLE_ID
AND a.USERNAME = '&username'

Below is a sample output from the SQL and the screenshot from OIM for the same user (FA user 'FUSION' is used for this example here).

OIM Screenshot for 'FUSION' user is below:


2. Further drill-down of the individual roles can be obtained using the query below which provides the detailed listing of roles inherited by a specific user session. The result from this query would match the results you see when drilling down 'Application Implementation Consultant', 'Employee' and 'IT Security Manager' above.

SELECT ROLE_NAME,
ROLE_GUID,
  SESSION_ID
FROM FND_SESSION_ROLES
WHERE  SESSION_ID IN
  (SELECT SESSION_ID
  FROM
    (SELECT SESSION_ID
    FROM FND_SESSIONS
    WHERE fnd_sessions.user_name = ‘&username’
    ORDER BY FIRST_CONNECT DESC
)
WHERE rownum<=1
)
ORDER BY role_name


The same result can also be obtained using the below query:

SELECT srs.ROLE_NAME
FROM FND_SESSIONS s,
FUSION.FND_SESSION_ROLE_SETS srs
WHERE s.SESSION_ROLE_SET_KEY = srs.SESSION_ROLE_SET_KEY
AND s.SESSION_ID IN
  (SELECT SESSION_ID
  FROM
    (SELECT b.SESSION_ID
    FROM FND_SESSIONS b
    WHERE b.USER_NAME = ‘&username’
    ORDER BY FIRST_CONNECT DESC
    )
  WHERE ROWNUM <= 1
)
ORDER BY srs.ROLE_NAME

The above queries, using FND_SESSIONS, will only be valid if the FA user has logged into Fusion Applications at any time (or if there is an active session of this user) and the user's login information exists in this table (not purged by any purge routines).

For a list of duties and privileges assigned to various job (or external) roles, please refer to My Oracle Support Reference Note: 1460486.1 Mapping of Roles, Duties and Privileges in Fusion Applications.

Keep visiting our blog for other useful tips and tricks in Fusion Applications.

Thursday Apr 11, 2013

Fusion Applications Single Sign On - Business User perspective

Common Use Cases & How to implement them (SSO Pilot Website)

The post outlines some of the more prevalent Single Sign On (SSO) use cases Fusion customers are currently using. It also provides an outline of work necessary to enable each of these use cases & links to more detailed technical information.

Case #1: From Corporate Portal

Employees, already authenticated into your corporate portal, should be able to click on the Fusion Apps link and get access without being challenged for their username/password as shown below.


Figure #1: SSO from Corporate Portal

Software you'll need:

Most companies will already have a directory (LDAP) that they are using to store their employees identities. If you already have Single Sign On configured for any of your applications, then you probably already have a "Federation Server" inhouse.

If your federation server is:
  • ADFS (Active Directory Federation Server) 2.0 from Microsoft
  • Oracle Identity Federation 11g
... you're all set.

If it's some other Federation Server capable of issuing a SAML 2.0 token, this is subject to approved by Oracle.


Configuration / Integration Work Needed:

Creating Employees in Fusion Apps: First thing you'll need to plan is how to create your employee identities in Fusion Applications and how to assign them the appropriate roles in Fusion Applications (this is required before Single Sign On will work). For testing purposes, you can just create the users using the Fusion Applications "Manage Users" or "New Person" screens and typing them in. If you're a small company, you can continue to do this for new hires. If you're a large company, refer to the "Employee/Role data flow" page - this might reflect the flow you need. If it does not, let us know.

When creating the employee in Fusion HCM, the value that you enter as the "HCM username", should be a unique value also present in your Federation Server for that employee, as you will need to configure your Federation Server to send this value as the "Name Id" when it issues the SAML token for Fusion Applications to consume. [The "Name Id" is just a unique value that tells Fusion Apps who this user is].

View Co-existence and SSO Presentation for more details.

Configuring your Federation Server & Fusion Applications (Cloud): Then it's simply a matter of doing some configurations in your Federation Server and for Oracle's Cloud Operations team to do some configurations in your Fusion Applications Pod. This part is done via filing a Service Request. The details of all this are available in My Oracle Support under Note 1477248.1.

Embedding URL: Finally you will embed the url into your corporate portal and your authenticated users will be able to click on the Fusion Applications link and be taken directly into Fusion Applications without being challenged again.

Case #2: From a 3rd Party Application

Employees already authenticated to a 3rd party SaaS Application should be able to click on a Fusion Applications URL and access Fusion Applications without being challenged for their username/password.


Figure #2: SSO from 3rd Party Application

Software you'll need:

If your employees are already configured for SSO into the 3rd party Cloud App, then you probably already have all the On-Premise Software needed in place (LDAP & Federation Server). Refer to Corporate Portal page.

Configuration / Integration Work Needed:

Creating Employees in Fusion Applications: Exactly the same as the "Corporate Portal" use case above.

Configuring your Federation Server & Fusion Applications (Cloud): Exactly the same as the "Corporate Portal" use case above. Single Sign On will operate between your On-Premise Identity Provider and Fusion Applications in exactly the same manner, but your end user will experience Fusion Applications embedded within your 3rd party Cloud Application (as long as the 3rd party Cloud Application supports embedding the URL).

Embedding URL: You will embed the URL into the 3rd party Cloud Application and your authenticated users will be able to click on the Fusion Applications link & access Fusion Applications screens without being challenged again.

Case #3: Accessing Fusion HCM & Taleo

Employees authenticated against Fusion Apps via SSO, should be able to access Taleo without being challenged for their username/password.


Figure #3: Accessing Fusion HCM & Taleo

If you wish to Single Sign On into Fusion HCM, you will need to configure that as outlined in the "Corporate Portal" use case above.

Then you follow the configuration steps to get Taleo SSO working with your On-Premise IdP. This includes a step of ensuring that the employees that need to access Taleo are already created in Taleo.

Now once your users are logged into Fusion HCM, they can bring up an additional tab for Taleo and will be automatically logged into Taleo.

Case #4: Access from Home

All the use cases above should also work when the employee logs in from home (outside work network).


Figure #4: Access from Home

Case #5: SSO plus Non-SSO

Some of your employees (contractors etc) or partners are not present in your LDAP and need to be authenticated by Fusion Applications. All the others need to be authenticated via SSO. NOTE: This is supported as of Release 7 only.


Figure #5: SSO plus Non-SSO

As of Release 7, when you click on the Fusion Applications URL, you will be able to choose between SSO authentication and authentication via Fusion Applications. Contractors and Partners can choose to authenticate via Fusion Applications and employees via SSO.

The SSO setup & configuration remains the same as in the "Corporate Portal" use case above.


References

Co-existence and SSO Presentation
My Oracle Support (MOS) Interlinked documents on Fusion Apps SSO
MOS Note on Configuring Taleo Business Edition

Employee/Role data flow (from SSO Pilot Website)
SSO Pilot Website

Feedback via comments below or email

Tuesday Nov 13, 2012

How you can extend Tasklists in Fusion Applications



In this post we describe the process of modifying and extending a Tasklist available in the Regional Area of a Fusion Applications UI Shell. This is particularly useful to Customers who would like to expose Setup Tasks (generally available in the Fusion Setup Manager application) in the various functional pillars workareas. Oracle Composer, the tool used to implement such extensions allows changes to be made at runtime. The example provided in this document is for an Oracle Fusion Financials page.

Let us examine the case of a customer role who requires access to both, a workarea and its associated functional tasks, and to an FSM (setup) task.  Both of these tasks represent ADF Taskflows but each is accessible from a different page.  We will show how an FSM task is added to a Functional tasklist and made accessible to a user from within a single workarea, eliminating the need to navigate between the FSM application and the Functional workarea where transactions are conducted. In general, tasks in Fusion Applications are grouped in two ways:


Setup tasks are grouped in tasklists available to implementers in the Functional Setup Manager (FSM). These Tasks are accessed by implementation users and in general do not represent daily operational tasks that fit into a functional business process and were consequently included in the FSM application. For these tasks, the primary organizing principle is precedence between tasks. If task "Manage Suppliers" has prerequisites, those tasks must precede it in a tasklist. Task Lists are organized to efficiently implement an offering.

Tasks frequently performed as part of business process flows are made available as links in the tasklist of their corresponding menu workarea. The primary organizing principle in the menu and task pane entries is to group tasks that are generally accessed together.

Customizing a tasklist thus becomes required for business scenarios where a task packaged under FSM as a setup task, is for a particular customer a regular maintenance task that is accessed for record updates or creation as part of normal operational activities and where the frequency of this access merits the inclusion of that task in the related operational tasklist


A user with the role of maintaining Journals in General Ledger is also responsible for maintaining Chart of Accounts Mappings.  In the Fusion Financials Product Family, Manage Journals is a task available from within the Journals Menu whereas Chart of Accounts Mapping is available via FSM under the Define Chart of Accounts tasklist



dif2.jpg

Figure 1. The Manage Chart of Accounts Mapping Task in FSM

dif2.jpg

Figure 2. The Manage Journals Task in the Task Pane of the Journals Workarea

Our goal is to simplify cross task navigation and allow the user to access both tasks from a single tasklist on a single page without having to navigate to FSM for the Mapping task and to the Journals workarea for the Manage task. To accomplish that, we use Oracle Composer to customize  the Journals tasklist by adding to it the Mapping task.

Identify the Taskflow name and path of the FSM Task

The first step in our process is to identify the underlying taskflow for the Manage Chart of Accounts Mappings task. We select to Setup and Maintenance from the Navigator to launch the FSM Application, and we query the task from Manage Tasklists and Tasks

dif2.jpgFigure 3. Task Details including Taskflow path

The Manage Chart of Accounts Mapping Task Taskflow is:


/WEB-INF/oracle/apps/financials/generalLedger/sharedSetup/coaMappings/ui/flow

/CoaMappingsMainAreaFlow.xml#CoaMappingsMainAreaFlow


We copy that value and use it later as a parameter to our new task in the customized Journals Tasklist.

Customize the Journals Page

A user with Administration privileges can start the run time customization directly from the Administration Menu of the Global Area.  This customization is done at the Site level and once implemented becomes available to all users with access to the Journals Workarea.

dif2.jpgFigure 4.  Customization Menu

The Oracle Composer Window is displayed in the same browser and the Hierarchy of the page component is displayed and available for modification.

dif2.jpg

Figure 5.  Oracle Composer

In the composer Window select the PanelFormLayout node and click on the Edit Button.  Note that the selected component is simultaneously highlighted in the lower pane in the browser.
In the Properties popup window, select the Tasks List and Task Properties Tab, where the user finds the hierarchy of the Tasklist and is able to Edit nodes or create new ones.

src="https://blogs.oracle.com/FunctionalArchitecture/resource/TL5.jpg" dif2.jpg

Figure 6.  The Tasklist in edit mode

Add a Child Task to the Tasklist

In the Edit Window the user will now create a child node at the desired level in the hierarchy by selecting the immediate parent node and clicking on the insert node button. 
This process requires four values to be set as described in Table 1 below.

Parameter

Value

How to Determine the Value

Focus View Id

/JournalEntryPage

This is the Focus View ID of the UI Shell where the Tasklist we want to customize is.  A simple way to determine this value is to copy it from any of the Standard tasks on the Tasklist

Label

COA Mapping

This is the Display name of the Task as it will appear in the Tasklist

Task Type

dynamicMain

If the value is dynamicMain, the page contains a new link in the Regional Area. When you click the link, a new tab with the loaded task opens

Taskflowid

/WEB-INF/oracle/apps/financials/generalLedger/sharedSetup/

coaMappings/ui/flow/

CoaMappingsMainAreaFlow.xml#CoaMappingsMainAreaFlow

This is the Taskflow path we retrieved from the Task Definition in FSM earlier in the process

Table 1.  Parameters and Values for the Task to be added to the customized Tasklist

dif2.jpg

Figure 7.   The parameters window of the newly added Task  

Access the FSM Task from the Journals Workarea

Once the FSM task is added and its parameters defined, the user saves the record, closes the Composer making the new task immediately available to users with access to the Journals workarea (Refer to Figure 8 below).

dif2.jpg

Figure 8.   The COA Mapping Task is now visible and can be invoked from the Journals Workarea  

Additional Considerations

If a Task Flow is part of a product that is deployed on the same app server as the Tasklist workarea then that task flow can be added to a customized tasklist in that workarea. Otherwise that task flow can be invoked from its parent product’s workarea tasklist by selecting that workarea from the Navigator menu.
For Example
The following Taskflows  belong respectively to the Subledger Accounting, and to the General Ledger Products. 
/WEB-INF/oracle/apps/financials/subledgerAccounting/accountingMethodSetup/mappingSets/ui/flow/MappingSetFlow.xml#MappingSetFlow
/WEB-INF/oracle/apps/financials/generalLedger/sharedSetup/coaMappings/ui/flow/CoaMappingsMainAreaFlow.xml#CoaMappingsMainAreaFlow
Since both the Subledger Accounting and General Ledger products are part of the LedgerApp J2EE Applicaton and are both deployed on the General Ledger Cluster Server (Figure 8 below), the user can add both of the above taskflows to the  tasklist in the  /JournalEntryPage FocusVIewID Workarea.
Note:  both FSM Taskflows and Functional Taskflows can be added to the Tasklists as described in this document

dif2.jpg

Figure 8.   The Topology of the Fusion Financials Product Family. Note that SubLedger Accounting and General Ledger are both deployed on the Ledger App

Conclusion

In this document we have shown how an administrative user can edit the Tasklist in the Regional Area of a Fusion Apps page using Oracle Composer. This is useful for cases where tasks packaged in different workareas are frequently accessed by the same user. By making these tasks available from the same page, we minimize the number of steps in the navigation the user has to do to perform their transactions and queries in Fusion Apps.  The example explained above showed that tasks classified as Setup tasks, meaning made accessible to implementation users from the FSM module can be added to the workarea of their respective Fusion application. This eliminates the need to navigate to FSM to access tasks that are both setup and regular maintenance tasks.

References

Oracle Fusion Applications Extensibility Guide 11g Release 1 (11.1.1.5) Part Number E16691-02 (Section 3.2)
Oracle Fusion Applications Developer's Guide 11g Release 1 (11.1.4) Part Number E15524-05


About

This blog shares with the broader Fusion Applications community instructional material in the areas of Enterprise Structures, Extensibility, Integration and Security with the a focus on implementation. This blog is updated by the Fusion Applications Implementation Solutions Task force, part of the Fusion Applications Fusion Architecture organization.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today