To generate an iLDT (*.ildt) file, execute the Integration Repository Parser using the following syntax:

$IAS_ORACLE_HOME/perl/bin/perl $FND_TOP/bin/irep_parser.pl -g -v -username=<a fnd username> <product>:<relative path from product top>:<fileName>:<version>=<Complete File Path, if not in currect directory>

Examples of generating iLDT files for custom PL/SQL APIs and custom composites of BPEL type:

• $IAS_ORACLE_HOME/perl/bin/perl $FND_TOP/bin/irep_parser.pl -g -v -username=sysadmin fnd:patch/115/sql:SOATest1S.pls:12.0=SOATest1S.pls

• $IAS_ORACLE_HOME/perl/bin/perl $FND_TOP/bin/irep_parser.pl -g -v -username=sysadmin fnd:<path>:ONT_POI_R121XB7A.bpel:12.0=<Path>/ONT_POI_R121XB7A.bpel

While executing the parser, you need to pay attention to any error messages on the console. These errors would be due to incorrect annotation or some syntax errors in the annotated file. Ensure that the annotations are correct and the file has proper syntax.

If no error occurs in the annotated interface file, an iLDT (*.ildt) file would be generated. This generated iLDT file needs to be uploaded to the Integration Repository.

See: Uploading ILDT Files to Integration Repository.

Integration Repository Parser (irep_parser.pl) Usage Details

The usage for the Integration Repository Parser can be seen from the command prompt using the -manual option:

$IAS_ORACLE_HOME/perl/bin/perl $FND_TOP/bin/irep_parser.pl -manual

Name irep_parser.pl Interface Repository Annotation Processor

Synopsis irep_parser.pl [-verbose] [-logfile=file ? -append-logfile=file] [-generate] [-force] [-outdir=directory] [-java-source=version] [-cache-java=oper] [-cache-file=file] [-imports=file] [-username=username] <filespec>...

Description The irep_parser reads interface annotation documentation in program source files and validates it according to its file type.

If the -generate flag is supplied (and other conditions met), then it will generate iLDT files. For more information, see -generate option.

Any validation errors will be reported, usually along with file name and line number, like the result of grep -n.

File Types

The irep_parser can handle almost all types of application source files. While validating the annotated files against the annotation standards of the supported interface types, files that do not match will be ignored.

Here is the list of supported file types:

• .java: All Java files are completely parsed.

• .p(kh/ls): PL/SQL package specifications are processed.

  If and when a package body is detected, the parser aborts processing and the file is ignored.

• .ldt: It processes the LDT file for annotated concurrent programs. Most LDT files will fail and be ignored right away because they are not concurrent program loader files (i.e. not created with afcpprog.lct).

• .xgm: It processes the XML Gateway map file, looking for an annotated map.

• .xml: It processes the XML file, scanning for signature contents indicating various kinds of Business Service Object data since the filename pattern is generic.

• .wfx: It processes the Business Event file, looking for annotated events.

Files Specifications

Argument filespec tokens have the following formats:

• pathname: A simple pathname argument directly indicates the file to be processed. Since path information is not included, the output iLDT can not be generated. For example, only validation is supported. See -development flag (This is backward compatible with previous validation only usage.)

• product:relative_path[:name[:version]]=pathname: Specify the product and relative path from product top (and optionally file name and version) in addition to the physical location of the file to process.

  Please note that the source file information on the left-hand side of the "=" sign is imported verbatim into the output iLDT, and otherwise not examined. The pathname on the right-hand side must refer to a real file, which can be located anywhere.

  The product and relative_path correspond to file location on APPL_TOP.

Options

Options can be abbreviated by the smallest significant number of characters. Often this can be just the first character. Options cannot be combined. Here are the supported options:

• -generate: It generates iLDT (Interface Repository Seed Data) files. The file is created in either the current directory or the directory designated by -outdir.

  The generated file name is derived from the file name by replacing all periods with underscores, and then appending the suffix ".ildt".

  Note: Use of the -generate flag requires that the command line filespecs to have (at least) the source product and path. For more information, see prod:path[:name[:version]]=pathname and the -development flag.

• -force: If the -generate flag is used to request iLDT generation, and if the file is an incorrect file type for annotations or has no significant annotation contents (no annotation at all, or no @rep:scope tag in any master-level annotation), then an empty file is created anyway. If a file of the same name existed from a previous run, it is forced to be overwritten with a zero-length file.

  The net effect is that only files that had actual errors (parsing, validation, and incomplete for generation) will not be represented in the creation of (at least) in an empty iLDT file.

• -development: It is a special flag for developers to quickly verify syntax of annotations in a file. It is equivalent to using both -generate and -verbose flags with sample values of fields, such as 'product', 'relative path from product top' and 'version'. For example, -d TestFileName is equivalent to -g -v nul:relative/path/unknown:TestFileName:1.0=TestFileName.

  This allows you to generate test iLDTs using a simple list of filenames.

• -outdir=directory: It designates an alternate directory (other than the working directory) for generated output to be placed in.

• -username=username: A valid FND username (other than the default SEED username) which marks this interface as custom service.

  If tag -username is missed, it is considered as a seeded interface. A custom interface is identified on the Integration Repository user interface by the label 'Custom' and can be searched by selecting 'Custom' in the Interface Source field after clicking Show More Search Options in the Search page.

• -logfile=file: It writes all verbose tracing and validation error messages in a log file instead of printing to standard output. It is mutually exclusive with -append-logfile.

• -append-logfile=file: It is similar to -logfile, append all verbose tracing and validation error messages in a log file instead of printing to standard output. It is mutually exclusive with -logfile.

• -verbose: It provides chatty information about files processed and other internals, non-fatal warning messages, and so on. This is in addition to any error messages generated.

  It is useful for querying the parser version, if it's used without any filespec arguments.

• -java-source=version: It informs the parser what language version (via JDK version number) to support for Java parses. A minor change was introduced in 1.4 (the assert facility), and major changes were introduced in 1.5 (generics, enhanced for loop, autoboxing/unboxing, enums, varargs, static import and annotations). If it is not supplied, then 1.5 is assumed.

Return Value

The parser will return an exit value of 0 if no errors occurred during processing. Otherwise, it will return a count of the number of files that had errors.

Files with incomplete information for generation (class resolution) are considered errors only if the -generate flag is used.

Quick Validation Examples

Use the following statements in validating annotation in PL/SQL specification files during development:

• $IAS_ORACLE_HOME/perl/bin/perl $FND_TOP/bin/irep_parser.pl *s.pls

• $IAS_ORACLE_HOME/perl/bin/perl $FND_TOP/bin/irep_parser.pl -v -g itg:patch/115/sql:12.0=fndav.pls

Environment

1. Set the Oracle E-Business Suite application environment.

   From the Oracle E-Business Suite APPS_BASE, establish the run file system APPL_TOP environment by running the EBSapps.env script.

2. The following environment variables affect parser operation:

   • LIBPATH: Add the $FMW_HOME/webtier/lib to LIBPATH variable if it is not present. For example,

     export LIBPATH=$LIBPATH:$FMW_HOME/webtier/lib

   • CLASSPATH: It is used when parsing Java files. This is required to be properly set up (as if for a compile) when performing -generate with such files.

     If parser is not able to find a particular class, check for its availability in CLASSPATH.

     On a Linux machine, CLASSPATH can be set like setenv CLASSPATH classpath1:classpath2.

     For others, refer to your platform documentation on how to set classpath variable.

   • JAVA_HOME: It is used to find the Java runtime.

     If JAVA_HOME is not set, obtain the path returned by 'which java' from the APPL_TOP environment, and set JAVA_TOP to the JDK top directory. For example,

     • On AIX:

       export JAVA_HOME=$COMMON_TOP/util/jdk32

     • On Oracle Solaris:

       export JAVA_HOME=$COMMON_TOP/util/jdk

   • export PERL5LIB=$APPL_TOP_NE/perl/lib/5.10.0:$APPL_TOP_NE/perl/lib/site_perl/5.10.0:$FND_TOP/perl:$PERL5LIB

   • For HP-UX Itanium Only

     Prepend LD_LIBRARY_PATH with $FMW_HOME/webtier/lib as follows:

     export LD_LIBRARY_PATH=$FMW_HOME/webtier/lib:$LD_LIBRARY_PATH