1 package hr_utility as
2 /* $Header: pyutilty.pkh 120.0.12010000.2 2008/12/12 10:52:39 sathkris ship $ */
3 /*
4 Copyright (c) Oracle Corporation (UK) Ltd 1993.
5 All rights reserved
6
7 Name: hr_utility
8
9 Description:
10
11 -- Cover routines for FND_MESSAGE
12 -- HR trace routines
13 -- Miscellaneous other things. See also HR_GENERAL
14
15 NEW 8.x DEPENDENCIES
16
17 Autonomous Transaction (8.1.x)
18 DBMS_SYSTEM (8.0.x)
19
20
21 Change List
22 -----------
23 dkerr 11-DEC-2002 Added NOCOPY hint to OUT and IN OUT parameters
24 dkerr 03-DEC-2002 Added debug_enabled()
25 nbristow 28-FEB-2002 Added dbdrv statements.
26 nbristow 28-FEB-2002 Changed read_trace_table to have a smaller PL/SQL
27 table. NT could not support a large table.
28 P.Walker 24-AUG-2001 Removed pragma restriction from set_location()
29 to enable AOL Process Logging
30 added following procedures:
31 log_at_statement_level()
32 log_at_procedure_level()
33 log_at_event_level()
34 log_at_exception_level()
35 log_at_error_level()
36 log_at_unexpected_level()
37 switch_logging_on()
38 switch_logging_off()
39 N.Bristow 18-JUL-2001 Added read_trace_table to improve PYUPIP
40 performance.
41 D Kerr 22-MAR-1999 Added set_trace_options
42 T Habara 03-DEC-1998 Added pragma WNDS to all the procedures and
43 functions except for trace_on and fnd_insert.
44 M Reid 06-NOV-1998 Added language parameter to chk_product_install
45 and created overloaded version.
46 KKOH 08-SEP-1998 Added PRAGMA RESTRICT_REFERENCES command
47 to allow HR_DISCOVERER.GET_ACTUAL_BUDGET_VALUES
48 function to call a procedure HRGETACT.GET_ACTUALS
49 which references this package
50
51 D Kerr 20-JUL-1998 - Changes to hr_trace to ensure compatibility
52 with NT.
53 - Added trace_udf to allow FastFormula to
54 be traced.
55 D Kerr 09-JAN-1997 Added WNDS purity assertions to
56 set_location and trace.
57 This depends on fnd_message.raise_error
58 having the same (519748)
59 K Mundair 02-JUN-1997 Added procedure chk_product_install
60 D Kerr 22-DEC-1996 Added trace_on overloads,
61 read_trace_pipe and get_trace_id.
62 D Harris 14-SEP-1993 Changed the HR_ERROR_NUMBER number
63 from -20000 to -20001 form forms 4 and
64 10x.
65 P Gowers 05-APR-1993 Add get_message_details, get_token_details
66 P Gowers 02-MAR-1993 Add set_message_token which translates token
67 P Gowers 20-JAN-1993 Big bang.
68 C Carter 12-OCT-1999 Removed pragma restriction from SET_MESSAGE
69 and ORACLE_ERROR for bug 1027169.
70 Sathkris 12-DEC-2008 Added get_icx_val function
71 */
72 --
73 -- Public Package variables
74 --
75
76 --
77 type t_varchar180 is table of varchar2(180) index by binary_integer;
78 --
79 -- define HR error number
80 HR_ERROR_NUMBER CONSTANT number := -20001;
81
82 --
83 -- PIPE timeout constants
84 --
85 PIPE_READ_TIMEOUT constant number := 600 ;
86 PIPE_PUT_TIMEOUT constant number := 300 ;
87
88 --
89 -- Note, pragma only accepts numeric literals for error number, but this
90 -- number MUST be the same as the package global constant HR_ERROR_NUMBER
91 --
92 hr_error exception;
93 pragma exception_init (hr_error, -20001);
94 --
95
96 procedure trace (trace_data in varchar2);
97 pragma restrict_references (trace , WNDS) ;
98 -- The following overloads are used to overcome the forms PL/SQL v1
99 -- limitation which prevents defaults from being used in stored
100 -- procedures.
101 -- See package body for details of calls
102 procedure trace_on ;
103 procedure trace_on (trace_mode in varchar2 ) ;
104 procedure trace_on (trace_mode in varchar2,
105 session_identifier in varchar2 ) ;
106 procedure trace_off;
107 pragma restrict_references (trace_off , WNDS);
108
109 -- UDF covers
110 -- DK 26-MAR-98
111 -- Added UDF to allow formulas to be traced.
112 -- This performanes the same as trace() however it has to be
113 -- a function as procedures are not yet supported from formula
114 -- It returns 'TRUE' if tracing is enabled otherwise FALSE.
115 --
116 function trace_udf (trace_data in varchar2) return varchar2 ;
117 pragma restrict_references (trace_udf , WNDS);
118
119 ---------------------------------- hr_error ----------------------------------
120 /*
121 NAME
122 hr_error - Returns the equivalent sqlcode of hr_error exception
123 DESCRIPTION
124 Needed because forms 3.0/4.0 cannot handle package exception 'hr_error'
125 function hr_error return number;
126 */
127 -------------------------------- clear_message ----------------------------
128 /*
129 NAME
130 clear_message
131 DESCRIPTION
132 clears current message text and number
133 */
134 procedure clear_message;
135 pragma restrict_references (clear_message , WNDS);
136 -------------------------------- set_message --------------------------------
137 /*
138 NAME
139 set_message
140 DESCRIPTION
141 Calls fnd_dict package to set up the named error
142 */
143 procedure set_message (applid in number, l_message_name in varchar2);
144 --pragma restrict_references (set_message , WNDS);
145 ------------------------------ set_message_token ------------------------------
146 /*
147 NAME
148 set_message_token
149 DESCRIPTION
150 Calls fnd_dict set set up a message token value
151 */
152 procedure set_message_token (l_token_name in varchar2,
153 l_token_value in varchar2);
154 pragma restrict_references (set_message_token , WNDS);
155 ------------------------------ set_message_token ------------------------------
156 /*
157 NAME
158 set_message_token
159 DESCRIPTION
160 Overloaded: Sets up a translated message token
161 */
162 procedure set_message_token (l_applid in number,
163 l_token_name in varchar2,
164 l_token_message in varchar2);
165 pragma restrict_references (set_message_token , WNDS);
166 -------------------------------- get_message --------------------------------
167 /*
168 NAME
169 get_message
170 DESCRIPTION
171 Calls fnd_dict to assemble the current message text and return it
172 */
173 function get_message return varchar2;
174 pragma restrict_references (get_message , WNDS);
175 ----------------------------- get_message_details -----------------------------
176 /*
177 NAME
178 get_message_details
179 DESCRIPTION
180 Gets the name and the application short name of the message last set
181 */
182 procedure get_message_details (msg_name in out nocopy varchar2,
183 msg_appl in out nocopy varchar2);
184 pragma restrict_references (get_message_details , WNDS);
185 -------------------------------- set_warning --------------------------------
186 /*
187 NAME
188 set_warning
189 DESCRIPTION
190 Sets the package warning flag to indicate that a warning has occurred
191 */
192 procedure set_warning;
193 pragma restrict_references (set_warning , WNDS);
194 -------------------------------- check_warning --------------------------------
195 /*
196 NAME
197 check_warning
198 DESCRIPTION
199 Returns the value of the warning flag
200 */
201 function check_warning return boolean;
202 pragma restrict_references (check_warning , WNDS);
203 -------------------------------- clear_warning --------------------------------
204 /*
205 NAME
206 clear_warning
207 DESCRIPTION
208 Resets the package warning flag
209 */
210 procedure clear_warning;
211 pragma restrict_references (clear_warning , WNDS);
212 -------------------------------- set_location --------------------------------
213 /*
214 NAME
215 set_location
216 DESCRIPTION
217 Sets package variables to store location name and stage number which
218 enables unexpected errors to be located more easily
219 */
220 procedure set_location (procedure_name in varchar2, stage in number);
221 -- pragma restrict_references (set_location , WNDS) ;
222 -------------------------------- oracle_error --------------------------------
223 /*
224 NAME
225 oracle_error
226 DESCRIPTION
227 Sets generic oracle error message and passes the sqlcode, and error
228 location information
229 */
230 procedure oracle_error (oracode in number);
231 --pragma restrict_references (oracle_error , WNDS);
232 -------------------------------- raise_error --------------------------------
233 /*
234 NAME
235 raise_error
236 DESCRIPTION
237 Performs raise_application_error but always with the same error number
238 HR_ERROR_NUMBER for consistency
239 */
240 procedure raise_error;
241 pragma restrict_references (raise_error , WNDS);
242 -------------------------------- fnd_insert --------------------------------
243 /*
244 NAME
245 fnd_insert
246 DESCRIPTION
247 Inserts a row into FND_SESSIONS for the date passed for the current
248 session id
249 */
250 procedure fnd_insert (l_effective_date in date);
251
252 -------------------------------- read_trace_pipe ----------------------------
253 /*
254 NAME
255 read_trace_pipe
256 DESCRIPTION
257 Reads the next message from the pipe
258 Bug ?????? Using a default parameter was causing problems on NT
259 For now include an overload
260 */
261 procedure read_trace_pipe(p_pipename in varchar2,
262 p_status in out nocopy number,
263 p_retval in out nocopy varchar2 ) ;
264 pragma restrict_references (read_trace_pipe , WNDS);
265
266 procedure read_trace_pipe(p_pipename in varchar2,
267 p_timeout in number,
268 p_status in out nocopy number,
269 p_retval in out nocopy varchar2 ) ;
270 pragma restrict_references (read_trace_pipe , WNDS);
271 -------------------------------- read_trace_table -----------------------------
272 /*
273 NAME
274 read_trace_table
275 DESCRIPTION
276 Reads the next message from the named pipe into a PL/SQL table.
277
278 If the pipename is PIPEnnnn then after the given timeout period.
279 The routine will check whether the corresponding session still
280 exists. Support for other types may be added later.
281
282 PARAMETERS
283
284 p_pipename Name of the pipe
285 p_status The return status from DBMS_PIPE.RECEIEVE_MESSAGE
286 p_retval The text PL/SQL table containing the messages
287 p_messages The maximum number of entries that should be placed
288 in the PL/SQL table.
289 p_cnt_mess The number of entries actually created in PL/SQL
290 table.
291 */
292 procedure read_trace_table(p_pipename in varchar2,
293 p_status in out nocopy number,
294 p_retval in out nocopy t_varchar180,
295 p_messages in number,
296 p_cnt_mess in out nocopy number );
297 -------------------------------- get_trace_id -------------------------------
298 /*
299 NAME
300 get_trace_id
301 DESCRIPTION
302 Returns the name of the PIPE that HR trace statements are written
303 to
304 */
305 function get_trace_id return varchar2 ;
306 pragma restrict_references (get_trace_id , WNDS);
307 -------------------------------- chk_product_install -------------------------
308 /*
309 NAME
310 chk_product_install
311 DESCRIPTION
312 Checks whether the product specified is installed for the legislation
313 specified
314 PARAMETERS
315 p_product Name of the product in initcap
316 p_legislation Legislation code(US,GB...)
317 */
318 function chk_product_install (
319 p_product VARCHAR2,
320 p_legislation VARCHAR2,
321 p_language VARCHAR2) return boolean;
322 pragma restrict_references (chk_product_install , WNDS);
323
324 function chk_product_install (
325 p_product VARCHAR2,
326 p_legislation VARCHAR2) return boolean;
327 pragma restrict_references (chk_product_install , WNDS);
328
329 ----------------------------- log_at_statement_level -------------------------
330 /*
331 NAME
332 log_at_statement_level
333 DESCRIPTION
334
335 Used for low level logging messages giving maximum detail
336 Example: Copying string from buffer xyz to buffer zyx
337
338 PARAMETERS
339
340 p_product Short name of the application e.g. 'pay', 'per',...
341
342 p_procedure_name name of calling procedure including package name
343 eg. package_name.procedure_name
344
345 p_label A unique name for the part within the procedure. The major
346 reason for providing the label is to make a module name uniquely
347 identify exactly one log call. This will allow support analysts
348 or programmers who look at logs to know exactly which piece of code
349 produced your message, even without looking at the message (which
353 routines and files into a group that can be enabled or disabled
350 may be translated). So make labels for each log statement unique
351 within a routine.
352 If it is desired to group a number of log calls from different
354 atomically, this can be done with a two part label. The first part
355 would be the functional group name, and the second part would be
356 the unique code location. For instance, descriptive flexfield
357 validation code might have several log calls in different places
358 with labels desc_flex_val.check_value,
359 desc_flex_val.display_window, and desc_flex_val.parse_code. Those
360 would all be enabled by enabling module fnd.%.desc_flex_val even
361 though they all exist in different code locations.
362 Examples: begin, lookup_app_id, parse_sql_failed,
363 myfeature.done_exec
364
365 p_message This is the string that will actually be written to the log file.
366 It will be crafted by the programmer to clearly tell the reader
367 whatever information needs to be conveyed about the state of the
368 code execution.
369 if p_message is omitted the message will default to p_label
370 */
371
372 procedure log_at_statement_level
373 (p_product IN VARCHAR2
374 ,p_procedure_name IN VARCHAR2
375 ,p_label IN VARCHAR2
376 ,p_message IN VARCHAR2 default null);
377
378 ----------------------------- log_at_procedure_level -------------------------
379 /*
380 NAME
381 log_at_procedure_level
382
383 DESCRIPTION
384
385 Used to log messages called upon entry and/or exit from a routine
386 Example: Entering routine fdllov()
387
388 PARAMETERS
389
390 p_product Short name of the application e.g. 'pay', 'per',...
391
392 p_procedure_name name of calling procedure including package name
393 eg. package_name.procedure_name
394
395 p_label A unique name for the part within the procedure. The major
396 reason for providing the label is to make a module name uniquely
397 identify exactly one log call. This will allow support analysts
398 or programmers who look at logs to know exactly which piece of code
399 produced your message, even without looking at the message (which
400 may be translated). So make labels for each log statement unique
401 within a routine.
402 If it is desired to group a number of log calls from different
403 routines and files into a group that can be enabled or disabled
404 atomically, this can be done with a two part label. The first part
405 would be the functional group name, and the second part would be
406 the unique code location. For instance, descriptive flexfield
407 validation code might have several log calls in different places
408 with labels desc_flex_val.check_value,
409 desc_flex_val.display_window, and desc_flex_val.parse_code. Those
410 would all be enabled by enabling module fnd.%.desc_flex_val even
411 though they all exist in different code locations.
412 Examples: begin, lookup_app_id, parse_sql_failed,
413 myfeature.done_exec
414
415 p_message This is the string that will actually be written to the log file.
416 It will be crafted by the programmer to clearly tell the reader
417 whatever information needs to be conveyed about the state of the
418 code execution.
419 if p_message is omitted the message will default to p_label
420 */
421
422 procedure log_at_procedure_level
423 (p_product IN VARCHAR2
424 ,p_procedure_name IN VARCHAR2
425 ,p_label IN VARCHAR2
426 ,p_message IN VARCHAR2 default null);
427
428 -------------------------------- log_at_event_level -------------------------
429 /*
430 NAME
431 log_at_event_level
432 DESCRIPTION
433
434 Used for high level logging message
435 Examples: User pressed "Abort" button
436 Beginning establishment of apps security session
437
438 PARAMETERS
439
440 p_product Short name of the application e.g. 'pay', 'per',...
441
442 p_procedure_name name of calling procedure including package name
443 eg. package_name.procedure_name
444
445 p_label A unique name for the part within the procedure. The major
446 reason for providing the label is to make a module name uniquely
447 identify exactly one log call. This will allow support analysts
448 or programmers who look at logs to know exactly which piece of code
449 produced your message, even without looking at the message (which
450 may be translated). So make labels for each log statement unique
451 within a routine.
452 If it is desired to group a number of log calls from different
453 routines and files into a group that can be enabled or disabled
454 atomically, this can be done with a two part label. The first part
455 would be the functional group name, and the second part would be
459 desc_flex_val.display_window, and desc_flex_val.parse_code. Those
456 the unique code location. For instance, descriptive flexfield
457 validation code might have several log calls in different places
458 with labels desc_flex_val.check_value,
460 would all be enabled by enabling module fnd.%.desc_flex_val even
461 though they all exist in different code locations.
462 Examples: begin, lookup_app_id, parse_sql_failed,
463 myfeature.done_exec
464
465 p_message This is the string that will actually be written to the log file.
466 It will be crafted by the programmer to clearly tell the reader
467 whatever information needs to be conveyed about the state of the
468 code execution.
469 if p_message is omitted the message will default to p_label
470 */
471
472 procedure log_at_event_level
473 (p_product IN VARCHAR2
474 ,p_procedure_name IN VARCHAR2
475 ,p_label IN VARCHAR2
476 ,p_message IN VARCHAR2 default null);
477
478 ----------------------------- log_at_exception_level -------------------------
479 /*
480 NAME
481 log_at_exception_level
482 DESCRIPTION
483 Used to to log a message when an internal routine is returning a failure
484 code or exception, but the error does not necessarily indicate a problem
485 at the user's level.
486
487 Examples: Profile ABC not found,
488 Networking routine XYZ could not connect; retrying.
489 File not found (in a low-level file routine)
490 Database error (in a low-level database routine like afupi)
491 PARAMETERS
492
493 p_product Short name of the application e.g. 'pay', 'per',...
494
495 p_procedure_name name of calling procedure including package name
496 eg. package_name.procedure_name
497
498 p_label A unique name for the part within the procedure. The major
499 reason for providing the label is to make a module name uniquely
500 identify exactly one log call. This will allow support analysts
501 or programmers who look at logs to know exactly which piece of code
502 produced your message, even without looking at the message (which
503 may be translated). So make labels for each log statement unique
504 within a routine.
505 If it is desired to group a number of log calls from different
506 routines and files into a group that can be enabled or disabled
507 atomically, this can be done with a two part label. The first part
508 would be the functional group name, and the second part would be
509 the unique code location. For instance, descriptive flexfield
510 validation code might have several log calls in different places
511 with labels desc_flex_val.check_value,
512 desc_flex_val.display_window, and desc_flex_val.parse_code. Those
513 would all be enabled by enabling module fnd.%.desc_flex_val even
514 though they all exist in different code locations.
515 Examples: begin, lookup_app_id, parse_sql_failed,
516 myfeature.done_exec
517
518 p_message This is the string that will actually be written to the log file.
519 It will be crafted by the programmer to clearly tell the reader
520 whatever information needs to be conveyed about the state of the
521 code execution.
522 if p_message is omitted the message will default to p_label
523 */
524
525 procedure log_at_exception_level
526 (p_product IN VARCHAR2
527 ,p_procedure_name IN VARCHAR2
528 ,p_label IN VARCHAR2
529 ,p_message IN VARCHAR2 default null);
530
531 -------------------------------- log_at_error_level -------------------------
532 /*
533 NAME
534 log_at_error_level
535 DESCRIPTION
536 An error message to the user; logged automatically by Message
537 Dict calls to "Error()" routines, but can also be logged
538 by other code.
539
540 Examples: User entered a duplicate value for field XYZ
541 Invalid apps username or password at Signon screen.
542 Function not available
543
544 PARAMETERS
545
546 p_product Short name of the application e.g. 'pay', 'per',...
547
548 p_procedure_name name of calling procedure including package name
549 eg. package_name.procedure_name
550
551 p_label A unique name for the part within the procedure. The major
552 reason for providing the label is to make a module name uniquely
553 identify exactly one log call. This will allow support analysts
554 or programmers who look at logs to know exactly which piece of code
555 produced your message, even without looking at the message (which
556 may be translated). So make labels for each log statement unique
557 within a routine.
558 If it is desired to group a number of log calls from different
559 routines and files into a group that can be enabled or disabled
563 validation code might have several log calls in different places
560 atomically, this can be done with a two part label. The first part
561 would be the functional group name, and the second part would be
562 the unique code location. For instance, descriptive flexfield
564 with labels desc_flex_val.check_value,
565 desc_flex_val.display_window, and desc_flex_val.parse_code. Those
566 would all be enabled by enabling module fnd.%.desc_flex_val even
567 though they all exist in different code locations.
568 Examples: begin, lookup_app_id, parse_sql_failed,
569 myfeature.done_exec
570
571 p_message This is the string that will actually be written to the log file.
572 It will be crafted by the programmer to clearly tell the reader
573 whatever information needs to be conveyed about the state of the
574 code execution.
575 if p_message is omitted the message will default to p_label
576 */
577
578 procedure log_at_error_level
579 (p_product IN VARCHAR2
580 ,p_procedure_name IN VARCHAR2
581 ,p_label IN VARCHAR2
582 ,p_message IN VARCHAR2 default null);
583
584 --------------------------- log_at_unexpected_level -------------------------
585 /*
586 NAME
587 log_at_unexpected_level
588 DESCRIPTION
589 An unexpected situation occurred which is likely to indicate
590 or cause instabilities in the runtime behavior, and which
591 the System Administrator needs to take action on.
592 Note to developers: Think very carefully before logging
593 messages at this level; Administrators are going to get worried
594 and file high priority bugs if your code logs at this level
595 frequently.
596
597 Examples: Out of memory, Required file not found, Data integrity error
598 Network integrity error, Internal error, Fatal database error
599
600 PARAMETERS
601
602 p_product Short name of the application e.g. 'pay', 'per',...
603
604 p_procedure_name name of calling procedure including package name
605 eg. package_name.procedure_name
606
607 p_label A unique name for the part within the procedure. The major
608 reason for providing the label is to make a module name uniquely
609 identify exactly one log call. This will allow support analysts
610 or programmers who look at logs to know exactly which piece of code
611 produced your message, even without looking at the message (which
612 may be translated). So make labels for each log statement unique
613 within a routine.
614 If it is desired to group a number of log calls from different
615 routines and files into a group that can be enabled or disabled
616 atomically, this can be done with a two part label. The first part
617 would be the functional group name, and the second part would be
618 the unique code location. For instance, descriptive flexfield
619 validation code might have several log calls in different places
620 with labels desc_flex_val.check_value,
621 desc_flex_val.display_window, and desc_flex_val.parse_code. Those
622 would all be enabled by enabling module fnd.%.desc_flex_val even
623 though they all exist in different code locations.
624 Examples: begin, lookup_app_id, parse_sql_failed,
625 myfeature.done_exec
626
627 p_message This is the string that will actually be written to the log file.
628 It will be crafted by the programmer to clearly tell the reader
629 whatever information needs to be conveyed about the state of the
630 code execution.
631 if p_message is omitted the message will default to p_label
632 */
633
634 procedure log_at_unexpected_level
635 (p_product IN VARCHAR2
636 ,p_procedure_name IN VARCHAR2
637 ,p_label IN VARCHAR2
638 ,p_message IN VARCHAR2 default null);
639
640 -------------------------------- switch_logging_on -------------------------
641 /*
642 NAME
643 switch_logging_on
644 DESCRIPTION
645 Turns on AOL debug message logging at specified level when not using
646 standard applications login (eg sqlplus session). Logging is enabled
647 for a user by setting user profile options. The user and responsibility
648 can be specified with p_user_id and p_responsibility_id .If p_user_id
649 is not specified the user will default to SYSADMIN. If p_responsibility_id
650 is not specified the responsibility will default to the first
651 responsibility in the list of responsibilities for the user ordered by
652 responsibility_id.
653
654 PARAMETERS
655
656 p_logging_level: possible values: FND_LOG.LEVEL_UNEXPECTED
657 FND_LOG.LEVEL_ERROR
658 FND_LOG.LEVEL_EXCEPTION
659 FND_LOG.LEVEL_EVENT
660 FND_LOG.LEVEL_PROCEDURE
661 FND_LOG.LEVEL_STATEMENT
665 */
662 default is FND_LOG.LEVEL_STATEMENT
663 p_user_id: user id for which logging will be enabled
664 p_responsibility_id: responsibility id for which logging will be enabled
666
667 procedure switch_logging_on
668 (p_logging_level in number default fnd_log.level_statement
669 ,p_user_id in number default null
670 ,p_responsibility_id in number default null);
671
672
673 -------------------------------- switch_logging_off -------------------------
674 /*
675 NAME
676 switch_logging_off
677 DESCRIPTION
678 Turns off AOL debug messaging previously turned on by calling
679 switch_logging_on. Logging is disabled by setting user profile
680 options for the user defined in the prior call to switch_logging_on.
681 If switch_logging_on is not called before calling
682 switch_logging_off, the user is set to 'SYSADMIN'.
683
684 */
685
686 procedure switch_logging_off;
687
688 -- DK 22-MAR-1999. Added to end of the package to avoid recompilations
689 procedure set_trace_options (p_options in varchar2 ) ;
690 --
691 -------------------------------- debug_enabled -------------------------
692 /*
693 NAME
694 debug_enabled
695 DESCRIPTION
696 Returns TRUE if the logging function if either HR Trace is enabled
697 or if AOL Logging has been enabled at procedure level.
698
699 This is currently implemented as a function call. This may be changed
700 to a public variable at some point. Don't use the empty argument list
701 form eg. hr_utility.debug_enabled() when referring to this function.
702
703 This is intended to be used a performance optimization to limit the
704 number of package function calls made in code that is called _very_
705 frequently.
706
707 The typical usage will be like this :
708
709
710 package body some_package is
711
712 ...
713 ...
714 g_debug boolean := hr_utility.debug_enabled;
715
716 ...
717 ...
718
719
720 procedure public_procedure(params,..) is
721 l_proc varchar2(72) ;
722 begin
723
724 g_debug := hr_utility.debug_enabled ;
725
726 if (g_debug) then
727 l_proc := g_package||'chk_type_id';
728 hr_utility.set_location('Entering:'|| l_proc, 10);
729 end if;
730
731 ...
732 ...
733
734 if (g_debug) then
735 hr_utility.trace('xyz')
736 end if;
737
738 ...
739 ...
740
741
742 if (g_debug) then
743 fnd_log.string(parameters,...);
744 end if;
745
746 ...
747
748 end public_procedure ;
749
750
751 Note that in most cases it is sufficient to synchronize the
752 value of g_debug only in the implementations of public procedures
753 and functions.
754
755
756 PARAMETERS
757 *None*
758 */
759 --
760 function debug_enabled return boolean;
761 --
762
763 PRAGMA RESTRICT_REFERENCES(hr_utility,WNDS);
764
765 /*Function added to get the ICX Attribute values */
766 FUNCTION get_icx_val(p_attribute_name varchar2,p_session_id number)
767 RETURN VARCHAR2;
768
769 end hr_utility;
[Home] [Help]