The XDOLoader utility is a Java-based command line program to load template (RTF, PDF, and XSL-FO), XML, and XSD files to the XML Publisher database tables. Before uploading any xml template you need to upload your concurrent program (if any) and data definitions through the FNDLOAD utility.
General Syntax to execute the XDOLoader utility as follows:
% java oracle.apps.xdo.oa.util.XDOLoader UPLOAD \Sample script to run the XDOLoader utility to upload a xml template:
echo "----------------------------------------------------------------------"
echo "Please enter the following details needed for the XML XDOLoad process"
echo "This details can be found in the TNS entry"
echo "----------------------------------------------------------------------"
echo "Enter Apps password =>"
read apps_pw
echo "Enter Host TNS Database Server name =>"
read v_host
echo "Enter Host Database TNS Port Number =>"
read v_port
echo "Enter Host Database SID name =>"
read v_sid
echo "Uploading rtf(XXFIN_SAMPLE_TEMPLATE.rtf) for the XML Template Definition"
java oracle.apps.xdo.oa.util.XDOLoader UPLOAD \
-DB_USERNAME apps \
-DB_PASSWORD $apps_pw \
-JDBC_CONNECTION $v_host:$v_port:$v_sid \
-LOB_TYPE TEMPLATE \
-APPS_SHORT_NAME "IBY" \
-LOB_CODE "XXFIN_TEMPLATE_CODE" \
-LANGUAGE en \
-XDO_FILE_TYPE RTF-ETEXT \
-FILE_CONTENT_TYPE 'text/html' \
-FILE_NAME "$XXFIN_TOP/templates/XXFIN_SAMPLE_TEMPLATE.rtf" \
-CUSTOM_MODE FORCE
echo "Finish uploading rtf(XXFIN_SAMPLE_TEMPLATE.rtf) for the XML Template Definition"
You can run the below query to see the details of your uploaded Template in the database.SELECT * FROM XDO_LOBS ORDER BY LAST_UPDATE_DATE DESC;
>
This trigger is fired each time the folder does certain operations that you may need to further process. ’global.folder_action’ contains the name of the process, and ’global.folder_field’ holds the name of the relevant field, if any, stripped of the block name. Specific callbacks may populate other global variables. The FOLDER_RETURN_ACTION trigger is optional. You should code it if you need to perform logic on any of the supported events.
Example:-
Following is code written in FOLDER_RETURN_ACTION trigger to allow update for ‘COL1’, ‘COL2’ and ‘COL3’ in the folder block:-
DECLARE
field_name VARCHAR2(30);
BEGIN
IF (:global.folder_action = ’SHOW–FIELD’) THEN
field_name:= NAME_IN(’global.folder_field’);
IF (field_name IN (’COL1’, ’COL2’, ’COL3’)) THEN
app_item_property.set_property (
’’||’.’||field_name,
ALTERABLE,
PROPERTY_ON);
END IF;
END IF;
END;
Step – 4 Create Prompt Block
Create a one record block to hold the fields that act as prompts for the folder block. For every item in the folder block that may be displayed, the prompt block must contain an item of the same name (except for the record indicator and the switcher). The initial settings of the prompts drive the layout of the Default Screen, including item width and tabbing sequence.
Typically one would name the prompt block _PROMPT, for example, ORDERS_PROMPT.
Each ’prompt’ field must have the following characteristics:
Property Class: DYNAMIC_PROMPT
Sequence: Must match the name of an item in the folder block. Sequence the first
set of fields to be displayed properly, starting at 1. This drives the
folder TAB order.
X Position: Positioned at runtime.
Y Position: .05.
Width: Dictates the width of the corresponding field. Make sure the width is adequate to display the text for the prompt fully. The width only needs to
account for English text – no translation expansion space is needed. Specifying the width as 0.1” causes it to adjust automatically based on the text it contains. For checkboxes, specify a width of 0.1”
Alignment: Usually Start, but follows alignment of data in corresponding folder
block field. Prompts for check boxes are always Center aligned.
Canvas: Stacked canvas.
Default: The text for the prompt. The translation tool translates this
automatically.
Displayed: True only for those fields you want displayed on the default screen;
otherwise, False.
Create Special Fields in Prompt Block
The following special fields must exist in the prompt block:-
Field: FOLDER_OPEN
PROPERTY CLASS: FOLDER_OPEN
X POSITION: 0.1”
Y POSITION: Y_OFFSET
CANVAS: content canvas
Field: FOLDER_TITLE
PROPERTY CLASS: DYNAMIC_TITLE
X POSITION: 0.4”
WIDTH: 4”
Y POSITION: Y_OFFSET +.05
CANVAS: content canvas
Field: FOLDER_DUMMY
PROPERTY CLASS: FOLDER_DUMMY
CANVAS: TOOLBAR
Field: ORDER_BY1,ORDER_BY2,ORDER_BY3
PROPERTY CLASS: FOLDER_ORDERBY
X POSITION: Set at runtime.
Y POSITION: For content canvas Y_OFFSET+.5+(.25*Rows)
For stack canvas .25+(.25*Rows)
CANVAS: If it’s a fixed field specify content canvas otherwise specify stack
canvas.
Step – 5 Code Form Level Trigger
The following form–level triggers must exist in order for a folder block to operate correctly:
• Trigger: WHEN–WINDOW–RESIZED:
IF :system.event_window IN (’<>’) THEN
app_folder.event(’WHEN–WINDOW–RESIZED’);
END IF;
• Trigger: KEY–CLRFRM:
app_folder.event(’KEY–CLRFRM’);
This call must be made anywhere a clear_form is issued. This cause the folder code to repaint the prompts and folder titles as if they were normal boilerplate.
• Trigger: WHEN–NEW–FORM–INSTANCE:
app_folder.define_folder_block('OBJECT NAME',
’’,
’’,
’’
’’,
[’’]);
Note: All parameters must be passed in UPPERCASE.
Example:
App_flolder.define_folder_block(‘PO_HEADER’
,’POHEADER’
,’POHEADER_PROMPT’
,’POHEADER_STK’
,POHEADER_MAIN’)
Choose the object name carefully; it must be unique across all products. Prefix it with the application short name, for example ’FND_ALERTS’. This object name identifies all folder definitions that users define and save for your folder, and it appears in the Administer Folders form as the Folder Set, so you should make the object name descriptive and readable.
’DISABLED FUNCTIONS’ can be a string combining any of the following. Specifying that a function is disabled prevents the user from performing it.
• OPEN
• TOOLS: Disables everything except OPEN. Note that if the profile FOLDERS:ALLOW_CUSTOMIZATION is ’N’, all tools are automatically disabled except Open.
• ORDERBY
• NEW
• SAVE: Disables Save and Save As.
• AUTOQUERY: Should be disabled for any detail block.
• PUBLIC
• DEFAULT
• DELETE
• SHOW
• HIDE
• MOVE
• WIDEN
• SHRINK
• AUTOSIZE
• PROMPT
• QUERY
Following example will disable ‘ORDER BY’ and ‘HIDE’ function in the folder form:
App_flolder.define_folder_block(‘PO_HEADER’
,’POHEADER’
,’POHEADER_PROMPT’
,’POHEADER_STK’
, POHEADER_MAIN’
,’ORDERBY HIDE’);
• User-named Trigger: FOLDER_ACTION
app_folder.event(:global.folder_action);
Do not insert additional code in this trigger. It is used to allow the menu and folder toolbar to communicate with the folder library that is attached to the form.
• User-named Trigger: FOLDER_RETURN_ACTION
NULL;
This trigger must exist at form–level to handle the case in which it has not been coded at block–level.
The FOLDER_RETURN_ACTION trigger supports the following events:
• SHOW_FIELD: The field in :global.folder_field has just been made visible. In updateable blocks, you may need to set some properties (such as Update Allowed, Required, etc.). Fields can become visible in Enter Query mode or normal mode. When a folder is opened, all fields currently displayed are hidden, even if they are in the new folder; thus this call is made for each field as it is redisplayed.
• ADD_FILED: Populates :global.folder_field. Called at the end of a user–initiated ’Show Field’ event that results in a field being displayed. The ’SHOW–FIELD’ callback is also triggered before this callback.
• HIDE_FIELD: Populates :global.folder_field. Called at the end of a user–initiated ’Hide Field’ event that results in a field being hidden.
• OPEN_FOLDER: Called at the end of an ’Open Folder’ event that results in a folder being loaded, but before the folder autoqueries. Populates global.folder_id.
• SET-WHERE-CLAUSE: Called during a ’Save Folder’ event, before setting the where clause that will be saved with the folder. Sets global.folder_action_allowed ’TRUE’. If the value of :global.folder_action_allowed is changed to anything but ‘TRUE’ by the FOLDER_RETURN_ACTION trigger, the WHERE clause saved with the folder is null.
• RESET-WHERE-CLAUSE: Called when the block WHERE clause is set back to the developer’s WHERE clause, because the user has selected Folder–>Reset query from the menu, or because the user has selected Folder–>New from the menu.
• SAVE-FOLDER: Called at the end of a ’Save Folder’ event, immediately before the Commit. Populates :global.folder_id.
• DELETE-FOLDER: Called during a ’Delete Folder’ event, immediately before the Commit. Populates :global.folder_id.
• CONFIRM-HIDE-FIELD: Called during a user–initiated ’Hide Field’ event, immediately after doing all other checks that the field can be cut (for example, it is not on the content or fixed canvas, it is not the only field on the stacked canvas, etc.). The variable ’global.folder_action_allowed’ is seeded with ’TRUE’. If this variable is changed to anything but ’TRUE’, the action is aborted and the user cannot hide the field. By default, if the user attempts to hide a required field, CONFIRM–HIDE-FIELD automatically prevents it, and users are allowed to hide non–required fields. You can override this behavior by changing the value of :global.folder_action_allowed to either ’TRUE’ (allow hiding) or ’FALSE’ (prevent hiding non–required fields) in the CONFIRM–HIDE–FIELD callback to the FOLDER_RETURN_ACTION trigger.
• AUTOQUERY: Called when a folder loads and automatically executes a query.
• CONFIRM-AUTOQUERY: Called when a folder that is designed to autoquery opens. ’GLOBAL.FOLDER_ACTION_ALLOWED’ is seeded with ’TRUE’. If this variable is changed to anything but ’TRUE’, the folder does not autoquery.
Example: Prevent Hiding a Field
Prevent the user from hiding the (non–required) ’PERIOD_NAME’ field:
Trigger: FOLDER_RETURN_ACTION (block–level):
IF(:global.folder_action = ’CONFIRM–HIDE–FIELD’) THEN
IF :global.folder_field = ’PERIOD_NAME’ THEN
:global.folder_action_allowed := ’FALSE’;
END IF;
END IF;
