Spel

10
In Self Service personalizations, there are two ways to change properties like Rendered or Read Only or Required. Either you hardcode a value of True/False during personalization or you attach a SPEL syntax to these properties via personalization. SPEL is nothing but an expression that returns TRUE or FALSE. In this article we will see how you can create a SPEL Expression by leveraging Permission Sets and Grants in AOL. This example is useful in cases whereby you have a need to perform same type of personalization across many different responsibilities, with each such responsibility pertaining to same set of Menu Items. In such cases, you can either personalize at responsibility level for each and every responsibility or you can simply personalize the fields just once at site level by attaching a SPEL expression. Even though we use this example with Responsibility, however in reality you can use this technique for any Role in the system. The steps followed for this demonstration has the following high level steps :- 1. Ensure that you have a Form Function to use or else create a new Function 2. Create a Permission Set that includes the desired functions 3. Remove global grant on that function from Permission Set, so that Permission Set if not available to everyone. We latter roll out this permission set to specific set of roles or responsibilities, 4. Create Grants for that permission set for selected few responsibilities. 5. Personalize at site level, using SPEL expression that contains reference to the Function that you included in Permission set. For example, if you grant XXCUSTFUNC to responsibility XXCUSTRESP1 but do not grant this function to XXCUSTRESP2. Then SPEL syntax of $ {oa.FunctionSecurity.XXCUSTFUNC} will evaluate to TRUE if the function

description

spel

Transcript of Spel

Page 1: Spel

In Self Service personalizations, there are two ways to change properties like Rendered or

Read Only or Required. Either you hardcode a value of True/False during personalization or you

attach a SPEL syntax to these properties via personalization. SPEL is nothing but an expression

that returns TRUE or FALSE. In this article we will see how you can create a SPEL Expression

by leveraging Permission Sets and Grants in AOL.

This example is useful in cases whereby you have a need to perform same type of

personalization across many different responsibilities, with each such responsibility pertaining to

same set of Menu Items. In such cases, you can either personalize at responsibility level for

each and every responsibility or you can simply personalize the fields just once at site level by

attaching a SPEL expression.  Even though we use this example with Responsibility, however in

reality you can use this technique for any Role in the system.

The steps followed for this demonstration has the following high level steps :-

1. Ensure that you have a Form Function to use or else create a new Function

2. Create a Permission Set that includes the desired functions

3. Remove global grant on that function from Permission Set, so that Permission Set if not

available to everyone. We latter roll out this permission set to specific set of roles or

responsibilities,

4. Create Grants for that permission set for selected few responsibilities.

5. Personalize at site level, using SPEL expression that contains reference to the Function that

you included in Permission set.

For example, if you grant XXCUSTFUNC to responsibility XXCUSTRESP1 but do not grant this

function to XXCUSTRESP2. Then SPEL syntax of ${oa.FunctionSecurity.XXCUSTFUNC} will

evaluate to TRUE if the function is available to that login context. For XXCUSTRESP1 this

syntax will return TRUE whereas for XXCUSTRESP2 this syntax will return FALSE. If this SPEL

is attached to a Read-Only Property of a field, then this field will be enterable in

XXCUSTRESP1 and will be read-only in XXCUSTRESP2. Note that you will do personalization

just once and thereafter you can totally control the read only and other properties using Grants

functionality. This SPEL expression can be attached to the following properties via

personalizations Rendered, Read Only, Disabled and Required. [Assuming Oracle Product

developers have not disabled admin personalization for the fields that you are trying to

Page 2: Spel

personalize.]

In this example we will use responsibility “OA Framework ToolBox Tutorial”. Login to this

responsibility and click Menu named Transactions and then click “Create Supplier”. Here you

will see a field named “Start Date” that we wish to make enterable or read-only depending upon

Function Grant.

For these demonstrations, we will create three responsibilities that have the same menu

attached as per the responsibility “OA Framework ToolBox Tutorial”.

We need to make “Supplier Date” Enterable in Create Supplier Window  for responsibility

“XXCUST1 Framework ToolBox Tutorial”; but the same field will be read-only for “XXCUST2

Framework ToolBox Tutorial” and “XXCUST3 Framework ToolBox Tutorial” responsibilities.

This can be easily done using personalization. But if you have dozens of responsibilities, some

of which you wish to make read only responsibilities. In such cases, it is not practical to go and

personalize each and every responsibility and retrospectively maintain personalizations at so

many levels. Therefore you can create a Security Function and grant that Security Function to a

set of responsibilities. There are some “minor bugs” in R12 when it comes to defining these

grants. Therefore you should follow these steps exactly in the sequence shown in this white

paper.

Responsibility 1

Page 3: Spel

 

Responsibility 2

 

Responsibility 3

Assign these three responsibilities to your username

Page 4: Spel

 

Step 1: Create function XXCUST_SUPPLIER_DATE_ENTERABLE

            This function will be available to XXCUST1 Responsibility

            This function will not be available to XXCUST2 Responsibility

            This function will not be available to XXCUST3 Responsibility

      This function will be of Type JSP

          Name = XXCUST Function Make Supplier Date Enterable

          Code= XXCUST_SUPPLIER_DATE_ENTERABLE

          Type=SSWA jsp Function

HTML Call= OA.jsp?page=/dummy

Page 5: Spel

 

Step 2: In Menu screen, Create Permission Set named “XXCUST Permission Set Supplier

Date”

Menu = XXCUST_PERMISSION_SET_SUP_DT

User Menu Name = XXCUST Permission Set Supplier Date

Menu Type = Permission Set

Page 6: Spel

Add Function “XXCUST Function Make Supplier Date Enterable” to this, and ensure that Global

Grant is removed by unchecking checkbox “Grant”.

Save the data.

 

Step3

Grant this permission set “XXCUST Permission Set Supplier Date” to XXCUST1% responsibility

Navigate to Functional Administrator

Click on Security Tab, and click on Grants, and then Create Grant

Name= XXCUST Grant Supplier Date Data Entry

Grantee Type = Group of users

Grantee = XXCUST1%

                Select the Responsibility “XXCUST1 Framework ToolBox Tutorial” from LOV

[source=FND_RESP]

Also enter the responsibility name

Click on Next, and in Set field, attach the permission set “XXCUST Permission Set Supplier

Date”

Page 7: Spel
Page 8: Spel

Click Next and then click Finish.

Effectively by doing this step, we have granted all the functions within the Permission Set

“XXCUST Permission Set Supplier Date” to a group of users that have responsibility “XXCUST1

Framework ToolBox Tutorial”. Therefore when user accesses a page via responsibility

“XXCUST1 Framework ToolBox Tutorial” then they will have access to Function

XXCUST_SUPPLIER_DATE_ENTERABLE

Clear the global cache via Functional Administrator, and now in the end we need to attach

Function via SPEL to read only property.

 

Step 4

Now personalize and set the Read Only Property to SPEL with value of SPEL being $

{oa.FunctionSecurity.XXCUST_SUPPLIER_DATE_ENTERABLE}

Navigate to responsibility “XXCUST1 Framework ToolBox Tutorial”

Click on Transactions and then Click create supplier

Page 9: Spel

Click on personalize page on top right corner

And personalize Supplier Start Date

In the read only property, at site level, select SPEL and enter $

{oa.FunctionSecurity.XXCUST_SUPPLIER_DATE_ENTERABLE}

Click Apply and then return to application.

Clear cache via Functional Administrator going to Caching Framework/Global Configuration

Navigate to responsibility “XXCUST2 Framework ToolBox Tutorial” or XXCUST3% responsibility

Click on Transactions and then Click create supplier

You will find that Start Date for Supplier is read-only

Page 10: Spel

However, in responsibility “XXCUST1 Framework ToolBox Tutorial”, this field will be enterable,

as “XXCUST1 Framework ToolBox Tutorial” responsibility has been granted permissions to

function XXCUST_SUPPLIER_DATE_ENTERABLE via permission set. This function is

attached read-only property.

In future, you can attach SPEL to $

{oa.FunctionSecurity.XXCUST_SUPPLIER_DATE_ENTERABLE} for any other fields in these

responsibility. Once that personalization with SPEL has been accomplished, then you may

simply grant permissions on that permission set to the desired responsibilities.