Page hyperlink
A page hyperlink takes this URL structure:
http(s)://<host>.<domain>:<port>/OA_HTML/a/#/<page Id>/<object Id>
For example:
https://myhost.mycompany.com/OA_HTML/a/#/leave-and-absences/123
The grey part remains static throughout an Applaud HCM installation. The bold part changes for each page and is made of two important components: the page Id and an optional object Id.
page Id
The page Id, sometimes called a slug, is a unique identifier for each page. You are not allowed to publish two pages with the same page Id, although you can create draft pages with duplicate page Ids with a view to only having one published at any point in time.
When the app is upgraded from a previous version the page Ids will default to the related Oracle Menu Id. You can change this to something more meaningful; please see Upgrading from previous versions.
Tip: set the page Id to a meaningful name that your users will understand.
You configure Applaud HCM to link pages together by their page Ids. When updating page Ids at a later point take care to update any places that may link to the old page Ids.
object Id
The object Id is an optional text identifier that is used to restrict the blocks and content within a block on a page. In the below example, the leave-and-absences page specifies that its Object Id Format should be {PERSON_ID}. So it would expect a URL in this format:
leave-and-absences/{PERSON_ID}
For example:
leave-and-absences/123
This tells the page that 123 is a PERSON_ID. PERSON_ID=123 is then passed to all the blocks on the page so that those blocks can restrict content relevant to this particular person.
The object Id doesn't have to be a person Id; in this example, it's a vacancy Id:
vacancy-detail/{VACANCY_ID}, eg, vacancy-detail/456
It can also contain multiple bits of information in a single text string:
purchase-order-line/{PO_ID}_{PO_LINE_ID}, eg, purchase-order-line/12345_67890
In this example, 12345 is a Purchase Order Id; 67890 is a Purchase Order Line Id.
An underscore must be used to separate an Object Id that contains multiple bits of information.
object Id handler
The object Id handler is an optional PL/SQL procedure that allows the database to be queried to generate additional key-value pairs that are passed to the blocks to restrict access control and content.
For example, the majority of HCM pages use a {PERSON_ID} Object Id format. This automatically creates a key-value pair of PERSON_ID={Object Id from URL}. In many cases, no Object Id Handler is function is required. However, if blocks require additional keys to be available that may not be passed in the URL you can write a handler function to set those additional keys.
For example, the majority of HCM pages use a handler function called xxas_per_pkg.per_and_primary_asg_ctx. This function uses the given object Id to set two additional keys:
- ASSIGNMENT_ID = primary employee or contingent worker assignment
- USER_ID = logged on user Id
This means that the blocks on these pages have access to 3 keys: PERSON_ID, ASSIGNMENT_ID, and USER_ID.
Here are some examples of other handlers used in seeded pages:
Handler | Description |
---|---|
xxas_vacancy_pkg.vacancy_and_logon_per_ctx | Expects a vacancy Id and returns a VACANCY_ID and PERSON_ID key, with the PERSON_ID being set to the person of the logged-on user. |
xxas_perf_plans_pkg.enrollment_ctx | Expects a person Id and/or performance plan enrollment Id. Eg: 123_4567 or 123_ or _4567. It returns PERSON_ID, ASSIGNMENT_ID, PERF_PLAN_ID and PERF_PLAN_ENROLLMENT_ID keys. |
Blocks use these keys to restrict access and contents to just information that's relevant. For example, restricting a list of phone numbers for a given PERSON_ID; restricting goals to just those within a PERF_PLAN_ENROLLMENT_ID; restricting notification details to a single NOTIFICATION_ID.
To create your own object Id handler procedure, you will need to write a PL/SQL program with this signature:
-- Name : my_object_id_handler_ctx
-- ------------------------------------------------------------------------ *
FUNCTION my_object_id_handler_ctx
(p_object_id IN varchar2
,p_keys IN OUT NOCOPY xxas_com_keys_type);
These parameters should be set as follows:
Parameter | Description |
---|---|
p_object_id | The object Id passed in from the page's URL |
p_keys | The keys object that passes in the automatically created keys and allows you to specify additional keys |
Here's an example of a object Id handler that expects an {ASSIGNMENT_ID} object Id and additional sets a PERSON_ID key:
-- Name : asg_object_id_handler_ctx
-- ------------------------------------------------------------------------ *
PROCEDURE asg_object_id_handler_ctx
(p_object_id IN varchar2
,p_keys IN OUT NOCOPY xxas_com_keys_type)
IS
l_person_id number;
l_assignment_id number;
BEGIN
l_assignment_id := to_number(p_object_id);
l_person_id := xxas_com_asg_pkg.get_person_from_asg(l_assignment_id);
p_keys.set_key('PERSON_ID', l_person_id);
END asg_object_id_handler_ctx;
Page title
The page title is required and is shown as the title of a browser tab. It's also shown as a label inside the page if the Hide title bar is not set.
If the page's title is hidden, you will not be able to see any Page actions.
You can choose to anchor the page title so that when a user scrolls down the page title remains visible. This is particularly useful when a page has an important call-to-action such as a Submit button - it saves the user having to scroll up to press the button.
You can also use a dynamic page title instead of a static one. To do this, set Dynamic title property to the name of a PL/SQL package function that has this signature:
-- Name : some_page_title
-- ------------------------------------------------------------------------ *
FUNCTION some_page_title
(p_object_id IN VARCHAR2 DEFAULT NULL) RETURN VARCHAR2;
The p_object_id parameter contains the value of the object Id passed in the page hyperlink. for example, if the object Id contains a person Id you would set the person Id as follows:
Please refer to object Id for more information.
Page layouts
A page has 3 available layouts. The stacked layout simply lays out blocks vertically stacked in their order sequence.
2-column and 3-column layouts use a masonry layout. With these layouts, the blocks are organized to fit the browser size and are automatically re-rendered when a browser is resized. In the top row the blocks are laid out left-to-right but then in subsequent rows blocks are laid out according to the columns with the most available space. With 2-column and 3-column layouts, you cannot control which blocks appear in which columns.
When you upgrade from previous versions the app attempts to automatically set the preferred layout for a page according to the number of blocks on that page. Please refer to Upgrading from previous versions for more information.
Smaller screens, such as phones, phablets, and some tablets in portrait, will respond down to a stacked layout even if you specify the page as 2-column or 3-column. Some medium-sized screens may use a 2-column layout even if you specify a 3-column.