6 Native Format Builder Wizard

This chapter describes the Native Format Builder wizard, which enables you to create native schemas used for translation. It includes use cases and constructs for the schema.

This chapter includes the following sections:

6.1 Creating Native Schema Files with the Native Format Builder Wizard

Oracle JCA Adapters are software components that enable the integration between various enterprise information systems (EIS) and the Oracle BPEL Process Manager (Oracle BPEL PM), the Oracle Mediator (Mediator), or the Oracle Service Bus (OSB). Adapters accept native messages in XML or non-XML format and publish them to Oracle BPEL PM or Mediator as XML messages. Adapters can also accept XML messages and convert them back to native EIS format. This translation from native data format to XML and back is performed using a definition file (non-XML schema definition), which itself is defined in XML schema format. The Native Format Builder wizard enables you to sample native data and create the native XSD (NXSD) grammar for translation of native data.

When you click the Define Schema for Native Format button in the Messages page of the Adapter Configuration Wizard shown in Figure 6-1, the Native Format Builder wizard is displayed. The Messages page is the last page that is displayed in the Adapter Configuration Wizard before the Finish page.

Figure 6-1 Starting the Native Format Builder Wizard

Description of Figure 6-1 follows
Description of "Figure 6-1 Starting the Native Format Builder Wizard"

6.1.1 Supported File Formats

The Native Format Builder wizard guides you through the creation of a native schema file from the following file formats shown in Figure 6-2. You must have a sample data file format for the selected type to create a native schema. You can also select the option for editing an existing native schema created with this wizard, except for those generated from a Document Type Definition (DTD) or COBOL Copybook file types. For information on editing the native schema file, see Editing Native Schema Files.

Figure 6-2 Native Format Builder Wizard

Description of Figure 6-2 follows
Description of "Figure 6-2 Native Format Builder Wizard"

6.1.1.1 Delimited

This option enables you to create native schemas for records, where the fields are separated by a value such as a comma or number sign (#).

6.1.1.2 Fixed Length (Positional)

This option enables you to create native schemas for records, where all fields are of fixed lengths.

6.1.1.3 Complex Type

This option enables you to create native schema for records, where the fields may themselves be records having multiple delimiter types.

6.1.1.4 DTD

This option enables you to generate native schema from the user-supplied DTD, which contains information about the structure of an XML document.

6.1.1.5 COBOL Copybook

This option enables you to generate native schema from the user-supplied COBOL Copybook definition.

A COBOL mainframe application typically uses a COBOL Copybook file to define its data layout. The converter creates a native schema from a COBOL Copybook so that the runtime translator can parse the associated data file.

A COBOL Copybook is typically a collection of group items (structures). These group items contain other items, which can be groups or elementary items. Elementary items are items that cannot be further subdivided. For example:

01 Purchase-Order
        05 Buyer
                 10 BuyerName PIC X(5) USAGE DISPLAY.
        04 Seller
                 08 SellerName PICTURE XXXXX.

Purchase-order is a group item with two child group items (Buyer, Seller). The numbers 01, 05, 04, and so on indicate the level of the group (that is, the hierarchy of data within that group).

Groups can be defined that have different level-numbers for the same level in the hierarchy. For example, Buyer and Seller have different level numbers, but are at the same level in the hierarchy. A group item includes all group and elementary items that follow it until a level number less than or equal to the level number of that group is encountered.

Each of the group items (Buyer and Seller) has a child elementary item. The PIC or PICTURE clause defines the data layout. For example, BuyerName defines an alphanumeric type of size equal to five characters. SellerName has the same data layout as BuyerName.

Group items in COBOL can be mapped to elements in XML schema with the complexType type. Similarly, elementary items can be mapped to elements of type simple type with certain native format annotations to help the runtime translator parse the corresponding data file. For example, the Buyer item can be mapped to the following definition:

<!--COBOL declaration : 05 Buyer-->
<element name="Buyer">
   <complexType>
      <sequence>
         <!--COBOL declaration : 10 Name PIC X(5)-->
         <element name="Name" type="string" nxsd:style="fixedLength"
            nxsd:padStyle="tail" nxsd:paddedBy=" " nxsd:length="5"/>
         </sequence>
   </complexType>
</element>
6.1.1.5.1 User Inputs

You are expected to provide the following information:

  • Target namespace for the native schema to be generated

  • Character set of the host computer on which the data file was generated. By default, this is set to EBCDIC (ebcdic-cp-us).

  • Byte order of the host computer on which the data file was generated. By default, this is set to big-endian.

  • Record delimiter, which is typically the new line character, or no delimiter, or any user-supplied string.

  • Container tag name for generated native schema. By default, this is set to Root-Element.

6.1.1.5.2 COBOL Clauses

Table 6-1 describes COBOL clauses. The numeric types covered in Table 6-1 are stored as one character per digit. Support for clauses is defined as follows:

  • Y indicates that the clause is supported.

  • N indicates that the clause is not supported.

  • I indicates that the clause is ignored.

Table 6-1 COBOL Clauses (Numeric Types Stored as One Character Per Digit)

COBOL Clause Design-Time Support Runtime Support Supported Synonyms Comments

PIC X(n)

Y

Y

XXX…

Alphanumeric – An allowable character from the character set of the computer. Each X corresponds to one byte.

PIC A(n)

Y

Y

AA…

Alphabetic – Any letter of the alphabet or space. Each A corresponds to one byte.

PIC 9(n) DISPLAY

Y

Y

9999…

Any character position that contains a numeral. Each nine is counted in the size of the item.

OCCURS n TIMES

Y

Y

  

Fixed-length array

JUSTIFIED

Y

Y

  

For A and X types. Right justifies with the space pad. Data is aligned at the right-most character position.

REDEFINES

Y

Y

  

Allows the same computer memory area to be described by different data items.

PIC 9(m)V9(n) DISPLAY

Y

Y

  

Size = n+m bytes

OCCURS DEPENDING ON

Y

Y

  

NA

BLANK WHEN ZERO

I

I

  

Ignored

RENAMES

N

N

  

This is rarely seen in COBOL Copybooks

INDEX

N

N

  

Four-byte index

SYNCHRONIZED

I

I

SYNC

NA

POINTER

N

N

  

NA

PROCEDURE-POINTER

      

NA

FILLER

Y

Y

  

NA

The numeric types described in Table 6-1 are stored as one character per digit. Table 6-2 describes the numeric types that are stored in a more efficient manner.

Table 6-2 COBOL Clauses (Numeric Types Stored More Efficiently)

COBOL Clause Design-Time Support Runtime Support Supported Synonyms Comments

USAGE [IS]

Y

Y

  

Both these keywords are optional.

PIC 9(n) COMP

Y

Y

COMPUTATIONAL, BINARY, COMP-4

Length varies with n:

  • n = 1-4 (2 bytes)

  • n = 5-9 (4 bytes)

  • n = 10-18 (8 bytes)

COMP-1

Y

Y

COMPUTATIONAL-1

Single precision, floating point number that is four bytes long.

COMP-2

Y

Y

COMPUTATIONAL-2

Double precision, floating point number that is eight bytes long.

PIC 9(n) COMP-3

Y

Y

PACKED-DECIMAL, COMPUTATIONAL-3

Two digits are stored in each byte. An additional half byte at the end is allocated for the sign, even if the value is unsigned.

PIC 9(n) COMP-4

Y

Y

COMPUTATIONAL-4

Treated the same as a COMP type and given its own data type for customizing requirements.

PIC 9(n) COMP-5

N

N

  

Capacity of the native binary representation.

PIC S9(n) DISPLAY

Y

Y

PIC S99…

Sign nibble in the right-most zone by default. S is not counted in the size.

PIC S9(n) COMP

Y

Y

  

Same as COMP. Negative numbers are represented as two's complement.

PIC S9(n) COMP-3

Y

Y

  

NA

PIC 9(m)V9(n) COMP

Y

Y

  

Length is the same as COMP.

PIC 9(m)V9(m) COMP-3

Y

Y

  

Length = Ceiling ((n+m+1)/2)

The following clauses can be added to impact the sign position.

  • SIGN IS LEADING

    Used with signed zoned numerics.

  • SIGN IS TRAILING

    Used with signed zoned numerics.

  • SIGN IS LEADING SEPARATE

    The character S is counted in the size.

  • SIGN IS TRAILING SEPARATE

    The character S is counted in the size.

Note:

These assume that the numerics are stored using IBM COBOL format. If these are generated for other platforms with different data storage formats, then a custom data handler for that type must be written.

6.1.1.5.3 Picture Editing Types

Table 6-3 describes picture editing types.

Table 6-3 Edited Pictures

Edited Pictures Supported Editing Types Unsupported Editing Types

Edited alphanumeric

Simple Insertion: B(blank) 0 / ,

  

Edited float numeric

Special insertion: . (period)

  

Edited numeric

  • Simple Insertion: B(blank) 0 / ,

  • Special insertion: . (period)

  • Fixed Insertion: cs + - CR DB (Inserts a symbol at the beginning or end)

  • Floating Insertion: cs + -

  • Zero suppression: Z *

  • Replacement insertion: Z * + - c

Edited pictures are more for presentation purposes and are rarely seen in data files. It is assumed that the editing symbols are also present in the data. For example, if you have:

05   AMOUNT     PIC 999.99

then, this field is six bytes wide and has a decimal point in the data.

Simple, special, and fixed insertions are handled by this method. Floating insertion, zero suppression, and replacement insertion are not supported.

6.1.1.6 MFL to be Converted into XSD

Enables you to convert an MFL file into XSD format. For more information, see Converting an MFL Format File to Schema Format.

6.1.1.7 JSON Interchange Format

Generates an NXSD schema from a JSON sample file or JSON file at a specified location. JSON is a text-based, open standard for human-readable data interchange. JSON comes from the JavaScript scripting language for representing simple data structures and associative arrays, called objects.

If you select this option, The Native Format Builder Wizard displays the JSON File Description screen. Here you can enter:

  • File Name—The name of the JSON file.

  • Target Namespace—Displays the target Namespace.

  • Root Element—Specifies the JSON root level.

  • Character Set —Select the character set to use.

For more information on using JSON, see “Integrating REST Operations in SOA Composite Applications”Developing SOA Applications with Oracle SOA Suite.

6.1.2 Editing Native Schema Files

You can edit an existing native schema generated using the Native Format Builder wizard by sampling a delimited, fixed length, or complex type file. To edit an existing native schema select the Edit existing option in the Choose Type page of the Native Format Builder wizard, and click Browse to navigate to the location of the existing schema file and then select the native schema file that must be edited. The Native Format Builder wizard guides you through the editing of the native schema file.

Note:

You cannot edit native schemas generated from a Document Type Definition (DTD) or COBOL Copybook file types.

Figure 6-3 shows the Native Format Builder - Choose Type page with the Edit existing option selected.

Figure 6-3 The Native Format Builder Wizard - Choose Type Page

Description of Figure 6-3 follows
Description of "Figure 6-3 The Native Format Builder Wizard - Choose Type Page"

Before you edit a native schema file, you must ensure that the sample file specified in the annotation within the schema exists. This annotation is automatically added when the native schema is generated the first time from the sample file.

The example below shows the annotation that is generated:

Example - Generated Annotation

 <xsd:annotation>
      <xsd:appinfo>NXSDSAMPLE=/scratch/bob/sample.txt</xsd:appinfo>
      <xsd:appinfo>USEHEADER=true</xsd:appinfo>
 </xsd:annotation>

For example, if the specified sample file path in the annotation is <!--NXSDWIZ:C:\Temp\Book1Out.csv:--> and if the file is not located at the path specified, then the wizard displays an error.

6.2 Native Schema Constructs

This section provides an overview of the various constructs of native schema used to translate the native format data to XML and also explains the usage of these native schema constructs.

This section includes the following topics:

6.2.1 Understanding Native Schema Constructs

Table 6-4 shows the constructs applicable only on the <schema> tag.

Table 6-4 Constructs Applicable Only on the <schema> Tag

Construct Description

byteOrder

The byte order of the native data as bigEndian or littleEndian.

encoding

The encoding in which the actual data is stored. UTF-8 is typically recommended for interoperability and Unicode support. You can specify any legal encoding supported by the Java runtime environment. For a complete listing of supported encodings, visit http://download.oracle.com/javase/6/docs/technotes/guides/intl/encoding.doc.html. You can specify the encoding in the (N)XSD associated with the adapter proxy meta data. For example, nxsd:encoding="iso-8859-1

nxsd:alwaysQuote

Set to true if quotes must be forced around native non-xml data in the outbound.

headerLines

A positive integer specifying the number of lines to be skipped, before translating the native data.

headerLinesTerminatedBy

Skip until the specified string, before translating the native data.

standalone

If declared, adds the standalone attribute in the XML declaration prolog of the translated XML, with the actual value as that specified in nxsd:standalone. Allowed values are true and false.

stream

Whether the data is stored as characters or bytes. Allowed values are CHARS and BYTES.

uniqueMessageSeparator

String specifying the unique message separator in the native data, in a batch of messages.

version

The type of native data. Possible values are NXSD, DTD, XSD, and OPAQUE.

xmlversion

If declared, adds the XML declaration prolog to the translated XML with the actual value as that specified in nxsd:xmlversion. Allowed values are 1.0 and 1.1.

outboundHeader

String specifying the header value to be inserted in the outbound message.

dataLines

Integer specifying the number of lines to process in the native file.

fieldValidation

If set to true, then translator performs data type validation on the tokens read from the native.

The fieldValidation construct is supported for built in simple types only.

validation

If set to true, then the translator performs result validation both on the inbound and outbound.

validateNxsd

If set to true, then a thorough native grammar validation is performed. This construct is switched off by default and must be switched off in production for better performance.

useArrayIdentifiers

If set to true, then it optimizes the native framework for handling array identifiers. This may result in a performance hit for very large payloads. By default, arrayIdentifiers are not supported.

parseBom

If set to true, then the byte order mark is looked for in the native stream and encoding is derived from this.

encodeLineTerminators

If set to true, then the semantic interpretation of ${eol} is \r\n instead of \n.

Table 6-5 shows the constructs applicable on all tags other than the <schema> tag.

Table 6-5 Constructs Applicable On All Tags Other Than the <schema> Tag

Construct Description

arrayIdentifierLength

The length of the array being stored in the native data occupying the specified length

arrayLength

The value of this construct is used as the length of the array, which can also be a variable resolved to a valid number. This value overrides any minOccurs and maxOccurs attributes of the particle where it is specified. Use this feature as follows:

nxsd:style="array" nxsd:arrayLength="10"

This indicates that the array length is 10.

arrayTerminatedBy

The last item in the array being terminated by the specified string

assign

Assigns a value to the variable that is declared

cellSeparatedBy

The cells of the array in the native data being separated by the specified string

choiceCondition

Either fixedLength or terminated

conditionValue

Matches the string read from the native stream for the choiceCondition construct, against the specified string in the conditionValue construct

dataLines

The value specified in this construct is used to translate only a portion of the data and not the entire data.

dateFormat

A valid Java date format representing the date in the native data

identifierLength

The number of characters and bytes in which the actual length of the data is stored

itemSeparatedBy

The items in the list being separated by the specified string

leftSurroundedBy,

rightSurroundedBy

The native data surrounded

length

The length of the native data to be read. Used with fixed-length style.

listTerminatedBy

The last item in the list being terminated by the specified string

lookAhead

Looks for a match ahead of the current position in the input stream. If a match is found, then the node on which this construct is specified is processed; otherwise, it is skipped. Use this feature as follows:

nxsd:lookAhead="20" nxsd:lookFor="abc"

This indicates to skip 20 characters and look for the string abc starting from that location. If this is found, then the node is processed; otherwise, it is skipped.

paddedBy

The string used for padding

padStyle

head, tail, or none

quotedBy

The native data being quoted by the specified string.

By default, the specified string is &quot; ("). If your data includes this character, you must override this default even if the field is not quoted. For more information, see Native Data Format to Be Translated: Data Includes Default Quote Character under Defining Terminated Data.

skip

Skips the specified number of bytes or characters

skipLines

Skips the number of lines specified

skipUntil

Skips until the string specified

startsWith

Looks for the specified string in the native data. If it exists, then proceeds with the element where it is specified; otherwise, skips and processes the next element.

style

The style used to read the native data from the input stream. Allowed values are fixedLength, surrounded, terminated, list, and array.

surroundedBy

The native data being surrounded by the specified string.

terminatedBy

The native data being terminated by the string specified.

variable

Declares a single variable.

variables

Declares a set of variables or assigns the declared variables a value.

6.2.2 Using Native Schema Constructs

This section includes the following topics:

6.2.2.1 Defining Fixed-Length Data

Fixed-length data in the native format can be defined in the native schema by using the fixed-length style. There are three types of fixed length:

  • With padding

  • Without padding

  • With the actual length also being read from the native data

Native Data Format to be Translated: With Padding

The actual data may be less than the length specified. In this case, you can specify paddedBy and padStyle as head or tail. When the data is read, the pads are trimmed accordingly. The following is a sample native data to be translated:

GBP*UK000012550.00

Native Schema: With Padding

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://www.oracle.com/ias/processconnect/"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">
 
<element name="fixedlength">
  <complexType>
    <sequence>
      <element name="currency_code" nxsd:style="fixedLength" nxsd:length="4"
         nxsd:padStyle="tail" nxsd:paddedBy="*">
        <simpleType>
          <restriction base="string">
            <maxLength value="4" />
          </restriction>
        </simpleType>
      </element>
      <element name="country_code" nxsd:style="fixedLength" nxsd:length="2"
         nxsd:padStyle="none">
        <simpleType>
          <restriction base="string">
            <length value="2" />
          </restriction>
        </simpleType>
      </element>
      <element name="to_usd_rate" nxsd:style="fixedLength" nxsd:length="12"
         nxsd:padStyle="head" nxsd:paddedBy="0">
        <simpleType>
          <restriction base="string">
            <maxLength value="12" />
          </restriction>
        </simpleType>
      </element>
    </sequence>
  </complexType>
</element>
 
</schema>

Translated XML Using the Native Schema: With Padding

<fixedlength xmlns="http://www.oracle.com/ias/processconnect/">
   <currency_code>GBP</currency_code>
   <country_code>UK</country_code>
   <to_usd_rate>12550.00</to_usd_rate>
</fixedlength>

Native Data Format to be Translated: Without Padding

To define a fixed-length data in native schema, you can use the fixed-length style. In case the actual data is less than the length specified, the white spaces are not trimmed. The following is a sample native data to be translated:

GBP*UK000012550.00

Native Schema: Without Padding

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://www.oracle.com/ias/processconnect/"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">
 
<element name="fixedlength">
  <complexType>
    <sequence>
      <element name="currency_code" nxsd:style="fixedLength" nxsd:length="4">
        <simpleType>
          <restriction base="string">
            <maxLength value="4" />
          </restriction>
        </simpleType>
      </element>
      <element name="country_code" nxsd:style="fixedLength" nxsd:length="2">
        <simpleType>
          <restriction base="string">
            <length value="2" />
          </restriction>
        </simpleType>
      </element>
      <element name="to_usd_rate" nxsd:style="fixedLength" nxsd:length="12">
        <simpleType>
          <restriction base="string">
            <maxLength value="12" />
          </restriction>
        </simpleType>
      </element>
    </sequence>
  </complexType>
</element>
 
</schema>

Translated XML Using the Native Schema: Without Padding

<fixedlength xmlns="http://www.oracle.com/ias/processconnect/">
   <currency_code>GBP*</currency_code>
   <country_code>UK</country_code>
   <to_usd_rate>000012550.00</to_usd_rate>
</fixedlength>

Native Data Format to be Translated: Actual Length Also Being Read from the Native Data

When the length of the data is also stored in the native stream, this style is used to first read the length, and subsequently read the data according to the length read. The following is a sample native data to be translated:

03joe13DUZac.1HKVmIY

Native Schema: Actual Length Also Being Read from the Native Data

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://www.oracle.com/ias/processconnect/"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">
 
<element name="fixedlength">
  <complexType>
    <sequence>
      <element name="user" type="string" nxsd:style="fixedLength"
         nxsd:identifierLength="2" />
      <element name="encr_user" type="string" nxsd:style="fixedLength"
         nxsd:identifierLength="2" />
    </sequence>
  </complexType>
</element>
 
</schema>

Translated XML Using the Native Schema: Actual Length also Being Read from the Native Data

<fixedlength xmlns="http://www.oracle.com/ias/processconnect/">
   <user>joe</user>
   <encr_user>DUZac.1HKVmIY</encr_user>
</fixedlength>

6.2.2.2 Defining Terminated Data

This format is used when the terminating mark itself is supposed to be treated as part of the actual data and not as a delimiter. When it is not clear whether the mark is part of actual data or not, you can use nxsd:quotedBy to be safe. Specifying nxsd:quotedBy means that the corresponding native data may or may not be quoted. If it is quoted, then the actual data is read from the begin quotation to the end quotation as specified in nxsd:quotedBy. Otherwise, it is read until the terminatedBy character is found.

By default, the terminating mark is &quot; ("). If your data includes this character, you must override this default even if the field is not quoted. For more information, see Native Data Format to be Translated: Data Includes Default Quote Character below.

Examples for the Optionally quoted, Not quoted, and Includes default quote character scenarios are provided in the following sections:

Native Data Format to be Translated: Optionally Quoted

The following is a sample native data to be translated:

Fred,"2 Old Street, Old Town,Manchester",20-08-1954,0161-499-1718

Native Schema: Optionally Quoted

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://www.oracle.com/ias/processconnect/"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">
 
<element name="terminated">
  <complexType>
    <sequence>
      <element name="PersonName" type="string" nxsd:style="terminated"
         nxsd:terminatedBy="," />
      <element name="Address" type="string" nxsd:style="terminated"
         nxsd:terminatedBy="," nxsd:quotedBy="&quot;"/>
      <element name="DOB" type="string" nxsd:style="terminated"
         nxsd:terminatedBy="," />
      <element name="Telephone" type="string" nxsd:style="terminated"
        nxsd:terminatedBy="${eol}" />
    </sequence>
  </complexType>
</element>

Translated XML Using the Native Schema: Optionally Quoted

<terminated xmlns="http://www.oracle.com/ias/processconnect/">
   <PersonName>Fred</PersonName>
   <Address>2 Old Street, Old Town,Manchester</Address>
   <DOB>20-08-1954</DOB>
   <Telephone>0161-499-1718</Telephone>
</terminated>

Native Data Format to be Translated: Not Quoted

This is used when the data is terminated by a particular string or character. The following is a sample native data to be translated:

1020,16,18,,1580.00

Native Schema: Not Quoted

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://www.oracle.com/ias/processconnect/"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">
 
<element name="terminated">
  <complexType>
    <sequence>
      <element name="product" type="string" nxsd:style="terminated"
         nxsd:terminatedBy="," />
      <element name="ordered" type="string" nxsd:style="terminated"
         nxsd:terminatedBy="," />
      <element name="inventory" type="string" nxsd:style="terminated"
        nxsd:terminatedBy="," />
      <element name="backlog" type="string" nxsd:style="terminated"
        nxsd:terminatedBy="," />
      <element name="listprice" type="string" nxsd:style="terminated"
        nxsd:terminatedBy="${eol}" />
    </sequence>
  </complexType>
</element>
 
</schema>

Translated XML Using the Native Schema: Not Quoted

<terminated xmlns="http://www.oracle.com/ias/processconnect/">
   <product>1020</product>
   <ordered>16</ordered>
   <inventory>18</inventory>
   <backlog></backlog>
   <listprice>1580.00</listprice>
</terminated>

Native Data Format to be Translated: Data Includes Default Quote Character

The following is a sample native data to be translated:

aaa,"bbbbb,[cccc

In this case, fields are terminated by commas, the " character is part of the data in the second field, and the [ character is part of the data in the third field.

Because the default nxsd:quotedBy terminating mark is &quot; ("), the Oracle File Adapter fails to translate field two even if you specify that this field is terminated by a comma character. To successfully translate this data, you must override the default nxsd:quotedBy terminating mark to any character that is not be part of the data for this field. In this example, you override the default nxsd:quotedBy terminating mark to &lt; (<) because this character never appears in field two:

<element name="FieldTwo" type="string" nxsd:style="terminated" nxsd:terminatedBy="," nxsd:quotedBy="&lt;"/>

By contrast, for field three, you must only specify nxsd:terminatedBy="," because the [ character does not conflict with the default nxsd:quotedBy terminating mark:

<element name="FieldThree" type="string" nxsd:style="terminated" nxsd:terminatedBy="," />

Native Schema: Data Includes Default Quote Character

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://www.oracle.com/ias/processconnect/"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">
 
<element name="terminated">
  <complexType>
    <sequence>
      <element name="FieldOne" type="string" nxsd:style="terminated"
         nxsd:terminatedBy="," />
      <element name="FieldTwo" type="string" nxsd:style="terminated"
         nxsd:terminatedBy="," nxsd:quotedBy="&lt;"/>
      <element name="FieldThree" type="string" nxsd:style="terminated"
         nxsd:terminatedBy="," />
    </sequence>
  </complexType>
</element>

Translated XML Using the Native Schema: Data Includes Default Quote Character

<terminated xmlns="http://www.oracle.com/ias/processconnect/">
   <FieldOne>aaa</FieldOne>
   <FieldTwo>"bbbbb</FieldTwo>
   <FieldThree>[cccc</FieldThree>
</terminated>

6.2.2.3 Defining Surrounded Data

This is used when the native data is surrounded by a mark.

The following are types of surrounded data:

  • Left and right surrounding marks are different.

  • Left and right surrounding marks are the same.

Native Data Format to be Translated: Left and Right Surrounding Marks are Different

The following is a sample native data to be translated for which the left and the right surrounding marks are different:

(Ernest Hemingway Museum){Whitehead St.}

Native Schema: Left and Right Surrounding Marks are Different

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        xmlns:tns="http://www.oracle.com/ias/processconnect/"
        targetNamespace="http://www.oracle.com/ias/processconnect/"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">
<element name="limstring">
  <complexType>
    <sequence>
      <element name="Landmark" type="string" nxsd:style="surrounded" nxsd:leftSurroundedBy="(" nxsd:rightSurroundedBy=")" />
      <element name="Street" type="string" nxsd:style="surrounded" nxsd:leftSurroundedBy="{" nxsd:rightSurroundedBy="}" />
    </sequence>
  </complexType>
</element>
</schema>

Translated XML Using the Native Schema: Left and Right Surrounding Marks are Different

<limstring xmlns="http://www.oracle.com/ias/processconnect/">
   <Landmark>Ernest Hemingway Museum</Landmark>
   <Street>Whitehead St.</Street>
</limstring>

Native Data Format to be Translated: Left and Right Surrounding Marks are the Same

The following is a sample native data to be translated for which the left and the right surrounding marks are the same:

.FL..Florida Keys.+Key West+

Native Schema: Left and Right Surrounding Marks are the Same

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        xmlns:tns="http://www.oracle.com/ias/processconnect/"
        targetNamespace="http://www.oracle.com/ias/processconnect/"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">
<element name="limstring">
  <complexType>
    <sequence>
      <element name="State" type="string" nxsd:style="surrounded" nxsd:surroundedBy="."/>
      <element name="Region" type="string" nxsd:style="surrounded" nxsd:surroundedBy="." />
      <element name="City" type="string" nxsd:style="surrounded" nxsd:surroundedBy="+" />
    </sequence>
  </complexType>
</element>
</schema>

Translated XML Using the Native Schema: Left and Right Surrounding Marks are the Same

<limstring xmlns="http://www.oracle.com/ias/processconnect/">
   <State>FL</State>
   <Region>Florida Keys</Region>
   <City>Key West</City>
</limstring>

6.2.2.4 Defining Lists

6.2.2.4.1 All Items Separated by the Same Mark, but the Last Item Terminated by a Different Mark (Bounded)

The following sections explain the format of the data to be translated, the native schema, and the translated XML.

Native Data Format to be Translated

125,200,255

Native Schema

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        xmlns:tns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
        targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">
 
 
<element name="list" type="tns:Colors" />

 
<complexType name="Colors" nxsd:style="list" nxsd:itemSeparatedBy=","
   nxsd:listTerminatedBy="${eol}">

  <sequence>
    <element name="Red" type="string" />
    <element name="Green" type="string" />
    <element name="Blue" type="string" />
  </sequence>
</complexType>
 
</schema>

Translated XML Using the Native Schema

<list xmlns="http://www.oracle.com/ias/processconnect/">
   <Red>125</Red>
   <Green>200</Green>
   <Blue>255</Blue>
</list>
6.2.2.4.2 All Items Separated by the Same Mark, Including the Last Item (Unbounded)

The following sections explain the format of the data to be translated, the native schema, and the translated XML.

Native Data Format to be Translated

configure;startup;runtest;shutdown;

Native Schema:

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        xmlns:tns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
        targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">
 
<element name="list" type="tns:CommandSet" />
 
<complexType name="CommandSet" nxsd:style="list" nxsd:itemSeparatedBy=";">
  <sequence>
    <element name="Cmd1" type="string" />
    <element name="Cmd2" type="string" />
    <element name="Cmd3" type="string" />
    <element name="Cmd4" type="string" />
  </sequence>
</complexType>
 
</schema>

Translated XML Using the Native Schema

<list xmlns="http://www.oracle.com/ias/processconnect/">
   <Cmd1>configure</Cmd1>
   <Cmd2>startup</Cmd2>
   <Cmd3>runtest</Cmd3>
   <Cmd4>shutdown</Cmd4>
</list>

6.2.2.5 Defining Arrays

This is for an array of complex types where the individual cells are separated by a separating character and the last cell of the array is terminated by a terminating character.

The following are examples of array types:

6.2.2.5.1 All Cells Separated by the Same Mark, but the Last Cell Terminated by a Different Mark (Bounded)

The following sections explain the format of the data to be translated, the native schema, and the translated XML.

Native Data Format to be Translated

"Smith, John","1 Old Street, Old Town, Manchester",,"0161-499-1717".
Fred,"2 Old Street, Old Town,Manchester","20-08-1954","0161-499-1718".
"Smith, Bob",,,0161-499-1719.#

Native Schema:

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://www.oracle.com/ias/processconnect/"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD"
>
<element name="array">
  <complexType>
    <sequence>
      <element name="Member" maxOccurs="unbounded" 
               nxsd:style="array" nxsd:cellSeparatedBy="${eol}"
 nxsd:arrayTerminatedBy="#">
        <complexType>
          <sequence>
            <element name="Name" type="string" nxsd:style="terminated"
 nxsd:terminatedBy="," nxsd:quotedBy='"'/>
            <element name="Address" type="string" nxsd:style="terminated"
 nxsd:terminatedBy="," nxsd:quotedBy='"'/>
            <element name="DOB" type="string" nxsd:style="terminated"
 nxsd:terminatedBy="," nxsd:quotedBy='"'/>
            <element name="Telephone" type="string" nxsd:style="terminated"
 nxsd:terminatedBy="." nxsd:quotedBy='"'/>
          </sequence>
        </complexType>
      </element>
    </sequence>
  </complexType>
</element>
 
</schema>

Translated XML Using the Native Schema

<array xmlns="http://www.oracle.com/ias/processconnect/">
   <Member>
      <Name>Smith, John</Name>
      <Address>1 Old Street, Old Town, Manchester</Address>
      <DOB></DOB>
      <Telephone>0161-499-1717</Telephone>
   </Member>
   <Member>
      <Name>Fred</Name>
      <Address>2 Old Street, Old Town,Manchester</Address>
      <DOB>20-08-1954</DOB>
      <Telephone>0161-499-1718</Telephone>
   </Member>
   <Member>
      <Name>Smith, Bob</Name>
      <Address></Address>
      <DOB></DOB>
      <Telephone>0161-499-1719</Telephone>
   </Member>
</array>
6.2.2.5.2 All Cells Separated by the Same Mark, Including the Last Cell (Unbounded)

The following sections explain the format of the data to be translated, the native schema, and the translated XML.

Native Data Format to be Translated

"Smith, John","1 Old Street, Old Town, Manchester",,"0161-499-1717".
Fred,"2 Old Street, Old Town,Manchester","20-08-1954","0161-499-1718".
"Smith, Bob",,,0161-499-1719.

Native Schema:

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://www.oracle.com/ias/processconnect/"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">
 
<element name="array">
  <complexType>
    <sequence>
      <element name="Member" maxOccurs="unbounded" 
               nxsd:style="array" nxsd:cellSeparatedBy="\r\n">
        <complexType>
          <sequence>
            <element name="Name" type="string" nxsd:style="terminated"
               nxsd:terminatedBy="," nxsd:quotedBy='"'/>
            <element name="Address" type="string" nxsd:style="terminated"
               nxsd:terminatedBy="," nxsd:quotedBy='"'/>
            <element name="DOB" type="string" nxsd:style="terminated"
               nxsd:terminatedBy="," nxsd:quotedBy='"'/>
            <element name="Telephone" type="string" nxsd:style="terminated"
               nxsd:terminatedBy="." nxsd:quotedBy='"'/>
          </sequence>
        </complexType>
      </element>
    </sequence>
  </complexType>
</element>
 

</schema>

Translated XML Using the Native Schema

<array xmlns="http://www.oracle.com/ias/processconnect/">
   <Member>
      <Name>Smith, John</Name>
      <Address>1 Old Street, Old Town, Manchester</Address>
      <DOB></DOB>
      <Telephone>0161-499-1717</Telephone>
   </Member>
   <Member>
      <Name>Fred</Name>
      <Address>2 Old Street, Old Town,Manchester</Address>
      <DOB>20-08-1954</DOB>
      <Telephone>0161-499-1718</Telephone>
   </Member>
   <Member>
      <Name>Smith, Bob</Name>
      <Address></Address>
      <DOB></DOB>
      <Telephone>0161-499-1719</Telephone>
   </Member>
</array>
6.2.2.5.3 Cells Not Separated by Any Mark, but the Last Cell Terminated by a Mark (Bounded)

The following sections explain the format of the data to be translated, the native schema, and the translated XML.

Native Data Format to be Translated

"Smith, John","1 Old Street, Old Town, Manchester",,"0161-499-1717"
Fred,"2 Old Street, Old Town,Manchester","20-08-1954","0161-499-1718"
"Smith, Bob",,,0161-499-1719
#

Native Schema

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://www.oracle.com/ias/processconnect/"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">
 
<element name="array">
  <complexType>
    <sequence>
      <element name="Member" maxOccurs="unbounded" 
               nxsd:style="array" nxsd:arrayTerminatedBy="#">
        <complexType>
          <sequence>
            <element name="Name" type="string" nxsd:style="terminated"
                nxsd:terminatedBy="," nxsd:quotedBy='"'/>
            <element name="Address" type="string" nxsd:style="terminated"
                nxsd:terminatedBy="," nxsd:quotedBy='"'/>
            <element name="DOB" type="string" nxsd:style="terminated"
                nxsd:terminatedBy="," nxsd:quotedBy='"'/>
            <element name="Telephone" type="string" nxsd:style="terminated"
                nxsd:terminatedBy="\r\n" nxsd:quotedBy='"'/>          </sequence>
        </complexType>
      </element>
    </sequence>
  </complexType>
</element>
 
</schema>

Translated XML Using the Native Schema

<array xmlns="http://www.oracle.com/ias/processconnect/">
   <Member>
      <Name>Smith, John</Name>
      <Address>1 Old Street, Old Town, Manchester</Address>
      <DOB></DOB>
      <Telephone>0161-499-1717</Telephone>
   </Member>
   <Member>
      <Name>Fred</Name>
      <Address>2 Old Street, Old Town,Manchester</Address>
      <DOB>20-08-1954</DOB>
      <Telephone>0161-499-1718</Telephone>
   </Member>
   <Member>
      <Name>Smith, Bob</Name>
      <Address></Address>
      <DOB></DOB>
      <Telephone>0161-499-1719</Telephone>
   </Member>
</array>
6.2.2.5.4 The Number of Cells Being Read from the Native Data

The following sections explain the format of the data to be translated, the native schema, and the translated XML.

Native Data Format to be Translated

3"Smith, John","1 Old Street, Old Town, Manchester",,"0161-499-1717"
Fred,"2 Old Street, Old Town,Manchester","20-08-1954","0161-499-1718"
"Smith, Bob",,,0161-499-1719

Native Schema:

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://www.oracle.com/ias/processconnect/"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">

<element name="arrayidentifierlength">
  <complexType>
    <sequence>
      <element name="Member" maxOccurs="unbounded" nxsd:style="array"
          nxsd:arrayIdentifierLength="1">
        <complexType>
          <sequence>
            <element name="Name" type="string" nxsd:style="terminated"
               nxsd:terminatedBy="," nxsd:quotedBy='"'/>
            <element name="Address" type="string" nxsd:style="terminated"
               nxsd:terminatedBy="," nxsd:quotedBy='"'/>
            <element name="DOB" type="string" nxsd:style="terminated"
               nxsd:terminatedBy="," nxsd:quotedBy='"'/>
            <element name="Telephone" type="string" nxsd:style="terminated"
               nxsd:terminatedBy="\r\n" nxsd:quotedBy='"'/>
          </sequence>
        </complexType>
      </element>
    </sequence>
  </complexType>
</element>
 
</schema>

Translated XML Using the Native Schema

<arrayidentifierlength xmlns="http://www.oracle.com/ias/processconnect/">
   <Member>
      <Name>Smith, John</Name>
      <Address>1 Old Street, Old Town, Manchester</Address>
      <DOB></DOB>
      <Telephone>0161-499-1717</Telephone>
   </Member>
   <Member>
      <Name>Fred</Name>
      <Address>2 Old Street, Old Town,Manchester</Address>
      <DOB>20-08-1954</DOB>
      <Telephone>0161-499-1718</Telephone>
   </Member>
   <Member>
      <Name>Smith, Bob</Name>
      <Address></Address>
      <DOB></DOB>
      <Telephone>0161-499-1719</Telephone>
   </Member>
</arrayidentifierlength>
6.2.2.5.5 Explicit Array Length

The following sections explain the format of the data to be translated, the native schema, and the translated XML.

Native Data Format to be Translated

3;John;Steve;Paul;Todd;

Native Schema

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">

<element name="array">
  <annotation>
    <appinfo>
      <nxsd:variables>
        <nxsd:variable name="len" />
      </nxsd:variables>
    </appinfo>
  </annotation>

  <complexType>
    <sequence>
      <element name="TotalMembers" type="string" nxsd:style="terminated"
nxsd:terminatedBy=";">
        <annotation>
          <appinfo>
            <nxsd:variables>
              <nxsd:assign name="len" value="${0}" />
            </nxsd:variables>
          </appinfo>
        </annotation>
      </element>
      <element name="Member" type="string" minOccurs="0" maxOccurs="unbounded" 
              nxsd:style="array,terminated" nxsd:arrayLength="${len}"
nxsd:terminatedBy=";" />
    </sequence>
  </complexType>
</element>

</schema>

Translated XML Using the Native Schema

<array xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
   <TotalMembers>3</TotalMembers>
   <Member>John</Member>
   <Member>Steve</Member>
   <Member>Paul</Member>
</array>

6.2.2.6 Conditional Processing

6.2.2.6.1 Processing One Element Within a Choice Model Group Based on the Condition

The following sections explain the format of the data to be translated, the native schema, and the translated XML.

Native Data Format to be Translated

PO28/06/2004^|ABCD Inc.|Oracle
OracleApps025070,000.00
Database  021230,000.00
ProcessCon021040,000.00
PO01/07/2004^|EFGH Inc.|Oracle
DB2       021230,000.00
Eclipse   021040,000.00
SO29/06/2004|Oracle Apps|5
Navneet Singh
PO28/06/2004^|IJKL Inc.|Oracle
Weblogic  025070,000.00
Tuxedo    021230,000.00
JRockit   021040,000.00
IN30/06/2004;Navneet Singh;Oracle;Oracle Apps;5;70,000.00;350,000.00

Native Schema

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        xmlns:tns="http://www.oracle.com/ias/processconnect/"
        targetNamespace="http://www.oracle.com/ias/processconnect/"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">
 
<element name="container">
 
  <complexType>
    <choice maxOccurs="unbounded" nxsd:choiceCondition="fixedLength"
 nxsd:length="2">
    
      <element ref="tns:PurchaseOrder" nxsd:conditionValue="PO" />
      
      <element ref="tns:SalesOrder" nxsd:conditionValue="SO" />
      
      <element ref="tns:Invoice" nxsd:conditionValue="IN" />
      
    </choice>
  </complexType>
</element>
 
<!-- PO -->
<element name="PurchaseOrder" type="tns:POType"/>
 
<complexType name="POType">
  <sequence>
 
    <element name="Date" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="^" />
    <element name="Buyer" type="string" nxsd:style="surrounded"
       nxsd:surroundedBy="|" />
    <element name="Supplier" type="string" nxsd:style="terminated"
 nxsd:terminatedBy="${eol}" />
    <element name="Items">
      <complexType>
        <sequence>
          <element name="Line-Item" minOccurs="3" maxOccurs="3">
            <complexType>
              <group ref="tns:LineItems" />
            </complexType>
          </element>
        </sequence>
      </complexType>
    </element>
  </sequence>
</complexType>
 
<group name="LineItems">
  <sequence>
    <element name="Id" type="string" nxsd:style="fixedLength" nxsd:length="10"
        nxsd:padStyle="none"/>
    <element name="Quantity" type="string" nxsd:style="fixedLength"
        nxsd:identifierLength="2" />
    <element name="Price" type="string" nxsd:style="terminated"
        nxsd:terminatedBy="${eol}" />
  </sequence>
</group>
 
<!-- SO -->
<element name="SalesOrder" type="tns:SOType" />
 
<complexType name="SOType">
  <sequence>
    <element name="Date" type="string" nxsd:style="terminated"
        nxsd:terminatedBy="|" />
    <element name="Item" type="string" nxsd:style="terminated"
        nxsd:terminatedBy="|" />
    <element name="Quantity" type="string" nxsd:style="terminated"
        nxsd:terminatedBy="${eol}" />
    <element name="Buyer" type="string" nxsd:style="terminated"
        nxsd:terminatedBy="${eol}" />
  </sequence>
</complexType>
 
<!-- INV -->
<element name="Invoice" type="tns:INVType" />
 
<complexType name="INVType">
  <sequence>
    <element name="Date" type="string" nxsd:style="terminated"
       nxsd:terminatedBy=";" />
    <element name="Purchaser" type="string" nxsd:style="terminated"
       nxsd:terminatedBy=";" />
    <element name="Seller" type="string" nxsd:style="terminated"
       nxsd:terminatedBy=";" />
    <element name="Item" type="string" nxsd:style="terminated"
       nxsd:terminatedBy=";" />
    <element name="Price" type="string" nxsd:style="terminated"
       nxsd:terminatedBy=";" />
    <element name="Quantity" type="string" nxsd:style="terminated"
       nxsd:terminatedBy=";" />
    <element name="TotalPrice" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="${eol}" />
  </sequence>
</complexType>
 
</schema>

Translated XML Using the Native Schema

<container xmlns="http://www.oracle.com/ias/processconnect/">
   <PurchaseOrder>
      <Date>28/06/2004</Date>
      <Buyer>ABCD Inc.</Buyer>
      <Supplier>Oracle</Supplier>
      <Items>
         <Line-Item>
            <Id>OracleApps</Id>
            <Quantity>50</Quantity>
            <Price>70,000.00</Price>
         </Line-Item>
         <Line-Item>
            <Id>Database  </Id>
            <Quantity>12</Quantity>
            <Price>30,000.00</Price>
         </Line-Item>
         <Line-Item>
            <Id>ProcessCon</Id>
            <Quantity>10</Quantity>
            <Price>40,000.00</Price>
         </Line-Item>
      </Items>
   </PurchaseOrder>
   <PurchaseOrder>
      <Date>01/07/2004</Date>
      <Buyer>EFGH Inc.</Buyer>
      <Supplier>Oracle</Supplier>
      <Items>
         <Line-Item>
            <Id>DB2       </Id>
            <Quantity>12</Quantity>
            <Price>30,000.00</Price>
         </Line-Item>
         <Line-Item>
            <Id>Eclipse   </Id>
            <Quantity>10</Quantity>
            <Price>40,000.00</Price>
         </Line-Item>
      </Items>
   </PurchaseOrder>
   <SalesOrder>
      <Date>29/06/2004</Date>
      <Item>Oracle Apps</Item>
      <Quantity>5</Quantity>
      <Buyer>Navneet Singh</Buyer>
   </SalesOrder>
   <PurchaseOrder>
      <Date>28/06/2004</Date>
      <Buyer>IJKL Inc.</Buyer>
      <Supplier>Oracle</Supplier>
      <Items>
         <Line-Item>
            <Id>Weblogic  </Id>
            <Quantity>50</Quantity>
            <Price>70,000.00</Price>
         </Line-Item>
         <Line-Item>
            <Id>Tuxedo    </Id>
            <Quantity>12</Quantity>
            <Price>30,000.00</Price>
         </Line-Item>
         <Line-Item>
            <Id>JRockit   </Id>
            <Quantity>10</Quantity>
            <Price>40,000.00</Price>
         </Line-Item>
      </Items>
   </PurchaseOrder>
   <Invoice>
      <Date>30/06/2004</Date>
      <Purchaser>Navneet Singh</Purchaser>
      <Seller>Oracle</Seller>
      <Item>Oracle Apps</Item>
      <Price>5</Price>
      <Quantity>70,000.00</Quantity>
      <TotalPrice>350,000.00</TotalPrice>
   </Invoice>
</container>
6.2.2.6.2 Processing Elements Within a Sequence Model Group Based on the Condition

The following sections explain the format of the data to be translated, the native schema, and the translated XML.

Native Data Format to be Translated

PO28/06/2004^|ABCD Inc.|Oracle
OracleApps025070,000.00
Database  021230,000.00
ProcessCon021040,000.00
PO01/07/2004^|EFGH Inc.|Oracle
DB2       021230,000.00
Eclipse   021040,000.00
SO29/06/2004|Oracle Apps|5
Navneet Singh
PO28/06/2004^|IJKL Inc.|Oracle
Weblogic  025070,000.00
Tuxedo    021230,000.00
JRockit   021040,000.00
IN30/06/2004;Navneet Singh;Oracle;Oracle Apps;5;70,000.00;350,000.00

Native Schema

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        xmlns:tns="http://www.oracle.com/ias/processconnect/"
        targetNamespace="http://www.oracle.com/ias/processconnect/"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">
 
<element name="container">
 
  <complexType>
    <sequence maxOccurs="unbounded">
    
      <element ref="tns:PurchaseOrder" minOccurs="0" nxsd:startsWith="PO" />
      
      <element ref="tns:SalesOrder" minOccurs="0" nxsd:startsWith="SO" />
      
      <element ref="tns:Invoice" minOccurs="0" nxsd:startsWith="IN" />
      
    </sequence>
  </complexType>
</element>
 
<!-- PO -->
<element name="PurchaseOrder" type="tns:POType"/>
 
<complexType name="POType">
  <sequence>
 
    <element name="Date" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="^" />    <element name="Buyer" type="string" nxsd:style="surrounded"
       nxsd:surroundedBy="|" />
    <element name="Supplier" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="${eol}" />
    <element name="Items">
      <complexType>
        <sequence>
          <element name="Line-Item" minOccurs="3" maxOccurs="3">
            <complexType>
              <group ref="tns:LineItems" />
            </complexType>
          </element>
        </sequence>
      </complexType>
    </element>
  </sequence>
</complexType>
 
<group name="LineItems">
  <sequence>
    <element name="Id" type="string" nxsd:style="fixedLength" nxsd:length="10"
        nxsd:padStyle="none"/>
    <element name="Quantity" type="string" nxsd:style="fixedLength"
        nxsd:identifierLength="2" />
    <element name="Price" type="string" nxsd:style="terminated"
        nxsd:terminatedBy="${eol}" />
  </sequence>
</group>
 
<!-- SO -->
<element name="SalesOrder" type="tns:SOType" />
 
<complexType name="SOType">
  <sequence>
    <element name="Date" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="|" />
    <element name="Item" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="|" />
    <element name="Quantity" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="${eol}" />
    <element name="Buyer" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="${eol}" />  </sequence>
</complexType>
 
<!-- INV -->
<element name="Invoice" type="tns:INVType" />
 
<complexType name="INVType">
  <sequence>
    <element name="Date" type="string" nxsd:style="terminated"
       nxsd:terminatedBy=";" />
    <element name="Purchaser" type="string" nxsd:style="terminated"
       nxsd:terminatedBy=";" />
    <element name="Seller" type="string" nxsd:style="terminated"
       nxsd:terminatedBy=";" />
    <element name="Item" type="string" nxsd:style="terminated"
       nxsd:terminatedBy=";" />    <element name="Price" type="string" nxsd:style="terminated"
       nxsd:terminatedBy=";" />
    <element name="Quantity" type="string" nxsd:style="terminated"
       nxsd:terminatedBy=";" />
    <element name="TotalPrice" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="${eol}" />
  </sequence>
</complexType>
 
</schema>

Translated XML Using the Native Schema

<container xmlns="http://www.oracle.com/ias/processconnect/">
   <PurchaseOrder>
      <Date>28/06/2004</Date>
      <Buyer>ABCD Inc.</Buyer>
      <Supplier>Oracle</Supplier>
      <Items>
         <Line-Item>
            <Id>OracleApps</Id>
            <Quantity>50</Quantity>
            <Price>70,000.00</Price>
         </Line-Item>
         <Line-Item>
            <Id>Database  </Id>
            <Quantity>12</Quantity>
            <Price>30,000.00</Price>
         </Line-Item>
         <Line-Item>
            <Id>ProcessCon</Id>
            <Quantity>10</Quantity>
            <Price>40,000.00</Price>
         </Line-Item>
      </Items>
   </PurchaseOrder>
   <PurchaseOrder>
      <Date>01/07/2004</Date>
      <Buyer>EFGH Inc.</Buyer>
      <Supplier>Oracle</Supplier>
      <Items>
         <Line-Item>
            <Id>DB2       </Id>
            <Quantity>12</Quantity>
            <Price>30,000.00</Price>
         </Line-Item>
         <Line-Item>
            <Id>Eclipse   </Id>
            <Quantity>10</Quantity>
            <Price>40,000.00</Price>
         </Line-Item>
      </Items>
   </PurchaseOrder>
   <SalesOrder>
      <Date>29/06/2004</Date>
      <Item>Oracle Apps</Item>
      <Quantity>5</Quantity>
      <Buyer>Navneet Singh</Buyer>
   </SalesOrder>
   <PurchaseOrder>
      <Date>28/06/2004</Date>
      <Buyer>IJKL Inc.</Buyer>
      <Supplier>Oracle</Supplier>
      <Items>
         <Line-Item>
            <Id>Weblogic  </Id>
            <Quantity>50</Quantity>
            <Price>70,000.00</Price>
         </Line-Item>
         <Line-Item>
            <Id>Tuxedo    </Id>
            <Quantity>12</Quantity>
            <Price>30,000.00</Price>
         </Line-Item>
         <Line-Item>
            <Id>JRockit   </Id>
            <Quantity>10</Quantity>
            <Price>40,000.00</Price>
         </Line-Item>
      </Items>
   </PurchaseOrder>
   <Invoice>
      <Date>30/06/2004</Date>
      <Purchaser>Navneet Singh</Purchaser>
      <Seller>Oracle</Seller>
      <Item>Oracle Apps</Item>
      <Price>5</Price>
      <Quantity>70,000.00</Quantity>
      <TotalPrice>350,000.00</TotalPrice>
   </Invoice>
</container>

6.2.2.7 Defining Dates

This examples shows how to define dates.

Native Data to be Translated

11/16/0224/11/02
11-20-2002
23*11*2002
01/02/2003 01:02
01/02/2003 03:04:05

Native Schema

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">
 
<element name="dateformat">
  <complexType>
    <sequence>
      <element name="StartDate" type="dateTime" nxsd:dateFormat="MM/dd/yy"  
         nxsd:style="fixedLength" nxsd:length="8" />
      <element name="EndDate" type="dateTime"   nxsd:dateFormat="dd/MM/yy"  
         nxsd:style="terminated" nxsd:terminatedBy="${eol}" />
      <element name="Milestone" type="dateTime" nxsd:dateFormat="MM-dd-yyyy"
         nxsd:style="terminated" nxsd:terminatedBy="${eol}" />
      <element name="DueDate" type="dateTime"   nxsd:dateFormat="dd*MM*yyyy"
         nxsd:style="terminated" nxsd:terminatedBy="${eol}" />
      <element name="Date" type="dateTime"   nxsd:dateFormat="MM/dd/yyyy hh:mm"
         nxsd:style="terminated" nxsd:terminatedBy="${eol}" />
      <element name="Date" type="dateTime"   nxsd:dateFormat="MM/dd/yyyy hh:mm:ss"
         nxsd:style="terminated" nxsd:terminatedBy="${eol}" />
    </sequence>
  </complexType>
</element>
 
</schema>

Translated XML Using the Native Schema

<dateformat xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
   <StartDate>2002-11-16T00:00:00</StartDate>
   <EndDate>2002-11-24T00:00:00</EndDate>
   <Milestone>2002-11-20T00:00:00</Milestone>
   <DueDate>2002-11-23T00:00:00</DueDate>
   <Date>2003-01-02T01:02:00</Date>
   <Date>2003-01-02T03:04:05</Date>
</dateformat>

Note:

nxsd:dateParsingMode="lax/strict" and locale support have been added to the existing date format.

6.2.2.7.1 Defining Dates: With Locale Support

The following example depicts the use of nxsd:dateParsingMode="lax/strict" and locale support.

Native Data Format to be Translated

11/16/0224/11/02
11-20-2002
23*11*2002
01/02/2003 01:02
01/02/2003 03:04:05
Thu, 26 May 2005 15:50:11 India Standard Time
Do, 26 Mai 2005 15:43:10 Indische Normalzeit
20063202

Native Schema

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">

<element name="dateformat">
  <complexType>
    <sequence>
      <element name="StartDate" type="date" nxsd:dateFormat="MM/dd/yy"
nxsd:localeLanguage="en" nxsd:style="fixedLength" nxsd:length="8" />
      <element name="EndDate" type="date"   nxsd:dateFormat="dd/MM/yy"
nxsd:style="terminated" nxsd:terminatedBy="${eol}" />
      <element name="Milestone" type="dateTime" nxsd:dateFormat="MM-dd-yyyy"
nxsd:style="terminated" nxsd:terminatedBy="${eol}" />
      <element name="DueDate" type="dateTime"   nxsd:dateFormat="dd*MM*yyyy"
nxsd:style="terminated" nxsd:terminatedBy="${eol}" />
      
      <element name="Date" type="dateTime"   nxsd:dateFormat="MM/dd/yyyy hh:mm"
nxsd:style="terminated" nxsd:terminatedBy="${eol}" />
      <element name="Date" type="dateTime"   nxsd:dateFormat="MM/dd/yyyy hh:mm:ss"
nxsd:style="terminated" nxsd:terminatedBy="${eol}" />
      
      <element name="LongDateInEnglish" type="dateTime"   nxsd:dateFormat="EEE, d
MMM yyyy HH:mm:ss zzzz" nxsd:localeLanguage="en" nxsd:localeCountry="US"
nxsd:style="terminated" nxsd:terminatedBy="${eol}" />
      <element name="LongDateInGerman" type="dateTime"   nxsd:dateFormat="EEE, d
MMM yyyy HH:mm:ss zzzz" nxsd:localeLanguage="de" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />
      
      <element name="InvalidDate" type="dateTime"   nxsd:dateParsingMode="lax"
nxsd:dateFormat="yyyyMMdd" nxsd:style="terminated" nxsd:terminatedBy="${eol}" />
      
    </sequence>
  </complexType>
</element>

</schema>

Translated XML

<dateformat xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
   <StartDate>2002-11-16</StartDate>
   <EndDate>2002-11-24</EndDate>
   <Milestone>2002-11-20T00:00:00</Milestone>
   <DueDate>2002-11-23T00:00:00</DueDate>
   <Date>2003-01-02T01:02:00</Date>
   <Date>2003-01-02T03:04:05</Date>
   <LongDateInEnglish>2005-05-26T15:50:11</LongDateInEnglish>
   <LongDateInGerman>2005-05-26T15:43:10</LongDateInGerman>
   <InvalidDate>2008-08-02T00:00:00</InvalidDate>
</dateformat>

6.2.2.8 Using Variables

This example shows how to use variables.

Native Data Format to Be Translated

{,;}Fred,"2 Old Street, Old Town,Manchester","20-08-1954";"0161-499-1718"
phone-2
phone-3

Native Schema

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">
 <element name="variable">
  <annotation>
    <documentation>
      1. var1 - variable declaration
      2. var2 - variable declaration with default value
      3. EOL - variable declaration with referencing a system variable
    </documentation>
    <appinfo>
      <junkies/>
      <nxsd:variables>
        <nxsd:variable name="var1" />
        <nxsd:variable name="var2" value="," />
        <nxsd:variable name="SystemEOL" value="${system.line.separator}" />
      </nxsd:variables>
      <junkies/>
      <junkies/>
      <junkies/>
    </appinfo>
  </annotation>
  
  <complexType>
    <sequence>
      <element name="delims" type="string" nxsd:style="surrounded"
          nxsd:leftSurroundedBy="{" nxsd:rightSurroundedBy="}" >
         <annotation>
           <appinfo>
             <junkies/>
             <junkies/>
             <junkies/>
             <nxsd:variables>
              <nxsd:assign name="var1" value="${0,1}"/>
              <nxsd:assign name="var2" value="${1}" />
             </nxsd:variables>
           </appinfo>
         </annotation>
      </element>
 
      <element name="PersonName" type="string" nxsd:style="terminated"
          nxsd:terminatedBy="${var1}" nxsd:quotedBy="&quot;" />
      <element name="Address" type="string" nxsd:style="terminated"
          nxsd:terminatedBy="${var1}" nxsd:quotedBy="&quot;"/>
      <element name="DOB" type="string" nxsd:style="terminated"
          nxsd:terminatedBy="${var2}" nxsd:quotedBy='"'/>
      <element name="Telephone1" type="string" nxsd:style="terminated"
          nxsd:terminatedBy="${eol}" nxsd:quotedBy='"'/>
      <element name="Telephone2" type="string" nxsd:style="terminated"
          nxsd:terminatedBy="${eol}" nxsd:quotedBy='"'/>
      <element name="Telephone3" type="string" nxsd:style="terminated"
          nxsd:terminatedBy="${eol}" nxsd:quotedBy='"'/>
    </sequence>
  </complexType>
</element>
 
</schema>

Translated XML Using the Native Schema

<variable xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
   <delims>,;</delims>
   <PersonName>Fred</PersonName>
   <Address>2 Old Street, Old Town,Manchester</Address>
   <DOB>20-08-1954</DOB>
   <Telephone1>0161-499-1718</Telephone1>
   <Telephone2>phone-2</Telephone2>
   <Telephone3>phone-3</Telephone3>
</variable>

6.2.2.9 Defining Prefixes and Suffixes

In native format, when data is read, the specified data is prefixed, suffixed, or both, as shown in the following example.

Native Data to Be Translated

     Fred,  "2 Old Street, Old Town,Manchester","20-08-1954",0161-499-1718

Native Schema

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD"
        >

<element name="terminated">
  <complexType>
    <sequence>
      <element name="PersonName" type="string" nxsd:prefixWith="Mr."
       nxsd:style="terminated" nxsd:terminatedBy="," nxsd:quotedBy="&quot;" />
      <element name="Address" type="string" nxsd:suffixWith="]]"
       nxsd:prefixWith="[[" nxsd:style="terminated" nxsd:terminatedBy=","
       nxsd:quotedBy="&quot;"/>
      <element name="DOB" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="," nxsd:quotedBy='"'/>
      <element name="Telephone" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="${eol}" nxsd:quotedBy='"'/>
    </sequence>
  </complexType>
</element>

</schema>

Translated XML Using the Native Schema

<terminated xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
   <PersonName>Mr.Fred</PersonName>
   <Address>[[2 Old Street, Old Town,Manchester]]</Address>
   <DOB>20-08-1954</DOB>
   <Telephone>0161-499-1718</Telephone>
</terminated>

6.2.2.10 Defining Skipping Data

Translator skips, before or after the data is read, depending on the skipMode construct, as shown in the following example:

Native Data to Be Translated

     Fred,   "2 Old Street, Old Town,Manchester","20-08-1954",0161-499-1718

Native Schema

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD"
        >

<element name="terminated">
  <complexType>
    <sequence>
      <element name="PersonName" type="string" nxsd:skip="5"
       nxsd:style="terminated" nxsd:terminatedBy="," nxsd:quotedBy="&quot;" />
      <element name="Address" type="string" nxsd:skipMode="before" nxsd:skip="3"
       nxsd:style="terminated" nxsd:terminatedBy="," nxsd:quotedBy="&quot;"/>
      <element name="DOB" type="string" nxsd:skipMode="after" nxsd:skip="6"
       nxsd:style="terminated" nxsd:terminatedBy="," nxsd:quotedBy='"'/>
      <element name="Telephone" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="${eol}" nxsd:quotedBy='"'/>
    </sequence>
  </complexType>
</element>

</schema>

Translated XML Using Native Schema

<terminated xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
   <PersonName>Fred</PersonName>
   <Address>2 Old Street, Old Town,Manchester</Address>
   <DOB>20-08-1954</DOB>
   <Telephone>99-1718</Telephone>
</terminated>

6.2.2.11 Defining fixed and default Values

When an element is declared without nxsd annotations but the value specified is either fixed or default, the translator uses the value provided and does not throw any exceptions.

Native Data to Be Translated

Fred,"2 Old Street, Old Town,Manchester","20-08-1954","0161-499-1718"

Native Schema

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">

<element name="terminated">
  <annotation>
    <appinfo>
      <nxsd:variables>
        <nxsd:variable name="x" value="hello" />
      </nxsd:variables>
      <junkies/>
      <junkies/>
      <junkies/>
    </appinfo>
  </annotation>

  <complexType>
    <sequence>
      <element name="PersonName" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="," nxsd:quotedBy="&quot;" />
      <element name="Age" type="string" fixed="16"  />
      <element name="Address" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="," nxsd:quotedBy="&quot;"/>
      <element name="DOB" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="," nxsd:quotedBy='"'/>
      <element name="salutation" type="string" default="${x}"  />
      <element name="Telephone" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="${eol}" nxsd:quotedBy='"'/>
    </sequence>
  </complexType>
</element>

</schema>

Translated XML Using Native Schema

<terminated xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
   <PersonName>Fred</PersonName>
   <Age>16</Age>
   <Address>2 Old Street, Old Town,Manchester</Address>
   <DOB>20-08-1954</DOB>
   <salutation>hello</salutation>
   <Telephone>0161-499-1718</Telephone>
</terminated>

6.2.2.12 Defining write

The write construct writes the literal at the current position in the output stream, either before writing the actual data or after writing it.

Input XML

<terminated xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
   <PersonName>Fred</PersonName>
   <Address>2 Old Street, Old Town,Manchester</Address>
   <DOB>20-08-1954</DOB>
   <Telephone>0161-499-1718</Telephone>
</terminated>

Native Schema

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD"
        >

<element name="terminated">
  <complexType>
    <sequence>
      <element name="PersonName" type="string" nxsd:writeMode="before"
       nxsd:write="Mr." nxsd:style="terminated" nxsd:terminatedBy=","
       nxsd:quotedBy="&quot;" />
      <element name="Address" type="string" nxsd:writeMode="after"
       nxsd:write="Over." nxsd:style="terminated" nxsd:terminatedBy=","
       nxsd:quotedBy="&quot;"/>
      <element name="DOB" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="," nxsd:quotedBy='"'/>
      <element name="Telephone" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="${eol}" nxsd:quotedBy='"'/>
    </sequence>
  </complexType>
</element>

</schema>

Translated Data Using Native Schema

Mr.Fred,"2 Old Street, Old Town,Manchester",Over.20-08-1954,0161-499-1718

6.2.2.13 Defining LookAhead

The LookAhead construct is of the following types:

  • Type 1: LookAhead X chars, read the value from a position using a style, and match against the specified literal.

  • Type 2: LookAhead X chars, read the value from a position using a style, and store that value in a variable to be used later.

6.2.2.13.1 LookAhead: Type 1

LookAhead X chars, read the value from a position using a style, and match against the specified literal.

Native Data Format to Be Translated

Fred,"2 Old Street, Old Town,Manchester","20-08-1954","0161-499-1718",YES

Native Schema

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">

<element name="LookAhead">
  <complexType>
    <sequence minOccurs="0" nxsd:lookAhead="70" nxsd:lookFor="YES">
      <element name="PersonName" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="," nxsd:quotedBy="&quot;" />
      <element name="Address" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="," nxsd:quotedBy="&quot;"/>
      <element name="DOB" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="," nxsd:quotedBy='"'/>
      <element name="Telephone" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="," nxsd:quotedBy='"'/>
    </sequence>
  </complexType>
</element>

</schema>

Translated XML Using Native Schema

<LookAhead xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
   <PersonName>Fred</PersonName>
   <Address>2 Old Street, Old Town,Manchester</Address>
   <DOB>20-08-1954</DOB>
   <Telephone>0161-499-1718</Telephone>
</LookAhead>
6.2.2.13.2 LookAhead: Type 2

In native schema, LookAhead X chars, read the value from a position using a style, and store that value in a variable to be used later.

Native Data Format to Be Translated

Name1,"2 Old Street, Old Town,Manchester",20-08-1954,"0161-499-1718", YES
Name2,"2 Old Street, Old Town,Manchester",20-08-1954,"0161-499-1718", NO
Name3,"2 Old Street, Old Town,Manchester",20-08-1954,"0161-499-1718", NO
Name4,"2 Old Street, Old Town,Manchester",20-08-1954,"0161-499-1718", YES

Native Schema

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">

<!--
nxsd:lookAhead="70" nxsd:scan="3"
-->

<element name="LookAhead">
  <complexType>
    <choice maxOccurs="unbounded" nxsd:choiceCondition="${x}" nxsd:lookAhead="70"
       nxsd:scanLength="3" nxsd:assignTo="${x}">
      <element name="Record1" type="string" nxsd:conditionValue="YES"
       nxsd:style="terminated" nxsd:terminatedBy="," nxsd:skipMode="after"
       nxsd:skipUntil="${eol}" />
      <element name="Record2" type="string" nxsd:conditionValue="NO "
       nxsd:style="terminated" nxsd:terminatedBy="," nxsd:skipMode="after"
       nxsd:skipUntil="${eol}" />
    </choice>
  </complexType>
</element>

</schema>

Translated XML Using Native Schema

<LookAhead xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
   <Record1>Name1</Record1>
   <Record2>Name2</Record2>
   <Record2>Name3</Record2>
   <Record1>Name4</Record1>
</LookAhead>

6.2.2.14 Defining Complex Look Ahead Strategies for Conditional Processing of Record Using Regular Expressions

The NXSD wizard provides look ahead attributes that enable you to specify Regular Expression patterns for filtering both fixed length records and variable length records.

You can use conditional processing support, using look ahead attributes with Fixed Length, Delimited and Complex file types.

Using this conditional processing, you can obtain results where only the records that satisfy the regular expression are published in XML.

You can also specify the option to raise an exception when a record does not satisfies regular expression. This assists in conditional processing by providing a choice condition.

For Regular Expression support you can specify the Character Sequence against which the Regular Expression can be matched. Note that the Character Sequence should not go beyond the record boundary.

For Fixed Length records, the length of the record and the record's various fields are known in advance. This helps you specify the starting position and the length of the stream against which the Regular Expression is to be matched.

See Table 6-6 for a list of fixed length record nxsd constructs and their definition.

The construct is provided in its nxsd: format, but has its equivalent in the Native Format Builder user interface and the construct is referenced in the discussion of the appropriate screen in the Native Format Builder Wizard.

Table 6-6 Fixed Length Record LookAhead Constructs

Construct Description

nxsd:lookAhead

Looks for a match ahead of the current position in the input stream. If a match is found, the record for which you have specified this construct is processed; otherwise, it is skipped. Use this feature as follows:

nxsd:lookAhead="20" nxsd:lookForPattern=".*Pattern.*" nxsd:scanLength="30"

This indicates to skip 20 characters and to look for the java.util.regex.Pattern ".*Pattern.*" in the next 30 characters. If pattern is found, the record is processed; otherwise, it is skipped.

This construct can be user with both lookFor and lookForPattern.

nxsd:lookForPattern

Specify the regular expression, the java.util.regex.Pattern , which is matched against the input stream.

nxsd:scanLength

Specify the length of the data in the input stream after lookAhead. This data is matched against the lookForPattern.

nxsd:reportLookAheadError

Specify the Boolean value, whether an error is raised for not matching the data with lookForPattern. Default value is 'false' which means do not raise an error for not matching data with lookForPattern and skip the unmatched record. This might result in unmatched records not being processed and might appear to a user as loss of data.

Refer to the following use cases.

  • You do not specify nxsd:scanLength is, the uniqueMessageSeparator is used to determine the Character Sequence.

    uniqueMessageSeparator is a String specifying the unique message separator in the native data, in a batch of messages. If the uniqueMessageSeparator is not specified then the default ${eol} is used.

    In the following scenario, since nxsd:scanLength is not specified, the Translator uses uniqueMessageSeparator to determine the character sequence, which is matched against the regular expression.

    • Scan all the records where the address is New Town. The Native Data is:

      #Fred,"2 Old Street, Old Town, Manchester","17-08-1954","0161-498-1718", YES
#Tred,"2 Old Street, Old Town, Manchester","16-08-1974","0161-486-1718", YES
John,"2 Old Street, New Town, Manchester","20-08-2004","0161-497-1718", NO
#

      The NXSD for this is the following:, using uniqueMessageSeparator to help determine the character sequence, is:

      <schema …
 nxsd:uniqueMessageSeparator="#">
<sequence minOccurs="0" maxOccurs="unbounded" nxsd:lookAhead="0" nxsd:lookForPattern="*New Town*">

    • Scan all the records where address is in New Town, and where nxsd:uniqueMessageSeparator is not specified. The Translator uses ${eol} to determine the Character Sequence, which is matched against the regular expression.

      Fred,"2 Old Street, Old Town, Manchester","17-08-1954","0161-498-1718", YES
Tred,"2 Old Street, Old Town, Manchester","16-08-1974","0161-486-1718", YES
John,"2 Old Street, New Town, Manchester","20-08-2004","0161-497-1718", NAH

      The NXSD for this is:

      <sequence minOccurs="0" maxOccurs="unbounded" nxsd:lookAhead="0" nxsd:lookForPattern="*New Town*">

  • The following use cases do not use nxsd:uniqueMessageSeparator:

    In a second use case, you specify nxsd:scanLength to determine the Character Sequence.

    Fred,"2 Old Street, New Town, Manchester","17-08-1954","0161-498-1718", YES
Tred,"2 Old Street, Old Town, Manchester","16-08-1974","0161-486-1718", YES
John,"2 Old Street, New Town, Manchester","20-08-2004","0161-497-1718", NAH

    The NXSD to use against this data is:

    <sequence minOccurs="0" maxOccurs="3" nxsd:lookAhead="0" nxsd:lookForPattern=".*New Town.*" nxsd:scanLength="73">

    • Scan all records where the second field is made up of digits only. The Native Data is:

      Fred, add, 20-08-1954, 0161-498-1718", YES
Tred, 100, 20-08-1954, 0161-486-1718", YES
John, add, 20-08-1954, 0161-497-1718", NAH

      The NXSD to determine if the second field is made up of digits only is:

      <sequence minOccurs="0" maxOccurs="3" nxsd:lookAhead="0" nxsd:lookForPattern=".*,\d+,.*" nxsd:scanLength="38">

    • Scan all records where zip contains 5 digits only. The Native Data is:

      Fred, zipID, 20-08-1954, 0161-498-1718", YES
Tred, 90210, 20-08-1954, 0161-486-1718", YES
John, 9021Z, 20-08-1954, 0161-497-1718", NAH

      The NXSD to look for the appropriate pattern and make the 5-digit determination is:

      <sequence minOccurs="0" maxOccurs="3" nxsd:       lookAhead="0" nxsd:lookForPattern=".*,\d{5},.*" nxsd:scanLength="40">

    • Scan all records where the name does not include any digit and the second field contains a five-digit zip code. The Native Data is:

      JohnBrown, zipID, 20-08-1954, 0161-498-1718", YES
Sweety101, 90210, 20-08-1954, 0161-486-1718", YES
CrowyBowy, 90210, 20-08-1954, 0161-497-1718", NAH

      The NXSD for this, again using the regular expressions, is:

      <sequence minOccurs="0" maxOccurs="4" nxsd:lookAhead="0" nxsd:lookForPattern="[a-zA-Z]*,\d{5},.*" nxsd:scanLength="45">

Using scan length works well with Fixed records, but the limitation with a variable length record is that the length of this type of record in not known in advance. Hence, the nxsd:scanLength attribute cannot be used in such scenarios. The Translator would require a way to determine the character sequence which would be matched against regular expression.

To address this limitation with variable length records, rather than using nxsd:scanLength, you can use two attributes when doing a complex lookahead, nxsd:LookFrom and nxsd:lookTill.

The character sequence, where a pattern can be matched, can be derived through nxsd:lookFrom and nxsd:lookTill attributes. The basic NXSD for a lookahead scan for a variable length record is:

nxsd:lookFrom="FirstInstanceOfString" nxsd:lookTill="firstInstanceOfString after lookFrom" 
nxsd:lookForPattern="java.util.regex.Pattern" [nxsd:skipUntill="${eol} or Literal"]

See Table 6-7 for a list of Variable Length Record lookAhead Constructs.

The construct is provided in its nxsd: format, but has its equivalent in the Native Format Builder user interface and the construct is referenced in the discussion of the appropriate screen.

Table 6-7 Variable Length Record lookahead Constructs

Construct Definition

nxsd:lookFrom

Specify the Literal, data is matched only after lookFrom Literal is found in input stream

nxsd:lookForPattern

Specify the java.util.regex.Pattern , (regular expression) which is matched against the input stream.

nxsd:lookTill

Specify the Literal up to which data in input stream is matched. Data in input stream between nxsd:lookFrom (excluded) and lookTill (excluded) is matched against lookForPattern.

nxsd:skipUntil

Specify Literal up to which data in the input stream is skipped, when the data does not match against lookForPattern.

nxsd:reportLookAheadError

Specify the Boolean value if an error is raised for not matching the data with lookForPattern. The default value is 'false' which means do not raise an error for not matching data with lookForPattern and also skip the unmatched record.

Note that when you create the NXSD for translating Native files, you can specify lookAhead in the schema to extract values based on the regular expression specified using lookForPattern.

However, when extracting variable length records, because you do not know the length of record, you can use lookFrom and lookTill attributes in NXSD element, thus, using JDeveloper Native Format Builder User Interface window, you specify values to lookFrom and lookTill with or without skipUntil.

There are a few use cases relevant to an understanding of these constructs when using complex look ahead with variable length records.

  • For the first use case, scan all records with address in New Town where nxsd:lookTill is the end of the record. In this case, the Translator must know what position to skip to if schema element cardinality is not exceeded and nxsd:lookForPattern does not match.

    Tred,"2 Old Street, NEW Town,Manchester",@NAH
Bred,"2 Old Street, Old Town,Manchester",@NAH
dred,"2 Old Street, New Town,Manchester",@YES
Hred,"2 Old Street, Old Town,Manchester",@YES
Bred,"2 Old Street, Old Town,Manchester",@YES

    The NXSD for this use case is the following, indicating to look for New Town, with the end of record indicated by nxsd:lookTill="${eol}

    <sequence minOccurs="0" maxOccurs="3" nxsd:lookFrom="Street" nxsd:lookTill="${eol}" nxsd:lookForPattern=".*New Town.*">

  • In another use case, nxsd:lookTill is not the end of the record. In this case, the Translator does not know till what position to skip when a record does not match.

    You can indicate the position to skip to when a record does not match information by using the attribute nxsd:skipUntil.

    You must explicitly define the nxsd:skipUntil clause in conjunction with the nxsd:lookTill clause.

    When using nxsd:skipUntil, always specify the end of record, that is:

    nxsd:skipUntil=" ${eol} or Literal"

    • In this use case, scan all records with address in New Town. The Native Data is:

      Tred,"2 Old Street, NEW Town, Manchester", @NAH
Bred,"2 Old Street, Old Town, Manchester", @NAH
Dred, "2 Old Street, New Town, Manchester", @YES
Hred,"2 Old Street, Old Town, Manchester", @YES
Bred,"2 Old Street, Old Town, Manchester", @YES

      The NXSD for this is indicates to skip until end of file if a record is not matched, but only to look until "Manchester":

      <sequence minOccurs="0" maxOccurs="3" nxsd:lookFrom="Street" nxsd:lookTill=" Manchester" nxsd:lookForPattern=".*New Town.*" nxsd:skipUntil="${eol}">

    • You could also match the regular expression from some predefined position to the occurrence of some string. To do this, specify the starting position using nxsd:lookAhead along with the nxsd:lookTill attribute.

      This is useful in scenarios where you do not have knowledge of the nxsd:lookFrom attribute but where you do know the end of record.

      In such scenarios, you can specify the nxsd:lookAhead="0" and nxsd:lookTill="end of record". In this case, you must ensure that the nxsd:lookTill is specified till end of record.

      In the following example, you want to scan all records with address in New Town. The Native Data is:

      Tred,"2 Old Street, NEW Town, Manchester", @NAHBred,"2 Old Street, Old Town, Manchester", @NAHDred,"2 Old Street, New Town, Manchester", @YESHred,"2 Old Street, Old Town, Manchester", @YESBred,"2 Old Street, Old Town, Manchester", @YES

      The NXSD for this use case, where you know the end of record, is:

      <sequence minOccurs="0" maxOccurs="3" nxsd:lookAhead="0" nxsd:lookForPattern=".*New Town.*" nxsd:lookTill="${eol}">

    • In another case nxsd:lookTill is not the end of record. You must specify the nxsd:skipUntil. This indicates the point at which the Translator has to skip the record where the record does not match against the given Regular Expression.

      In the following example, scan all records with address in New Town.

    • Tred,"2 Old Street, NEW Town, Manchester", @NAH
Bred,"2 Old Street, Old Town, Manchester", @NAH
Dred,"2 Old Street, New Town, Manchester", @YES
Hred,"2 Old Street, Old Town, Manchester", @YES
Bred,"2 Old Street, Old Town, Manchester", @YES

      The NXSD for this, when nxsd:skipUntil defines the end of record is:

      <sequence minOccurs="0" maxOccurs="3" nxsd:lookAhead="0" nxsd:lookForPattern=".*New Town.*" nxsd:lookTill="Manchester" nxsd:skipUntil="${eol}">

    • Using the JDeveloper Native Format Builder User Interface window, you can specify values to lookAhead and lookTill with or without using skipUntil, but when you select them in the JDeveloper UI and proceed next to see the NXSD source, the schema misses the lookTill attribute. To avoid this issue, explicitly write <namespace>:lookTill="literal" with the lookAhead attribute.

6.2.2.14.1 Including the Newline Character when Looking for a Pattern

For every row in a record that has a newline character, the newline character should be included as char while defining the Complex Look Ahead patterns for finding the last word in the statement.

For example, if you are looking for the following record

canvas,"1 17th Cross, North
London,England","17-08-1954","0161-498-1718",YES

You might think you could use the following as the pattern for which to look.

nxsd:lookAhead="73" nxsd:scanLength="3" 
nxsd:lookForPattern=".ES"

However, if the record searched for is actually the following, with the newline character:

canvas,"1 17th Cross, North 
London,England","17-08-1954","0161-498-1718",YES\n

Thus, the lookForPattern clause to find this record should be the following:

nxsd:lookForPattern=".ES\n"

or, to accommodate for the delimiter,

nxsd:lookForPattern=".ES."

Hence the attributes are

nxsd:lookAhead="73" nxsd:scanLength="4" 
nxsd:lookForPattern=".ES\n" or nxsd:lookForPattern=".ES."

6.2.2.15 Defining outboundHeader

The actual content of outboundHeader can use variables, specifically ${eol}. When headerLines and outboundHeader both are available, outboundHeader takes precedence in the outbound.

Note:

In the inbound direction, the Skipping Headers feature is supported. Only predefined variables can be used in a header because other variables might either not be accessible or would have only literals.

Input XML

<terminated xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
   <PersonName>Fred</PersonName>
   <Address>2 Old Street, Old Town,Manchester</Address>
   <DOB>20-08-1954</DOB>
   <Telephone>0161-499-1718</Telephone>
</terminated>

Native Schema

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD"
        nxsd:hasHeader="true"
        nxsd:outboundHeader="This is a header ${eol}">

<element name="terminated">
  <complexType>
    <sequence>
      <element name="PersonName" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="," nxsd:quotedBy="&quot;" />
      <element name="Address" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="," nxsd:quotedBy="&quot;"/>
      <element name="DOB" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="," nxsd:quotedBy='"'/>
      <element name="Telephone" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="${eol}" nxsd:quotedBy='"'/>
    </sequence>
  </complexType>
</element>

</schema>

Translated Data

This is a header
Fred,"2 Old Street, Old Town,Manchester",20-08-1954,0161-499-1718

6.2.2.16 Defining Complex Condition in conditionValue

When you use the conditionValue construct along with the choiceCondition construct, you can specify match criteria such as equals (==) and not equals (!=), along with the Boolean operators AND and OR, for comparison between the value read and the value specified in the conditionValue construct.

Native Data Format to Be Translated

Order, ID41678, 20May2000
Item1, GigaWidget, 60, $75
Item2, MegaBucket, 48, $125
Cust1, Hopkins Associates, ID26490
Order, ID41680, 20May2000
Item3, Rt.Clopper, 40, $100
Item4, Lt.Clopper, 50, $100
Cust2, Jersey WebInovaters, ID46786

Native Schema

<?xml version="1.0" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/extensions/SampleNS"
            xmlns:tns="http://xmlns.oracle.com/pcbpel/nxsd/extensions/SampleNS"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified" nxsd:encoding="US-ASCII"
nxsd:stream="chars" nxsd:version="NXSD">

<xsd:element name="Container">
    <xsd:complexType>
      <xsd:choice minOccurs="1" maxOccurs="unbounded"
       nxsd:choiceCondition="terminated" nxsd:terminatedBy=",">
        <xsd:element name="Customer" nxsd:conditionValue="(== Cust1) or (== Cust2)
         and (!= emp)">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="C1" type="xsd:string" nxsd:style="terminated"
               nxsd:terminatedBy="," nxsd:quotedBy="&quot;">
              </xsd:element>
              <xsd:element name="C2" type="xsd:string" nxsd:style="terminated"
               nxsd:terminatedBy="${eol}" nxsd:quotedBy="&quot;">
              </xsd:element>
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
        <xsd:element name="Item" nxsd:conditionValue="(== Item1) or (== Item2) or
         (==Item3) or (== Item4)">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="C1" type="xsd:string" nxsd:style="terminated"
               nxsd:terminatedBy="," nxsd:quotedBy="&quot;">
              </xsd:element>
              <xsd:element name="C2" type="xsd:string" nxsd:style="terminated"
               nxsd:terminatedBy="," nxsd:quotedBy="&quot;">
              </xsd:element>
              <xsd:element name="C3" type="xsd:string" nxsd:style="terminated"
               nxsd:terminatedBy="${eol}" nxsd:quotedBy="&quot;">
              </xsd:element>
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
        <xsd:element name="Order" nxsd:conditionValue="Order">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="C1" type="xsd:string" nxsd:style="terminated"
               nxsd:terminatedBy="," nxsd:quotedBy="&quot;">
              </xsd:element>
              <xsd:element name="C2" type="xsd:string" nxsd:style="terminated"
               nxsd:terminatedBy="${eol}" nxsd:quotedBy="&quot;">
              </xsd:element>
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
      </xsd:choice>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

Translated XML Using Native Schema

<Container xmlns="http://xmlns.oracle.com/pcbpel/nxsd/extensions/SampleNS">
   <Order>
      <C1> ID41678</C1>
      <C2> 20May2000</C2>
   </Order>
   <Item>
      <C1> GigaWidget</C1>
      <C2> 60</C2>
      <C3> $75</C3>
   </Item>
   <Item>
      <C1> MegaBucket</C1>
      <C2> 48</C2>
      <C3> $125</C3>
   </Item>
   <Customer>
      <C1> Hopkins Associates</C1>
      <C2> ID26490</C2>
   </Customer>
   <Order>
      <C1> ID41680</C1>
      <C2> 20May2000</C2>
   </Order>
   <Item>
      <C1> Rt.Clopper</C1>
      <C2> 40</C2>
      <C3> $100</C3>
   </Item>
   <Item>
      <C1> Lt.Clopper</C1>
      <C2> 50</C2>
      <C3> $100</C3>
   </Item>
   <Customer>
      <C1> Jersey WebInovaters</C1>
      <C2> ID46786</C2>
   </Customer>
</Container>

6.2.2.17 Defining Complex Condition in choiceCondition

The choiceCondition construct is used along with the conditionValue construct for records that are complex and may have fields delimited by multiple delimiter types. The other choiceCondition types available are FixedLength, Variable, and Ad hoc. The following example is for the variable choiceCondition type.

Native Data Format to Be Translated

Name1,"2 Old Street, Old Town,Manchester",20-08-1954,"0161-499-1718", YES
Name2,"2 Old Street, Old Town,Manchester",20-08-1954,"0161-499-1718", NO

Native Schema

<element name="LookAhead">
  <complexType>
    <choice maxOccurs="unbounded" nxsd:choiceCondition="${x}" nxsd:lookAhead="70" nxsd:scanLength="3" nxsd:assignTo="${x}">
      <element name="Record1" type="string" nxsd:conditionValue="YES" nxsd:style="terminated" nxsd:terminatedBy="," nxsd:skipMode="after" nxsd:skipUntil="${eol}" />
      <element name="Record2" type="string" nxsd:conditionValue="NO " nxsd:style="terminated" nxsd:terminatedBy="," nxsd:skipMode="after" nxsd:skipUntil="${eol}" />
    </choice>
  </complexType>
</element>

Translated XML Using Native Schema

<LookAhead xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
   <Record1>Name1</Record1>
   <Record2>Name2</Record2>
</LookAhead>

6.2.2.18 Defining dataLines

If the requirement is to translate only a portion of the data and not the entire data, then you can specify the number of lines to be ignored from the beginning of the file and the number of lines to be translated from that point onwards by using the dataLines construct.

Native Data Format to Be Translated

Fred,addr,20-08-1954,0161-499-1718
Tam,addr,20-08-1954,0161-499-1718
Albert,addr,20-08-1954,0161-499-1718
Bill,addr,20-08-1954,0161-499-1718
Phil,addr,20-08-1954,0161-499-1718

Native Schema

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD"
        
        nxsd:headerLines="1"
        nxsd:dataLines="1">

<element name="terminated">
  <complexType>
    <sequence maxOccurs="unbounded">
      <element name="PersonName" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="," />
      <element name="Address" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="," />
      <element name="DOB" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="," />
      <element name="Telephone" type="string" nxsd:style="terminated"
       nxsd:terminatedBy="${eol}" />
    </sequence>
  </complexType>
</element>

</schema>

Translated XML Using Native Schema

<terminated xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
   <PersonName>Tam</PersonName>
   <Address>addr</Address>
   <DOB>20-08-1954</DOB>
   <Telephone>0161-499-1718</Telephone>
</terminated>

6.2.2.19 Defining Date Formats with Time Zone

In the translator, the date or time must be associated with a time zone. The translator supports the date formats with time zone for both, the date in native data and for the date in XML.

There are two parts when translating a date/time string. First, the format of the date in the native data (dateformat), second is the time zone to use when parsing that date (timeZone or useTimeZone). The translator uses these details while parsing the date/time string.

After the parsing, by default, the date string is converted to the ISO-8601 format in an XML. You can override the defaults by using XMLDateFormat and XMLTimeZone, or useTimeZone.

Native Data Format to Be Translated

11/16/0224/11/02
11-20-2002
23*11*2002
01/02/2003 01:02
01/02/2003 03:04:05
Thu, 26 May 2005 15:50:11 India Standard Time
Do, 26 Mai 2005 15:43:10 Indische Normalzeit
20063202
11/16/02

Native Schema

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">

<element name="dateformat">
  <complexType>
    <sequence>
      <element name="StartDate" type="date" nxsd:dateFormat="MM/dd/yy"  
       nxsd:localeLanguage="en" nxsd:style="fixedLength" nxsd:length="8" />

      <element name="EndDate" type="date"   nxsd:dateFormat="dd/MM/yy"  
       nxsd:style="terminated" nxsd:terminatedBy="${eol}" />

      <element name="Milestone" type="dateTime" nxsd:useTimeZone="UTC"
       nxsd:dateFormat="MM-dd-yyyy" nxsd:style="terminated"        nxsd:terminatedBy="${eol}" />

      <element name="DueDate" type="dateTime" nxsd:useTimeZone="UTC"
       nxsd:dateFormat="dd*MM*yyyy" nxsd:style="terminated" nxsd:terminatedBy="${eol}" />
      
      <element name="Date" type="dateTime" nxsd:useTimeZone="UTC"
       nxsd:dateFormat="MM/dd/yyyy hh:mm" nxsd:style="terminated"
       nxsd:terminatedBy="${eol}" />

      <element name="Date" type="dateTime" nxsd:useTimeZone="UTC"
       nxsd:dateFormat="MM/dd/yyyy hh:mm:ss" nxsd:style="terminated"
       nxsd:terminatedBy="${eol}" />
      
      <element name="LongDateInEnglish" type="dateTime" 
       nxsd:displayTimeZone="true" nxsd:useTimeZone="IST" nxsd:dateFormat="EEE, d MMM
       yyyy HH:mm:ss zzzz" nxsd:localeLanguage="en" nxsd:localeCountry="US"
       nxsd:style="terminated" nxsd:terminatedBy="${eol}" />

      <element name="LongDateInGerman"  type="dateTime" 
       nxsd:displayTimeZone="true" nxsd:useTimeZone="IST" nxsd:dateFormat="EEE, d MMM
       yyyy HH:mm:ss zzzz" nxsd:localeLanguage="de" nxsd:style="terminated"
       nxsd:terminatedBy="${eol}" />
      
      <element name="InvalidDate" type="dateTime" nxsd:useTimeZone="UTC"
       nxsd:dateParsingMode="lax" nxsd:dateFormat="yyyyMMdd" nxsd:style="terminated"
       nxsd:terminatedBy="${eol}" />

      <element name="MyFormatDate" type="string" nxsd:dateFormat="MM/dd/yy" 
       nxsd:xmlDateFormat="dd-MM-yyyy" nxsd:localeLanguage="en" nxsd:style="fixedLength"
       nxsd:length="8" />
      
    </sequence>
  </complexType>
</element>

</schema>

Translated XML Using Native Schema

<dateformat xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
   <StartDate>2002-11-16</StartDate>
   <EndDate>2002-11-24</EndDate>
   <Milestone>2002-11-20T00:00:00</Milestone>
   <DueDate>2002-11-23T00:00:00</DueDate>
   <Date>2003-01-02T01:02:00</Date>
   <Date>2003-01-02T03:04:05</Date>
   <LongDateInEnglish>2005-05-26T15:50:11+05:30</LongDateInEnglish>
   <LongDateInGerman>2005-05-26T15:43:10+05:30</LongDateInGerman>
   <InvalidDate>2008-08-02T00:00:00</InvalidDate>
   <MyFormatDate>16-11-2002</ MyFormatDate >
</dateformat>

6.2.2.20 Implementing Validation During Translation

You must configure Oracle JCA Adapters to implement validation during translation. Validation helps ensure that Oracle JCA Adapters do not publish invalid messages during translation.

You can implement either one or both of the following types of validation:

6.2.2.20.1 Payload Validation

Payload validation involves validating the input and output XML messages that are processed by Oracle JCA Adapters. You can set payload validation at one of the these levels:

Top-Level Validation

In top-level validation, the DOMResult (result in the form of a Document Object Model) is validated against the XML schema. This form of validation is implemented on both inbound and outbound payloads. This form of validation can control the publishing of invalid records and provide information about XML validation errors. However, it does not provide translation context. For example, information about the line and column in the native stream where the error was encountered is not provided by top-level validation.

To implement top-level validation of XML messages:

  • The nxsd namespace in the message must be set to the following:

    xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"

  • The validation flag must be set to true as follows:

    nxsd:validation="true"

For example:

<schema xmlns="http://www.w3.org/2001/XMLSchema" 
     xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd" 
        targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest" 
        elementFormDefault="qualified" 
         attributeFormDefault="unqualified" 
        nxsd:stream="chars" 
         nxsd:version="NXSD" 
        nxsd:validation="true" 
        >

Field Level Validation

In field-level validation, the individual fields are validated against the XML schema. This form of validation is implemented only on inbound payloads, not on outbound payloads.

If the XML message does not conform to the XML schema, then information about the exact line and character where the error was encountered is displayed.

To implement field-level validation of XML messages:

  • The nxsd namespace in the message must be set to the following:

    xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"

  • The validation flag must be set to true as follows:

    nxsd:fieldValidation="true"

For example:

<schema xmlns="http://www.w3.org/2001/XMLSchema" 
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd" 
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest" 
elementFormDefault="qualified" 
attributeFormDefault="unqualified" 
 nxsd:stream="chars" 
  nxsd:version="NXSD" 
   nxsd:fieldValidation="true" 
   >
6.2.2.20.2 Schema Validation

Schema validation involves validating the schema (native schemas or XML schemas) that you define for the native or XML data formats to be translated by the Oracle JCA Adapters.

To enable schema validation:

  • The nxsd namespace in the message must be set to the following:

    xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"

  • The validate nxsd flag must be set to true as follows:

    nxsd:validateNxsd="true"

For example:

<schema xmlns="http://www.w3.org/2001/XMLSchema" 
     xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd" 
        targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest" 
        elementFormDefault="qualified" 
         attributeFormDefault="unqualified" 
        nxsd:stream="chars" 
         nxsd:version="NXSD" 
        nxsd: validateNxsd ="true" 
        >

Note:

The nxsd:validateNxsd="true" validation flag does not affect payload level validations.

6.2.2.21 Processing Files with BOM

The byte order mark (BOM) is a special U+FEFF Unicode character that describes the encoding of a byte sequence. The Native Format Translator can be configured to use BOM for determining the character encoding of the native input data. By default, BOM is not used. If your input data uses BOM, then set the nxsd:parseBom attribute to true in the native schema. Otherwise, the translator throws a parsing error.

The following is a sample nxsd file:

<?xml version= '1.0' encoding= 'UTF-8' ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
             xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
             xmlns:tns="http://TargetNamespace.com/InboundService"
             targetNamespace="http://TargetNamespace.com/InboundService"
             elementFormDefault="qualified" attributeFormDefault="unqualified"
             nxsd:parseBom="true" nxsd:version="NXSD" nxsd:stream="chars"
 nxsd:encoding="UTF8">
     <xsd:element name="Root-Element">
         <xsd:complexType>
             <xsd:sequence>
                 <xsd:element name="mydata" minOccurs="1" maxOccurs="unbounded"
                     nxsd:style="array"
                     nxsd:cellSeparatedBy="${eol}">
                     <xsd:complexType>
                         <xsd:sequence>
                             <xsd:element name="C1" type="xsd:string"
                                nxsd:style="fixedLength"
                                nxsd:length="3"/>
                         </xsd:sequence>
                     </xsd:complexType>
                 </xsd:element>
             </xsd:sequence>
         </xsd:complexType>
     </xsd:element>
 </xsd:schema>

6.2.3 Multi-Byte Translation for Inbound and Outbound Native Data

The Native Format Builder processes inbound fixed-length native data in terms of characters. The translator internally uses character data. With support for Multi-Byte streaming in 12c, you can specify the length of a field in terms of bytes instead of characters. This enables the inbound Oracle translator to read the data as bytes and convert them into characters based on the encoding used. Similarly, the outbound Translator converts the XML Data into bytes (and not characters) and writes them to the output stream.

6.2.3.1 The Initial Problem

However, you might want to specify the field length as bytes, and to process fixed length data where length has to be specified in terms of bytes. For fixed length binary data, such specifying is very useful because specifying the length in characters would not be as helpful.

This not a problem with a single byte character set; however, it is a problem with a multi byte character set as the length in bytes is not equal to the length in characters.

6.2.3.2 Solution

To solve this problem and to enable you to specify the field length in terms of bytes, the NXSD translator supports specifying the length of the field in terms of bytes. Specifically, you can specify the length unit as either Byte or Char. The default value is Char. To specify this unit length, use the following convention:

nxsd:lengthUnits="Byte|Char"

Byte specifies that the length of the field is to be translated in terms of Bytes, and Char indicates that the length of the field is specified in terms of character.

Note that you must make manual changes to the files to provide for both inbound and outbound multi-byte translation. You cannot do this through the Native Format Builder User Interface.

6.2.3.3 Specifying Padded Data

You can also specify inbound data as padded data. When you do this, the translator strips off all the occurrences of padded data.

To use this feature, you must let the translator know the format of the padded Byte data it is stripping off. Use the following convention to do so:

nxsd:paddedDataType="decimal|binary|octal|hexbinary|string" nxsd:paddedBy="XYZ"

See the following table for a description of the padded Data Type formats that you can specify as inputs.

Format Description

Decimal

Padded data specified is in decimal format. You must specify the decimal values corresponding to the padded bytes.

Each decimal digit is expressed in 'nnn' format for example, 32 is expressed as '032'. If you wish to specify multiple digits, then each digit must follow the same format; for example, 001002123 would mean 3 bytes (1, 2 and 123)

nxsd:paddedDataType="decimal" nxsd:padStyle="head"
nxsd:paddedBy='032032'

Binary

Padded data specified is in Binary format. You must specify the binary values corresponding to the padded bytes. If you want to specify more than one byte as padded data, then the length corresponding to each byte must be eight. For example:

nxsd:paddedDataType="binary" nxsd:padStyle="head" nxsd:paddedBy='0010000000100000'/

Oct

Padded data specified is in Octal format. You must specify the octal values corresponding to the padded bytes. If you want to specify more than one byte as padded data then the length corresponding to each byte must be three. For example,

nxsd:paddedDataType="octal" nxsd:padStyle="head" nxsd:paddedBy='040040'

hexbinary

Padded data specified is in Hexadecimal format. You have to specify the hexbinary values corresponding to the padded bytes. If you want to specify more than one byte as padded data, then the length corresponding to each byte must be two. For example,

nxsd:paddedDataType="hexBinary" nxsd:padStyle="head" nxsd:paddedBy='2020'

string

Padded data specified is in String format. Translator would use the encoding specified at schema level (nxsd:encoding). For example,

nxsd:paddedDataType="string" nxsd:padStyle="head"nxsd:paddedBy='

Note:

Note that the SJIS character can be used in padding only when paddedDataType="string"

6.2.3.4 Specifying a Prefix or a Suffix

You can also specify the prefix and suffix which could be appended to the incoming data before publishing to the XML To do, use the following convention:

nxsd:prefixWith="XXXX" nxsd:suffixWith="YYYY"

Note:

While reading/writing data in byte mode in FixedLength style, the translator does not support specifying a prefix and suffix with base64Binary and hexBinary data.

6.2.3.5 Translator Behavior with Multi-Stream Data

The behavior of the Translator depends upon the type of data to be published to the XML. For example ,you might specify the type as

type="xsd:string|xsd:hexBinary|xsd:base64Binary"

If data type is specified as string, the Translator reads the specified number of bytes for the input stream.

However, if the input stream does not contain sufficient data, the translator throws an exception.

Once the Translator has read the specified number of bytes, it strips off all padded data from the read bytes. After removing the padded data, Translator converts remaining bytes to Character.

If the remaining bytes do not match the character boundary, or if the remaining bytes cannot be converted to Character for any reason, the Translator throws an exception.

If the data is successfully converted to the Characters, these Characters are published to the XML.

If data type you specify is either hexBinary or base64Binary, after removing the padded data, the Translator converts the remaining bytes to the specified data type and they are published to the XML.

6.2.3.6 Outbound Translation Behavior

For outbound translation, you can specify the field length in terms of bytes. The Translator generates the bytes corresponding to the data specified in XML

Once data is converted to bytes, the Translator first removes any prefix or suffix (if present).

For string types (that is, elements that are not defined as xsd:hexBinary or xsd:base64Binary in the schema) the prefix and suffix are removed before the value is converted to bytes for padding and writing out.

For binary types, prefix and suffix are not allowed, as previously mentioned.

The translator checks for the number of bytes generated along with the length specified in the schema. If the number of bytes generated are more than that of specified in Schema, translator throws an exception.

If the generated bytes are less than that of specified in length, the translator adds the paddedBy data bytes at the start or end of generated bytes as specified in schema.

6.2.3.7 Examples

The following examples provide XSD, XML and text files representing Translation.

6.2.3.7.1 Base 64 Binary Padded Data

The following are examples of Base 64 Binary Padded Data conversion. In the XSD, the translator is told to strip off strings using nxsd:paddedDataType=

<?xml version="1.0" encoding="SJIS"?>
 
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
            targetNamespace="http://xmlns.oracle.com/test"
            xmlns:tns="http://xmlns.oracle.com/test"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified" 
              nxsd:stream="bytes" nxsd:version="NXSD" 
                   nxsd:encoding="SJIS" >
  <xsd:element name="root">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="field1" type="xsd:base64Binary" nxsd:style="fixedLength" nxsd:length="14"
           nxsd:lengthUnit="byte" nxsd:paddedDataType="string" 
            nxsd:padStyle="head" nxsd:paddedBy="‚Ì"/>
      <xsd:element name="field2" type="xsd:base64Binary"
              nxsd:style="fixedLength" nxsd:length="13" 
               nxsd:lengthUnit="byte"  
                   nxsd:paddedDataType="string" 
                    nxsd:padStyle="tail" 
                     nxsd:paddedBy="‚Ì"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

The XML is

<root xmlns="http://xmlns.oracle.com/test">
   <field1>g32Di4Ngg2+DQ4Nn</field1>
   <field2>IILMg1SDfIFbg2c=</field2>
</root>
6.2.3.7.2 Binary

This example shows conversion of multiple field binary data.

The XSD follows. Note that nxsd:lengthUnits="Byte" which indicates the length of the field is to be translated in terms of Bytes.

<?xml version="1.0" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
            targetNamespace="http://style.onron.com/pcbpel/demo"
            xmlns:tns="http://style.onron.com/pcbpel/demo"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified"              nxsd:stream="bytes" nxsd:version="NXSD" 
            nxsd:encoding="SJIS"
            >
  <xsd:element name="Root-Element">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="field1" type="xsd:base64Binary" nxsd:style="fixedLength" nxsd:length="10" 
               nxsd:lengthUnit="Byte"/>
                <xsd:element name="field2" 
              type="xsd:base64Binary" nxsd:style="fixedLength" 
                     nxsd:length="10" 
                    nxsd:lengthUnit="Byte"/>
        <xsd:element name="field3" type="xsd:hexBinary" 
                nxsd:style="fixedLength" nxsd:length="20"
                 nxsd:lengthUnit="Byte"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

The XML is:

<Root-Element xmlns="http://style.onron.com/pcbpel/demo">
   <field1>gqCCooKkICAgIA==</field1>
   <field2>gqmCq4KtICAgIA==</field2>
   <field3>82BD82BF82C282C482C620202020202020202020
                    </field3>
</Root-Element>
6.2.3.7.3 Shift JIS Encoding

The following provide an example of shift JIS encoding in bytes.

The XSD is:

<?xml version="1.0" encoding="SJIS"?>
 
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:nxsd="http://xmlns.oracle.com/
                                pcbpel/nxsd"
            targetNamespace="http://xmlns.oracle.com/
                              test"
            xmlns:tns="http://xmlns.oracle.com/test"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified"
              nxsd:stream="bytes" 
               nxsd:version="NXSD"
                  nxsd:encoding="SJIS" >
  <xsd:element name="root">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="field1"
           type="xsd:hexBinary"
                  nxsd:style="fixedLength"
        nxsd:length="14" nxsd:lengthUnit="byte" 
            nxsd:paddedDataType="string" 
                     nxsd:padStyle="head"
                nxsd:paddedBy="‚Ì"/>
      <xsd:element name="field2" 
                  type="xsd:hexBinary" 
            nxsd:style="fixedLength"
                  nxsd:length="13" 
            nxsd:lengthUnit="byte"  
            nxsd:paddedDataType="string" 
            nxsd:padStyle="tail"                   nxsd:paddedBy="‚Ì"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

The corresponding XML is

<root xmlns="http://xmlns.oracle.com/test">
   <field1>837D838B8360836F83438367</field1>
   <field2>2082CC8354837C815B8367</field2>
</root>
6.2.3.7.4 Identifier Length Example

The IdentifierLength construct indicates the number of characters and bytes in which the actual length of the data is stored, while lengthUnit enables you to specify the field length in bytes.

<?xml version="1.0" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
            targetNamespace="http://style.onron.com/pcbpel/demo"
            xmlns:tns="http://style.onron.com/pcbpel/demo"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified"
               nxsd:stream="bytes" nxsd:version="NXSD" 
            nxsd:encoding="SJIS"
            >
            
  <xsd:element name="Root-Element">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="field1" type="xsd:string"
              nxsd:style="fixedLength" 
              nxsd:identifierLength="2" 
              nxsd:lengthUnit="Byte"/>
        <xsd:element name="field3" type="xsd:string"
              nxsd:style="fixedLength" 
              nxsd:identifierLength="2" 
              nxsd:lengthUnit="Byte"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>
6.2.3.7.5 Identifier Example base64BInary

The following example shows a similar Identifierlength statement, except the type is base64Binary.

The XSD is:

<?xml version="1.0" ?>
 
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
            targetNamespace="http://style.onron.com/pcbpel/demo"
            xmlns:tns="http://style.onron.com/pcbpel/demo"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified" nxsd:stream="bytes" nxsd:version="NXSD" 
            nxsd:encoding="SJIS"
            >
            
  <xsd:element name="Root-Element">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="field1" type="xsd:base64Binary"                  nxsd:style="fixedLength" nxsd:identifierLength="2" 
          nxsd:lengthUnit="Byte"/>
        <xsd:element name="field3" type="xsd:hexBinary"
          nxsd:style="fixedLength" 
          nxsd:identifierLength="2" nxsd:lengthUnit="Byte"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

The XML is:

<Root-Element xmlns="http://style.onron.com/pcbpel/demo">
   <field1>gqCCooKkICAgIA==</field1>
   <field3>82BD82BF82C282C482C620202020202020202020</field3>
</Root-Element>
6.2.3.7.6 Identifier-Padded Data with SJIS

The following shows a similar Identifier example, but with padded data (by '32') and shifted SJIS encoding.

The xsd is:

<?xml version="1.0" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
            targetNamespace="http://style.onron.com/pcbpel/demo"
            xmlns:tns="http://style.onron.com/pcbpel/demo"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified" 
              nxsd:stream="bytes" nxsd:version="NXSD" 
              nxsd:encoding="SJIS"
            >
  <xsd:element name="Root-Element">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="field1" type="xsd:string"
           nxsd:style="fixedLength" nxsd:identifierLength="2" nxsd:lengthUnit="Byte" nxsd:padStyle="head" nxsd:paddedBy='32'/>
        <xsd:element name="field3" type="xsd:string" 
           nxsd:style="fixedLength" 
           nxsd:identifierLength="2"  
           nxsd:lengthUnit="Byte" 
           nxsd:padStyle="tail" 
           nxsd:paddedBy='32'/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>
6.2.3.7.7 Identifier-Padded Binary

Another identifier example shows padded binary data.

The xsd for this example is:

<?xml version="1.0" ?>
 
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
            targetNamespace="http://style.onron.com/pcbpel/demo"
            xmlns:tns="http://style.onron.com/pcbpel/demo"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified" nxsd:stream="bytes" nxsd:version="NXSD" 
            nxsd:encoding="SJIS"
            >
  <xsd:element name="Root-Element">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="field1" type="xsd:base64Binary" nxsd:style="fixedLength" nxsd:identifierLength="2"
          nxsd:lengthUnit="Byte" nxsd:padStyle="head" 
           nxsd:paddedBy='32'/>
        <xsd:element name="field3" type="xsd:hexBinary" 
           nxsd:style="fixedLength" nxsd:identifierLength="2" nxsd:lengthUnit="Byte" nxsd:padStyle="tail" 
           nxsd:paddedBy='32'/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

The XML is:

<Root-Element xmlns="http://style.onron.com/pcbpel/demo">
   <field1>gqmCq4KC</field1>
   <field3>82BD82BF82C282C482C6</field3>
</Root-Element>
6.2.3.7.8 Padded Multibyte Binary Element

The XSD for padded multi-byte binary is:

<?xml version="1.0" ?>
 
 <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
            targetNamespace="http://style.onron.com/pcbpel/demo"
            xmlns:tns="http://style.onron.com/pcbpel/demo"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified" 
                nxsd:stream="bytes"
                nxsd:version="NXSD" 
            nxsd:encoding="SJIS"
            nxsd:validateNxsd="true">
            
  <xsd:element name="Root-Element">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="field1" type="xsd:base64Binary" nxsd:style="fixedLength" nxsd:length="10" nxsd:lengthUnit="Byte" nxsd:paddedDataType="binary" nxsd:padStyle="head" nxsd:paddedBy='0010000000100000'/>

        <xsd:element name="field2" type="xsd:hexBinary" 
           nxsd:style="fixedLength" nxsd:length="20" 
           nxsd:lengthUnit="Byte" nxsd:padStyle="tail" 
          nxsd:paddedDataType="binary" 
          nxsd:paddedBy='0010000000100000'/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

The XML is:

<Root-Element xmlns="http://style.onron.com/pcbpel/demo">
   <field1>gqmCq4Kt</field1>
   <field2>82BD82BF82C282C482C6</field2>
</Root-Element>
6.2.3.7.9 Padded Multi-Byte Decimal

The padded multi-byte decimal XML is:

<?xml version="1.0" ?>
 
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
            targetNamespace="http://style.onron.com/pcbpel/demo"
            xmlns:tns="http://style.onron.com/pcbpel/demo"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified" 
               nxsd:stream="bytes" 
               nxsd:version="NXSD" 
               nxsd:encoding="SJIS">
            
  <xsd:element name="Root-Element">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="field1" type="xsd:base64Binary" nxsd:style="fixedLength" nxsd:length="10" 
         nxsd:lengthUnit="Byte"
         nxsd:paddedDataType="decimal" 
         nxsd:padStyle="head" 
         nxsd:paddedBy='032032'/> 
        <xsd:element name="field2" type="xsd:hexBinary" 
        nxsd:style="fixedLength" nxsd:length="20"
         nxsd:lengthUnit="Byte" nxsd:padStyle="tail" 
         nxsd:paddedDataType="decimal" 
         nxsd:paddedBy='032032'/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

6.2.4 SOSI Support

The Translator also provides support to escape bytes (SHIFT_OUT, SHIFT_IN) from the input stream.

This support is specifically provided to support SJIS encoding, where, in mixed Double Byte Character Set mode, SHIFT_OUT and SHIFT_IN bytes are inserted to the data to indicate the change of mode (from single byte to double byte).

To use SOSI support with the Translator, use the following convention:

nxsd:escapeBytes="sosi"

Note that the SJIS character can be used in padding only when paddedDataType="string"

6.3 Translator XPath Functions

The Translator XPath functions can translate data from a native format (such as CSV, fixed-length, tab-delimited, and COBOL Copybook formats) to an XML format and from an XML format to a native format. The translator XPath functions are of two types, streaming and non-streaming.

The difference is that the streaming translator XPath functions implement the batching transformation approach while the non-streaming XPath functions do not implement the batching transformation approach. With the batching transformation approach, files that are of the order of a few gigabytes (GB) can be processed without running into memory issues.

This section includes the following topics:

6.3.1 Terminologies

This section describes the terminologies that you must understand for using translation XPath functions.

Attachment Element

An attachment element unusually refers to the actual content elsewhere by using an "href" attribute. The actual content may be present in a file system or in a database table.

An attachment is usually represented by using the following schema construct:

<element name="hrefelement">
    <complexType>
        <attribute name="href" type="string"/>
    </complexType>
</element>

The "href" attribute contains the actual location of the data being referred to. It can contain the path to a file in the file system or a pointer (primary key) to a database entity.

Scalable DOM

Scalable DOM (SDOM), from Oracle XML Developer Kit (Oracle XDK), provides scalable and pluggable support for DOM. This removes problems of memory inefficiency, limited scalability, and lack of control over the DOM configuration.

Using the lazy materialization mechanism, Oracle XDK only creates nodes that are accessed and frees unused nodes from memory. Applications can process very large XML documents with improved scalability.

6.3.2 Translator XPath Functions

A translator may be required while reading and writing files. This section discusses the following translator XPath functions:

6.3.2.1 doTranslateFromNative Function

The doTranslateFromNative XPath function translates input data into XML. The input data can be a string, an attachment element, or a base64Binary element.

ora:dotranslateFromNative('input','nxsdTemplate','nxsdRoot','targetType','attachment element?')

The following table describes the parameters used in the syntax for using this function:

Parameter Description

input

Input data for the XPath function; the data can either be a string data that must be translated, an Oracle File or FTP Adapter attachment, an attachment referring to an external file path, or a base64Binary element.

nxsdTemplate

NXSD schema to use to translate the input data into XML format.

nxsdRoot

Root element in the NXSD schema.

targetType

This parameter des how the XPath function translates the native data into XML. Must be set to either 'DOM', or 'ATTACHMENT' or 'SDOM'. If the targetType parameter is:

  • 'DOM', then the translated data is returned as a DOM.

  • 'ATTACHMENT', then the translated data is returned as an attachment. If the optional parameter (attachmentElement) is available to the XPath function, then the XPath function uses the corresponding href attribute to write the translated XML. However, if the parameter is absent, then the XPath function creates a new database-backed attachment and returns that. See the following example for more details.

  • 'SDOM', then the translated data is returned as SDOM. You must use this if the returned XML file is huge.

attachmentElement

This parameter is optional. This is the attachment for the returned XML file.

Example - Configuring the XPath Function When the Input Data Is of String Type and Must Be Converted to an XML DOM

<variables>
     <variable…/>
    <variable name="csv_data" type="xsd:string"/>
  </variables>
<assign name="assignCSVData">
      <copy>
        <from expression="'this, is, csv, data…'"/>
        <to variable="csv_data"/>
      </copy>
</assign>
 
<assign name="doTranslateFromNativeCall">
      <copy>
        <from expression="ora: doTranslateFromNative               (bpws:getVariableData('csv_data'),                  'xsd/address-csv.xsd',                    'Root-Element','DOM')"/>
        <to variable="returnVariable" query="/ns1:Root-Element"/>
      </copy>
    </assign>

In this example:

  • csv_data is a BPEL variable containing CSV data to be translated into XML.

  • xsd/address-csv.xsd is relative path to the NXSD schema in the project.

  • Root-Element is a root element in the NXSD schema (This is optional.)

  • returnVariable is the returned XML data as DOM.

Example - When the Input data is an Attachment, Which Must Be Translated to a DOM

  1. Define attachmentElement in the schema of the BPEL process, as follows:

    <schema targerNamespace="…">
        <element name="attachmentElement">
            <complexType>
                <attribute name="href" type="string"/>
            </complexType>
        </element>
</schema>

  2. Create a variable of type attachment element in the schema of the BPEL process, as follows:

      <variables>
     <variable…/>
    <variable name="attachmentVariable"          type="client:attachmentElement"/>
  </variables>

  3. Assign the source file path that you must translate, as follows:

    <assign name="AssignAttachmentReference">
  <copy>
    <from expression="'/tmp/xpath/in/address.csv'"/>
    <to variable="attachmentVariable"
            query="/client:attachmentElement/@href"/>
  </copy>
</assign>

  4. Call the XPath function, as follows:

    <assign name="xlateFromNative">
  <copy>
    <from expression="ora:doTranslateFromNative        (bpws:getVariableData('attachmentVariable'),          'xsd/address-csv.xsd', 'Root-Element', 'DOM')"/>
    <to variable="returnVariable" query="/ns1:Root-Element"/>
  </copy>
</assign>

In this example:

  • attachmentVariable is an attachment variable in BPEL referring to the source file path.

  • xsd/address-csv.xsd is the relative path to the NXSD schema in the project.

  • Root-Element is a root element in the NXSD schema.

  • returnVariable is the XML data returned as DOM.

Example - Configuring XPath Function When the Input Data Is Base64-encoded and Must Be Translated to DOM

  1. Define the base64-encoded element in the schema of the BPEL process, as follows:

    <schema targerNamespace="…">
  <element name="mtomElement" type="base64Binary"/>
</schema>

  2. Create a variable of type mtom element in the schema of the BPEL process, as follows:

    <variables>
     <variable…/>
    <variable name="encodedData" type="client:mtomElement"/>
</variables>

  3. Assign the source file path that you must translate, as follows

    <assign name="assignBase64EncodedData">
      <copy>
        <from expression="'b3JhY2xl'"/>
        <to variable="encodedData"              query="/client:mtomElement"/>
      </copy>
</assign>
 
<assign name="doTranslateFromNativeCall">
      <copy>
        <from expression="ora: doTranslateFromNative         (bpws:getVariableData('encodedData'), 'xsd/address-csv.xsd','Root-Element','DOM')"/>
        <to variable="returnVariable" 
                      query="/ns1:Root-Element"/>
      </copy>
    </assign>

In this example:

  • mtomElement is a BPEL variable containing base64-encoded data to be translated into XML.

  • xsd/address-csv.xsd is the relative path to the NXSD schema in the project.

  • Root-Element is a root element in the NXSD schema.

  • returnVariable is the XML data returned as DOM.

Example - Configuring XPath Function When the Input Data Is of String Type, Which Must Be Translated to an Attachment Referred to by a File-Path

  1. Define attachmentElement in the schema of the BPEL process, as follows:

    <schema targerNamespace="…">
        <element name="attachmentElement">
            <complexType>
                <attribute name="href" type="string"/>
            </complexType>
        </element>
</schema>

  2. Create an input variable of type string and an output variable of type attachment in the schema of the BPEL process, as follows:

    <variables>
    <variable…/>
    <variable name="csv_data" type="xsd:string"/> 
    <variable name="returnAttachmentVariable" 
            type="client:attachmentElement"/> 
</variables>

  3. Assign the CSV data that you must translate, as follows:

    <assign name="assignCSVData">
    <copy>
      <from expression="'this, is, csv, data…'"/>
      <to variable="csv_data"/>
    </copy>
</assign>

  4. Populate the attachment with the path of the file where you want the translated data to be stored, as follows:

    <assign name="AssignAttachmentReferenceForOutput">
    <copy>
      <from expression="'/tmp/xpath/output/address.xml'"/>
      <to variable=" returnAttachmentVariable "
            query="/client:attachmentElement/@href"/>
    </copy>
</assign>

  5. Call the XPath function as follows:

    <assign name="doTranslateFromNativeCall">
    <copy>
      <from expression="ora: doTranslateFromNative 
      (bpws:getVariableData('csv_    data'),'xsd/address-csv.xsd','Root-Element','ATTACHMENT',   bpws:getVariableData('returnAttachmentVariable'))"/>
      <to variable="returnAttachmentVariable"/>
    </copy>
</assign>

In this example:

  • csv_data is a BPEL string variable containing CSV data to be translated into XML.

  • xsd/address-csv.xsd is the relative path to the NXSD schema in the project.

  • Root-Element is a root element in the NXSD schema.

  • returnAttachmentVariable is the returned attachment.

Note: In this example, targetType is set to ATTACHMENT, and returnAttachmentVariable points to the file path where the translated XML is to be written.

However, the fifth parameter (bpws:getVariableData('returnAttachmentVariable')) is optional. If this parameter is missing, then the XPath function creates a database-backed attachment and returns it. In such a case, the XPath function is configured, as follows:

  1. Define attachmentElement in the schema of the BPEL process, as follows:

    <schema targerNamespace="…">
        <element name="attachmentElement">
            <complexType>
                <attribute name="href" type="string"/>
            </complexType>
        </element>
</schema>

  2. Create an input variable of type string and an output variable of type attachment in the schema of the BPEL process, as follows:

    <variables>
    <variable…/>
    <variable name="csv_data" type="xsd:string"/> 
    <variable name="returnAttachmentVariable"
        type="client:attachmentElement"/> 
</variables>

  3. Assign the CSV data that you must translate, as follows:

    <assign name="assignCSVData">
    <copy>
      <from expression="'this, is, csv, data…'"/>
      <to variable="csv_data"/>
    </copy>
</assign>

<assign name="doTranslateFromNativeCall">
      <copy>
        <from expression="ora: doTranslateFromNative (bpws:getVariableData('csv_data'),'xsd/address-csv.xsd','Root-Element','ATTACHMENT')"/>
        <to variable="returnAttachmentVariable"/>
      </copy>
    </assign>

    After the XPath call returns, the returnAttachmentVariable variable is populated with the href attribute pointing to the GUID representing the database-backed attachment.

    Note: If the data being translated is huge, then you must use either ATTACHMENT or SDOM as the targetType parameter for the XPath function.

6.3.2.2 doTranslateToNative Function

The doTranslateToNative XPath function translates an input DOM into string data or an attachment.

Syntax

ora:dotranslateToNative('input','nxsdTemplate','nxsdRoot','targetType','attachmentElement?')

The following table describes the parameters used in the syntax for using this function:

Table 6-8 do TranslateToNative Function Parameters

Parameter Description

input

Input data for the XPath function; the data can either be DOM or SDOM data that must be translated to a native format such as CSV.

nxsdTemplate

NXSD schema to be used to translate the input data into XML format.

nxsdRoot

Name of the root element in the NXSD schema.

targetType

This parameter des how the XPath function translates the XML data into native formats. Must be set to either 'STRING', or 'ATTACHMENT'. If the targetType parameter is:

  • STRING, then the translated data is returned as a string.

  • ATTACHMENT, then the translated data is returned as an attachment. If the optional parameter (attachmentElement) is available to the XPath function, then the XPath function uses the corresponding href attribute to write the translated native data. However, if the parameter is absent, then the XPath function creates a new database-backed attachment and returns that. See the following example for more details.

attachmentElement

This parameter is optional. This is the attachment to which the translated data is written.

Example - Configuring the XPath Function When the Input Data Is of XML Format and Must Be Translated Into CSV String Format

<variables>
     <variable…/>
   <variable name="inputDOM" type="ns1:Root-Element"/>
          <!- - data that must be translated into native - ->
    <variable name="returned_csv_data" 
       type="xsd:string"/>
  </variables>
 
<assign name="doTranslateToNativeCall">
      <copy>
        <from expression="ora: doTranslateToNative (bpws:getVariableData('inputDOM'),
        'xsd/address-csv.xsd','Root-Element','STRING')"/>
        <to variable="returned_csv_data"/>
      </copy>
    </assign>

In this example:

  • inputDOM is a BPEL DOM variable containing XML data to be translated into string data representing the translated CSV.

  • xsd/address-csv.xsd is the relative path to the NXSD schema in the project.

  • Root-Element is a root element in the NXSD schema.

  • return_csv_data is the string variable that contains the translated CSV data.

Example - Configuring XPath Function to Translate an Incoming XML DOM into an Attachment Representing the Target File-Path for the Translated CSV

  1. Define attachmentElement in the schema of the BPEL process, as follows:

    <schema targerNamespace="…">
        <element name="attachmentElement">
            <complexType>
                <attribute name="href"
                    type="string"/>
            </complexType>
        </element>
</schema>

  2. Create an input variable of type attachmentElement in the schema of the BPEL process, as follows:

    <variables>
     <variable…/>
    <variable name="inputDOM"
        type="ns1:Root-Element"/>
    <variable name="attachmentVariable" 
         type="client:attachmentElement"/>
  </variables>

  3. Assign the target file path where you want the translated CSV to be written, as follows:

    <assign name="AssignAttachmentReference">
  <copy>
     <from expression=
                     "'/tmp/xpath/out/address.csv'"/>
     <to variable="attachmentVariable"
            query="/client:attachmentElement/@href"/>
  </copy>
</assign>

  4. Call the XPath function, as follows:

    <assign name="xlateToNative">
      <copy>
        <from expression="ora:doTranslateToNative
            (bpws:getVariableData('inputDOM'),'xsd/address-csv.xsd'        'Root-Element', 'ATTACHMENT', bpws:getVariableData
           (' attachmentVariable'))"/>
        <to variable="attachmentVariable"/>
      </copy>
    </assign>

In this example:

  • inputDOM is a BPEL DOM variable containing XML data to be translated into a CSV output file represented by /tmp/xpath/out/address.csv.

  • xsd/address-csv.xsd is the relative path to the NXSD schema in the project.

  • Root-Element is a root element in the NXSD schema.

  • AttachmentElement points to the target output file path represented by /tmp/xpath/out/address.csv.

Note: In this example, targetType is set to ATTACHMENT, and AttachmentVariable points to the file path where the translated CSV file is to be written.

However, the fifth parameter (bpws:getVariableData('attachmentVariable')) is optional. If this parameter is missing, then the XPath function creates a database-backed attachment and returns it. In such a case, the XPath function is configured as follows:

  1. Define attachmentElement in the schema of the BPEL process, as follows:

    <schema targerNamespace="…">
        <element name="attachmentElement">
            <complexType>
                <attribute name="href" type="string"/>
            </complexType>
        </element>
</schema>

  2. Create an input variable of type attachmentElement in the schema of the BPEL process, as follows:

    <variables>
     <variable…/>
    <variable name="inputDOM" type="ns1:Root-Element"/>
    <variable name="attachmentVariable" 
       type="client:attachmentElement"/>
  </variables>

  3. Call the XPath function, as follows:

    <assign name="xlateToNative">
      <copy>
        <from expression="ora:doTranslateToNative
        (bpws:getVariableData('inputDOM'),
         'xsd/address-csv.xsd', 'Root-Element', 
           'ATTACHMENT')"/>
        <to variable="attachmentVariable"/>
      </copy>
    </assign>

After the XPath call returns, attachmentVariable is populated with the href attribute pointing to the GUID representing the database-backed attachment.

6.3.2.3 doStreamingTranslate Function

XPath functions implement the batching transformation approach. With this approach, files that are of the order of a few gigabytes (GB) can be processed without running into memory issues. Arbitrarily large payloads can be handled because the transformation engine does not store the result of the transformation in its memory. The transformation engine flushes its memory after a batch of elements of the large file is processed. The default batch size is 10000, which is the number of elements after which the transformation engine flushes its memory. This parameter is used internally and is optional.

Note:

Batching transformation approach is supported for XML documents that have repeating structures only.

Syntax

ora:doStreamingTranslate('input','streamingXpathContext','targetType','attachmentElement?')

Table 6-9 describes the parameters used in the syntax for using this function:

Table 6-9 doStreamingTranslate Parameters

Parameter Description

input

Input data for the XPath function; the data can either be SDOM or an Attachment element.

streamingXpathContext

DOM representing the XPath context.

targetType

This parameter des how the XPath function translates the input data into an attachment. This must be set to either SDOM or ATTACHMENT.

attachmentElement

This parameter is optional. This is the attachment to which the data is streamed.

sourceDocumentType

Set this to ATTACHMENT if the source element points to an attachmentElement.

The streamingXPathContext parameter specifies the context for the streaming transformation and, it must conform to the following schema element:

Example - Schema Element to Which streamingXPathContext Must Conform

<schema targetNamespace="…">
    <element name="streamingcontext">
        <complexType>
            <sequence>
                <element name="sourceSchema" 
                    type="string"/>
                <element name="sourceRootElement"
                    type="string"/>
                <element name="sourceType"
                    type="string"/>
                <element name="sourceDocumentType"
                    type="string"/> 
                <element name="xsl" 
                    type="string"/>
                <element name="targetSchema"
                    type="string"/>
                <element name="targetRootElement"
                    type="string"/>
                <element name="targetType" type="string"/>
                <element name="batchSize" type="string"/>
            </sequence>
        </complexType>
    </element>        
</schema>

Table 6-10 streamingXPathContext Path Parameters

Parameter Description

sourceSchema

Source NXSD schema used to translate a native data to XML.

sourceRootElement

Source NXSD schema used to translate a native data to XML

sourceType

Set this to either xml or native depending on the input data.

xsl

Relative path of the xsl.

targetSchema

Target NXSD schema used to translate an XML into native data.

targetRootElement

Name of root element in target NXSD schema.

targetType

Set this to either xml or native depending on the output data.

batchSize

The number of elements after which the transformation engine flushes its memory.

6.3.2.4 Batching Transformation Features

This section discusses the following features of batching transformation:

Applicability

Batching transformation is applicable to:

  • Documents with repeating structure

  • XSLTs not requiring aggregation across entire document

Batched Invocation of XSLT Engine

The following procedure highlights the batched invocation of the XSLT engine:

  1. Splitting the source document into multiple batches of one or more records

  2. Performing the XSLT transformation one batch at a time

  3. Combining the result of the XSLT invocation to a single target document

Splitting or Combining Performed on the Fly

The source documents are split and the results are combined into a target document:

  • Without any intermediate memory or disk storage

  • Through pipelining or intercepting SAX events

Low In-Memory Footprint

Batching transformation method uses low memory for the following tasks:

  • Transforming arbitrarily large XML documents, which are constrained by the target system

  • For standalone tests, 540 MB is transformed in less than 3 minutes

The example below implements the FlatStructure File Adapter sample using streaming transformation XPath functions. This sample use case translates the inbound native attachment from a CSV format to an XML format, and then applies the user-supplied XSL file to the resulting XML file. The transformed XML file is then translated into a fixed-length content represented by an attachment.

Example - Using Streaming Transformation XPath Function

  1. Define attachmentElement, as shown in the example below.

    Example - Defining attachmentElement

    <schema targerNamespace="…">
    <element name="attachmentElement">
        <complexType>
           <attribute name="href"
              type="string"/>
        </complexType>
    </element>
</schema>

  2. Create a variable for the input attachment referring to the inbound csv file and the output attachment referring to the output fixed-length file. Create the variable corresponding to the streaming context. You must populate this variable before making a call to the XPath function.

    Example - Creating the Variable for the Input Attachment

      <variables>
    <variable name="xlationContext" 
            element="client:streamingcontext"/>
    <variable name="inputAttachment"
            element="client:attachmentElement"/>
    <variable name="returnAttachment"
            element="client:attachmentElement"/>
  </variables>
 
 <!- - Assign the input and output attachments - ->
    <assign name="assignValuesForAttachments">
      <copy>
        <from expression="'/tmp/xpath/in/address.csv' "/>
        <to variable="inputAttachment" 
          query="/client:attachmentElement/@href"/>
      </copy>
      <copy>
        <from expression="
                '/tmp/xpath/out/address_fixedLength.txt' "/>
        <to variable="returnAttachment"
            query=
             "/client:attachmentElement/@href"/>
      </copy>
    </assign>
<!- - Assign the streaming context - ->
    <assign name="AssignStreamingContext">
      <copy>
        <from expression="'xsd/address-csv.xsd'"/>
        <to variable="xlationContext"
            query="/client:streamingcontext
                      /client:sourceSchema"/>
      </copy>
      <copy>
        <from expression="'Root-Element'"/>
        <to variable="xlationContext"
            query="/client:streamingcontext/
                    client:sourceRootElement"/>
      </copy>
      <copy>
        <from expression="'native'"/>
        <to variable="xlationContext"
            query="/client:streamingcontext/client:
                  sourceType"/>
      </copy>
      <copy>
        <from expression=
                  "'xsd/address-fixedLength.xsd'"/>
        <to variable="xlationContext"
            query="/client:streamingcontext/
                   client:targetSchema"/>
      </copy>
      <copy>
        <from expression="'Root-Element'"/>
        <to variable="xlationContext"
            query="/client:streamingcontext/client:
                   targetRootElement"/>
      </copy>
      <copy>
        <from expression="'native'"/>
        <to variable="xlationContext"
            query="/client:streamingcontext/client:
                   targetType"/>
      </copy>
      <copy>
        <from expression="'xsl/addr1Toaddr2.xsl'"/>
        <to variable="xlationContext"
            query="/client
                   :streamingcontext/client:xsl"/>
      </copy>
      <copy>
        <from expression="'10000'"/>
        <to variable="xlationContext"
            query="/client:streamingcontext/client:
                   batchSize"/>
      </copy>
    </assign>
<!- - call the XPath function - ->
    <assign name="executeStreamingXPath">
      <copy>
        <from expression=
                 "ora:doStreamingTranslate
           (bpws:getVariableData('inputAttachment',
               '/client:attachmentElement'),
           bpws:getVariableData('xlationContext'), 
                              'ATTACHMENT', 
               bpws:getVariableData('returnAttachment'))"/>
        <to variable="returnAttachment" 
                   query="/client:attachmentElement"/>
      </copy>
    </assign>

6.4 Use Cases for the Native Format Builder

This section describes the following use cases:

Note:

Sampling the data with multi-character delimiter in Native Format Builder is not supported currently. The same can be achieved through hand coding the NXSD with the appropriate Delimited By string.

6.4.1 Defining the Schema for a Delimited File Structure

A comma-separated value (CSV) file is a common non-XML file structure.

Use the Delimited option in the Native Format Builder wizard, when creating the XML schema for this native file.

The nxsd:headerLines="1" schema attribute signifies that the first line must be treated as a header row and skipped in the native data before actually translating the rest of the data. The nxsd:stream="chars" schema attribute signifies that the data should be read as characters. If nxsd:stream is set as bytes, nxsd:stream="bytes", then this schema attribute signifies that the native data should be read as bytes. For each of the element declarations, Name, Street, City, State, and Country, which have a corresponding scalar data, the nxsd:style="terminated" attribute defines that the corresponding data is stored in terminated style. The actual terminator is then defined by the nxsd:terminatedBy="," attribute specified at that construct. See Defining Terminated Data for details on the terminated style.

In this use case, the Native Format Builder uses a delimited sample file type that contains the address details, such as name, street, city, state, and country. Every element in this sample native file is delimited by a comma (,). You can generate the corresponding NXSD and also test it. Perform the following steps to run the use case:

  1. The data in a sample text file, address-csv.txt, is: 
    Name,Street1,Street2,City,State,Country
Oracle India Private Limited, Lexington Towers Prestige
            St. John's Woods, 2nd Cross Road Chikka Audugodi,
               Bangalore,Karnataka, India
Intel Technology India Private Limited, Survey #23-56 P Devarabeesanahalli Village, Outer Ring Road Varthur Hobli, Bangalore, Karnataka, India
  2. Navigate to the Adapter Configuration Wizard Messages page, as displayed in Figure 6-4, and click the Define Schema for Native Format button.

    Figure 6-4 Starting the Native Format Builder Wizard

    Description of Figure 6-4 follows
    Description of "Figure 6-4 Starting the Native Format Builder Wizard"

    The Native Format Builder Welcome page is displayed, as shown in Figure 6-5.

    Figure 6-5 Native Format Builder Wizard Welcome Page

    Description of Figure 6-5 follows
    Description of "Figure 6-5 Native Format Builder Wizard Welcome Page"
  3. Click Next. The Choose Type page is displayed, as shown in Figure 6-6.

    Figure 6-6 Native Format Builder Wizard Choose Type Page

    Description of Figure 6-6 follows
    Description of "Figure 6-6 Native Format Builder Wizard Choose Type Page"
  4. Click Next. The Native Format Builder File Description page is displayed.
  5. Click Browse and select the address-csv.txt file, as shown in Figure 6-7.

    Figure 6-7 Native Format Builder Wizard File Description Page

    Description of Figure 6-7 follows
    Description of "Figure 6-7 Native Format Builder Wizard File Description Page"
  6. Click Next. The Record Organization page is displayed, as shown in Figure 6-8.

    Figure 6-8 Native Format Builder Wizard Record Organization Page

    Description of Figure 6-8 follows
    Description of "Figure 6-8 Native Format Builder Wizard Record Organization Page"
  7. Select File contains multiple record instances, then select Multiple records are of single type, and then click Next. The Specify Elements page is displayed.
  8. Enter AddressBook in the Enter name of element containing multiple records field and enter Address in the Enter a name for element that represents record field, as shown in Figure 6-9.

    Figure 6-9 Native Format Builder Wizard Specify Elements Page

    Description of Figure 6-9 follows
    Description of "Figure 6-9 Native Format Builder Wizard Specify Elements Page"
  9. Click Next. The Specify Delimiters page is displayed, as shown in Figure 6-10. (For more information on Complex Lookahead strategies, see Defining Complex Look Ahead Strategies for Conditional Processing of Record Using Regular Expressions).

    Figure 6-10 Native Format Builder Wizard Specify Delimiters Page

    Description of Figure 6-10 follows
    Description of "Figure 6-10 Native Format Builder Wizard Specify Delimiters Page"
  10. Ensure that the Comma(,) option is selected in the Delimited By field, and click Next. The Field Properties page is displayed, as shown in Figure 6-11.

    Figure 6-11 Native Format Builder Wizard Field Properties Page

    Description of Figure 6-11 follows
    Description of "Figure 6-11 Native Format Builder Wizard Field Properties Page"
  11. Select Use the first record as the field names, then click Next. The Generated Native Format File page is displayed, as shown in Figure 6-12.

    Note:

    The first record is used as the field name, is also treated as a header record, and is skipped during translation.

    Figure 6-12 Native Format Builder Wizard Generated Native Format File Page

    Description of Figure 6-12 follows
    Description of "Figure 6-12 Native Format Builder Wizard Generated Native Format File Page"

    The corresponding native schema definition is as follows:

    <?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
            xmlns:tns="http://TargetNamespace.com/Read"
            targetNamespace="http://TargetNamespace.com/Read"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified"
            nxsd:version="NXSD"
            nxsd:stream="chars"
            nxsd:encoding="ASCII"
            nxsd:hasHeader="true"
            nxsd:headerLines="1"
            nxsd:headerLinesTerminatedBy="${eol}"
>
  <xsd:element name="AddressBook">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="Address" minOccurs="1"
              maxOccurs="unbounded">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="Name" 
                type="xsd:string"
                  nxsd:style="terminated" 
                  nxsd:terminatedBy=","
                  nxsd:quotedBy="&quot;" />
              <xsd:element name="Street1"
          type="xsd:string"
               nxsd:style="terminated" 
               nxsd:terminatedBy=","
               nxsd:quotedBy="&quot;" />
               <xsd:element name="Street2"
                 type="xsd:string"
               nxsd:style="terminated"
               nxsd:terminatedBy=","
               nxsd:quotedBy="&quot;" />
              <xsd:element name="City" type="xsd:string"
               nxsd:style="terminated"
               nxsd:terminatedBy=","
               nxsd:quotedBy="&quot;" />
              <xsd:element name="State"
                 type="xsd:string"
               nxsd:style="terminated"
               nxsd:terminatedBy=","
               nxsd:quotedBy="&quot;" />
              <xsd:element name="Country"
                  type="xsd:string"
               nxsd:style="terminated" 
               nxsd:terminatedBy="${eol}"
               nxsd:quotedBy="&quot;" />
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>
  12. Click Test. The Test NXSD Schema dialog is displayed, as shown in Figure 6-13.

    Figure 6-13 Test NXSD Schema Dialog

    Description of Figure 6-13 follows
    Description of "Figure 6-13 Test NXSD Schema Dialog"
  13. Click the Generate XML icon. The resultant XML is displayed on the Result XML pane of the Test NXSD Schema dialog, as shown in Figure 6-14.

    Figure 6-14 Test NXSD Schema Dialog

    Description of Figure 6-14 follows
    Description of "Figure 6-14 Test NXSD Schema Dialog"

    The native data using the corresponding native schema format is translated into the following XML:

    <?xml version = '1.0' encoding = 'UTF-8'?>
<AddressBook xmlns="http://TargetNamespace.com/ReadFile">
   <Address>
      <Name>Oracle India Private Limited</Name>
      <Street1> Lexington Towers Prestige St. John's Woods</Street1>
      <Street2> 2nd Cross Road Chikka Audugodi</Street2>
      <City> Bangalore</City>
      <State> Karnataka</State>
      <Country> India</Country>
   </Address>
   <Address>
      <Name>Intel Technology India Private Limited</Name>
      <Street1> Survey #23-56 P Devarabeesanahalli Village</Street1>
      <Street2> Outer Ring Road Varthur Hobli</Street2>
      <City> Bangalore</City>
      <State> Karnataka</State>
      <Country> India</Country>
   </Address>
</AddressBook>
  14. Click OK. The Generated Native Format Schema File page is displayed, as shown in Figure 6-12.
  15. Click Next. The Native Format Builder Finish page is displayed, as shown in Figure 6-15.

    Figure 6-15 Native Format Builder Wizard Finish Page

    Description of Figure 6-15 follows
    Description of "Figure 6-15 Native Format Builder Wizard Finish Page"
  16. Click Finish. The Adapter Configuration Wizard Messages page is displayed, as shown in Figure 6-16, containing the generated NXSD.

    Figure 6-16 Adapter Configuration Wizard Messages Page

    Description of Figure 6-16 follows
    Description of "Figure 6-16 Adapter Configuration Wizard Messages Page"

6.4.1.1 Defining a Asterisk (*) Separated Value File Structure

The use case defined in the previous example is just one specific case of the *SV class, where the wildcard can be substituted by any character or string. For example, for the native data containing a plus (+) separated value, substitute the wildcard with the plus (+) character.

Use the Delimited type option in the Native Format Builder wizard when creating the XML schema for this native file.

Native Data Format to Be Translated

The following native data format is provided:

a+b+c+d+e
f+g+h+i+j

Native Schema

The corresponding native schema definition is similar to the one in the previous use case except that instead of nxsd:terminatedBy="," you now define the terminated by format as nxsd:terminatedBy="+". See Defining Terminated Data for details about the terminated style.

6.4.2 Defining the Schema for a Fixed Length File Structure

In this example, the native data used is the same as in the CSV case, but the data used is of type fixed length and not CSV.

Use the Fixed Length option in the Native Format Builder wizard, to create the XML schema for this native file.

In this use case, the Native Format Builder uses a fixed-length file type called address that contains the address details such as name, street, city, state, and country. Every element in this address native file has a fixed length. You can generate the corresponding NXSD and also test it. Perform the following steps to run the use case:

  1. The data in a sample text file, address.txt, is: 
    Name                  Street    City      State     Country
ABC Private Limited   Street1   Bangalore Karnataka India
XYZ Private Limited   Street1   Bangalore Karnataka India
  2. Launch the Adapter Configuration Wizard and navigate to the Messages page, as displayed in Figure 6-4, and click Define Schema For Native Format. The Native Format Builder Welcome page is displayed, as shown in Figure 6-5.
  3. Click Next. The Choose Type page is displayed.
  4. Select Fixed Length as the file type, as shown in Figure 6-17.

    Figure 6-17 Native Format Builder Wizard Choose Type Page

    Description of Figure 6-17 follows
    Description of "Figure 6-17 Native Format Builder Wizard Choose Type Page"
  5. Click Next. The Native Format Builder File Description page is displayed.
  6. Click Browse and select the address.txt file, as displayed in Figure 6-18.

    Figure 6-18 Native Format Builder Wizard File Description Page

    Description of Figure 6-18 follows
    Description of "Figure 6-18 Native Format Builder Wizard File Description Page"
  7. Click Next. The Record Organization page is displayed, as shown in Figure 6-19.

    Figure 6-19 Native Format Builder Wizard Record Organization Page

    Description of Figure 6-19 follows
    Description of "Figure 6-19 Native Format Builder Wizard Record Organization Page"
  8. Select Multiple records are of single type, and click Next. The Specify Elements page is displayed.
  9. Enter AddressBook in the Enter name of element containing multiple records field, and enter Address in the Enter a name for element that represents record field, as shown in Figure 6-20.

    Figure 6-20 Native Format Builder Wizard Specify Elements Page

    Description of Figure 6-20 follows
    Description of "Figure 6-20 Native Format Builder Wizard Specify Elements Page"
  10. Click Next. The Field Lengths for Multiple Record Files page is displayed.
  11. Click the ruler at the desired position to mark fields on the sample text area, as shown in Figure 6-21 and click Next. The Field Properties page is displayed.

    Figure 6-21 Native Format Builder Wizard Field Lengths for Multiple Record Files Page

    Description of Figure 6-21 follows
    Description of "Figure 6-21 Native Format Builder Wizard Field Lengths for Multiple Record Files Page"
  12. Check Use the first record as the field names, as shown in Figure 6-22.

    Figure 6-22 Native Format Builder Wizard Field Properties Page

    Description of Figure 6-22 follows
    Description of "Figure 6-22 Native Format Builder Wizard Field Properties Page"
  13. Click Next. The Generated Native Format Schema File page is displayed, as shown in Figure 6-23.

    Figure 6-23 Native Format Builder Wizard Native Format Schema File Page

    Description of Figure 6-23 follows
    Description of "Figure 6-23 Native Format Builder Wizard Native Format Schema File Page"

    The corresponding native schema definition is similar to the definition of the CSV, file but style changes from nxsd:style="terminated" to nxsd:style="fixedLength" along with the relevant attributes for the fixed-length style. For the fixed-length style, the one mandatory attribute is the length: nxsd:length. The value of nxsd:length is the actual length of the data to be read.

    Example - Native Schema Definition Example with Fixed Length Style

    <?xml version="1.0" encoding="UTF-8" ?>
 
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
            xmlns:tns="http://TargetNamespace.com/FileIn_1"
            targetNamespace="http://TargetNamespace.com/FileIn_1"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified"
 
            nxsd:version="NXSD"
            nxsd:stream="chars"
            nxsd:encoding="ASCII"
            nxsd:hasHeader="true"
            nxsd:headerLines="1"
            nxsd:headerLinesTerminatedBy="${eol}"
 
  <xsd:element name="AddressBook">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="Address" minOccurs="1"
           maxOccurs="unbounded"
           nxsd:style="array"
           nxsd:cellSeparatedBy="${eol}">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="Name"
               type="xsd:string" 
               nxsd:style="fixedLength"
               nxsd:length="22" />
              <xsd:element name="Street" 
                type="xsd:string"
                nxsd:style="fixedLength"
                nxsd:length="8" />
              <xsd:element name="City"
               type="xsd:string" 
               nxsd:style="fixedLength" nxsd:length="12" />
              <xsd:element name="State" 
                type="xsd:string" nxsd:style="fixedLength" 
                           nxsd:length="10" />
              <xsd:element name="Country" type="xsd:string" nxsd:style="fixedLength" nxsd:length="7" />
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
 
</xsd:schema>
  14. Click Test. The Test NXSD Schema dialog is displayed, as shown in Figure 6-24.

    Figure 6-24 Test NXSD Schema Dialog

    Description of Figure 6-24 follows
    Description of "Figure 6-24 Test NXSD Schema Dialog"
  15. Click the Generate XML icon. The resultant XML is displayed on the Result XML pane of the Test NXSD Schema dialog, as shown in Figure 6-25.

    Figure 6-25 Test NXSD Schema Dialog

    Description of Figure 6-25 follows
    Description of "Figure 6-25 Test NXSD Schema Dialog"

    The native data using the corresponding native schema format is translated into XML as shown in the following example.

    Example - The Native Data Using the Native Schema FormatTranslated XML

    <?xml version = '1.0' encoding = 'UTF-8'?>
<AddressBook xmlns="http://TargetNamespace.com/Read">
   <Address>
      <Name>ABC Private Limited</Name>
      <Street>Street1  </Street>
      <City> Bangalore </City>
      <State>Karnataka </State>
      <Country>India</Country>
   </Address>
   <Address>
      <Name>XYZ Private Limited</Name>
      <Street>Street1  </Street>
      <City> Bangalore </City>
      <State>Karnataka </State>
      <Country>India </Country>
   </Address>
</AddressBook>
  16. Click OK. The Generated Native Format File page is displayed, as shown in Figure 6-23.
  17. Click Next. The Native Format Builder Finish page is displayed, as shown in Figure 6-15.
  18. Click Finish. The Adapter Configuration Wizard Messages page is displayed, as shown in Figure 6-16, that contains the generated NXSD.

6.4.3 Defining the Schema for a Complex File Structure

The file structure of an invoice is more complex than the structure of CSV, *SV, and fixed-length files discussed in the preceding use cases. An invoice usually contains buyer information, seller information, and line items. Each of these elements, in turn, can be of complex type. For example, the buyer element can be defined as a partner-type, where partner-type consists of three elements - id, name, and address.

Use the Complex Type option in the Native Format Builder wizard when creating the XML schema for this native file.

In this use case, the Native Format Builder uses invoice.txt, a complex file type called invoice, which contains multiple records such as buyer, seller, and items. Also, using this use case, you can generate the NXSD and test it. Perform the following steps to run this use case:

  1. The data in a sample text file, invoice.txt, is:

    6335722^Company OnêFirst Street   999       San Jose       95129USCA650-801-6250
 ^OraclêBridge Parkway 1600      Redwood Shores 94065USCA650-506-7000
001|BPEL Process Manager Enterprise Edition|20000,2,+40000+
002|BPEL Process Manager Standard Edition|10000,5,+50000+
003|BPEL Process Manager Developer Edition|1000,20,+20000+#110000

  2. Launch the Adapter Configuration Wizard and navigate to the Messages page, as displayed in Figure 6-4, and click Define Schema For Native Format. The Native Format Builder Welcome page is displayed, as shown in Figure 6-5.

  3. Click Next. The Choose Type page is displayed, as shown in Figure 6-26.

    Figure 6-26 Native Format Builder Wizard Choose Type Page

    Description of Figure 6-26 follows
    Description of "Figure 6-26 Native Format Builder Wizard Choose Type Page"

  4. Select Complex Type (Contains records whose fields may themselves be records having multiple delimiter types).

  5. Click Next. The Native Format Builder File Description page is displayed.

  6. Click Browse and select the invoice.txt file, and enter Invoice in the Root Element field, as displayed in Figure 6-27.

    Figure 6-27 Native Format Builder Wizard File Description Page

    Description of Figure 6-27 follows
    Description of "Figure 6-27 Native Format Builder Wizard File Description Page"

  7. Click Next. The Native Format Builder Design Schema is displayed, as shown in Figure 6-28.

    Figure 6-28 Native Format Builder Wizard Design Schema Page

    Description of Figure 6-28 follows
    Description of "Figure 6-28 Native Format Builder Wizard Design Schema Page"

Create the partner-type Complex Type

The schema structure that you can build using the invoice.txt sample is as follows:

Invoice

Buyer => partner-type

Seller => partner-type

Items => item-type

Invoice-total => double

The first line in the native data consists of buyer details, followed by seller details, followed by line items, and finally the total for the line items. Both buyer and seller elements have the same complex structure, as follows:

  • The first seven characters are the UID

  • This is followed by the buyer/seller name surrounded by " ^".

  • This is followed by the address until the end of the line.

To create this in the Native Format Builder:

  1. Click the Add Complex Type icon. A Complex Type, <new_complex_type> is created in the Schema Tree under Invoice, as shown in Figure 6-29.

    Figure 6-29 Native Format Builder Wizard Design Schema Page

    Description of Figure 6-29 follows
    Description of "Figure 6-29 Native Format Builder Wizard Design Schema Page"

  2. Select the first row of the sample text from the right-hand pane of the Sample File section, and drag and drop it on the <new_complex_type> node. The Complex Type Details dialog is displayed.

  3. Enter partner-type in the Complex Type Name field, as shown in Figure 6-30.

    Figure 6-30 Native Format Builder Wizard Design Schema Page - Complex Type Details Dialog

    Description of Figure 6-30 follows
    Description of "Figure 6-30 Native Format Builder Wizard Design Schema Page - Complex Type Details Dialog"

  4. Click the ruler at the desired position to mark fields on the sample text area, and then click the Generate Fields button. The system interprets the style of data for the defined fields.

    Note:

    For the Fixed Length or Mixed Delimiter type options, a ruler-based text area is displayed. You have to use the rulers to identify fields within the sample text. In case of delimited data, select or enter the appropriate delimiter in the Delimited By field.

  5. Enter the id, name, and address in the Name field, as shown in Figure 6-31.

    Figure 6-31 Complex Type Details Dialog

    Description of Figure 6-31 follows
    Description of "Figure 6-31 Complex Type Details Dialog"

  6. Click the pencil icon adjacent to each field to display the corresponding Edit Field Details dialog that enables you to edit the field properties. For example, click the pencil icon adjacent to the Name field. The Edit Field Details dialog is displayed, as shown in Figure 6-32.

    Figure 6-32 Edit Field Details Dialog

    Description of Figure 6-32 follows
    Description of "Figure 6-32 Edit Field Details Dialog"

  7. Edit the following field properties, as shown in Figure 6-32.

    • Type: The data type of the sample text. Select String from the Type list.

    • Style: Represents the style of the complex type element. You can select any of the following four options:

      • fixed length

      • surrounded

      • terminated

      • left/right surrounded

      In this example, select surrounded.

    • Surrounded By: This option is displayed when you select surrounded in the Style option. In this example, enter caret (^) in the Surrounded By field.

    The field properties displayed on this panel correspond to the NXSD attributes used in the schema.

  8. Click OK. The Complex Type Details dialog is displayed with the field properties that you selected.

  9. Verify or edit the field properties for id and address Name fields.

  10. Click OK in the Complex Type Details dialog. The Native Format Builder Design Schema page is displayed, as shown in Figure 6-33.

    Figure 6-33 Native Format Builder Wizard Design Schema Page - partner-type Complex Type

    Description of Figure 6-33 follows
    Description of "Figure 6-33 Native Format Builder Wizard Design Schema Page - partner-type Complex Type"

Create an address-type Complex Type

The address element can be further defined as another complex-type that contains a fixed-length street, city, and additional fields.

To do so:

  1. Create another <noncompliant> node in the Schema Tree. See Step 1 in Create the partner-type Complex Type.

  2. Drag and drop the address part in the first row of the sample text to the Complex Type, <noncompliant>. The Complex Type Details dialog is displayed.

  3. Enter address-type in the Complex Type Name field.

  4. Click the ruler to mark fields on the sample text area, and then click the Generate Fields button. Now, enter street1, street2, city, zip, country, state, and phone in the Name field, as shown in Figure 6-34.

    Figure 6-34 Native Format Builder Wizard Design Schema Page - Complex Type Details Dialog

    Description of Figure 6-34 follows
    Description of "Figure 6-34 Native Format Builder Wizard Design Schema Page - Complex Type Details Dialog"

  5. Click OK. The Native Format Builder Design Schema page is displayed, as shown in Figure 6-35.

    Figure 6-35 Native Format Builder Wizard Design Schema Page

    Description of Figure 6-35 follows
    Description of "Figure 6-35 Native Format Builder Wizard Design Schema Page"

Assign the address-type Complex Type to the address field of partner-type Complex Type

You must assign the address-type complex type to the address field of the partner-type complex type. You can assign a complex type to an element by using one of the following methods:

    • Drag and drop the address-type node on the address field node of the partner-type complex type. This instantly assigns address-type to the address field element, or

    • Select the address field node of the partner-type complex type and then click the pencil icon.

      The Edit Field Details dialog is displayed, as shown in Figure 6-36.

    Figure 6-36 Edit Field Details Dialog

    Description of Figure 6-36 follows
    Description of "Figure 6-36 Edit Field Details Dialog"

  2. Select the address-type option in the Type list, and click OK. The address-type option is assigned to the address field element in the Native Format Builder Design Schema page, as shown in Figure 6-37.

    Figure 6-37 Native Format Builder Wizard Design Schema Page

    Description of Figure 6-37 follows
    Description of "Figure 6-37 Native Format Builder Wizard Design Schema Page"

Create 'buyer' and 'seller' Global Elements

  1. Select Invoice, and click the Add Element icon. An element, <new_element>, is created in the Schema Tree under the root element, Invoice.

  2. Rename it to buyer.

  3. Again, select Invoice, and click the Add Element icon. An element, <new_element>, is created in the Schema Tree under Invoice.

  4. Rename it to seller.

    Drag and drop the partner-type node on each of the buyer and seller nodes, to assign the partner-type complex type to these nodes. The Schema Tree appears, as shown in Figure 6-38.

    Figure 6-38 Native Format Builder Wizard Design Schema Page

    Description of Figure 6-38 follows
    Description of "Figure 6-38 Native Format Builder Wizard Design Schema Page"

Create item-type Complex Type, and items and invoice-total Element Nodes

The items element can be considered an array of item-types. The last line item in the native file ends with the number sign (#), followed by the line-item total.

  1. Select Invoice, and click the Add Element icon. An element, <new_element>, is created in the Schema Tree under Invoice.

  2. Rename it to items.

  3. Create the item-type complex type and define the field properties, as shown in Figure 6-39.

    Figure 6-39 Native Format Builder Wizard Design Schema Page

    Description of Figure 6-39 follows
    Description of "Figure 6-39 Native Format Builder Wizard Design Schema Page"

  4. Drag and drop item-type complex type to the items element to assign item-type to this element.

  5. Select items - item-type and click the pencil icon. The Element Details dialog is displayed.

    Figure 6-40 Element Details Dialog

    Description of Figure 6-40 follows
    Description of "Figure 6-40 Element Details Dialog"

  6. Set the following properties in the Element Details dialog, as shown in Figure 6-40:

    1. Set Max. Occurrence - UNBOUNDED

    2. Select Array. The Cell Separator and Array Separator are enabled.

    3. Set Cell Separator - ${eol}

    4. Set Array Separator - #

    Note:

    The element items is defined as an array of item-type.

  7. Click OK.

  8. Create the invoice-total element, and drag and drop the sample text (110000) on the <new_element> node. The Element Details dialog is displayed.

  9. Enter invoice-total in the Element Name field, and click Generate Fields. The Alert message is displayed, as shown in Figure 6-41.

    Figure 6-41 Element Details Dialog - Alert Message

    Description of Figure 6-41 follows
    Description of "Figure 6-41 Element Details Dialog - Alert Message"

    If a single field is identified in the sampled data for a global element, then the properties of this data are applied to the global element itself.

  10. Click OK in the Alert message. The Element Details dialog is displayed.

  11. Select double in the Data Type list, and click OK. The Native Format Builder Design Schema page is displayed, as shown in Figure 6-42.

    Figure 6-42 Native Format Builder Wizard Design Schema Page - Complete Schema Tree

    Description of Figure 6-42 follows
    Description of "Figure 6-42 Native Format Builder Wizard Design Schema Page - Complete Schema Tree"

  12. Click Next. The Generated Native Format Schema File page is displayed, as shown in Figure 6-43, which displays the native format file.

    Figure 6-43 Native Format Builder Wizard Generated Native Format File Page

    Description of Figure 6-43 follows
    Description of "Figure 6-43 Native Format Builder Wizard Generated Native Format File Page"

    The native schema definition corresponding to the preceding native data can be defined as follows:

    Example - Native Schema Definition

    <schema attributeFormDefault="qualified"
         elementFormDefault="qualified" 
                targetNamespace=
                "http://xmlns.oracle.com/ias/pcbpel
                 /fatransschema/demo"
                xmlns:tns="http://xmlns.oracle.com
                               /ias/pcbpel/
                          fatransschema/demo"
                xmlns="http://www.w3.org/2001/XMLSchema" 
                xmlns:nxsd="http://xmlns.oracle.com/pcbpel/
                                          nxsd" 
              nxsd:version="NXSD" nxsd:stream="chars">
 
    <element name="invoice" type="tns:invoiceType" />
 
    <complexType name="invoiceType"> 
       <sequence>
          <element name="purchaser" 
                         type="tns:partnerType" />
          <element name="seller" 
                         type="tns:partnerType" />
          <element name="line-item" 
                        type="tns:line-itemType" 
              maxOccurs="unbounded" nxsd:style="array" 
                nxsd:cellSeparatedBy="${eol}"
                nxsd:arrayTerminatedBy="#"/>
          <element name="total" type="double"
                nxsd:style="terminated"
                nxsd:terminatedBy="${eol}"/>
       </sequence>
    </complexType>
 
    <complexType name="partnerType"> 
       <sequence>
          <element name="uid" type="string"
             nxsd:style="fixedLength"
             nxsd:length="7" nxsd:padStyle="tail" 
             nxsd:paddedBy=" "/> 
          <element name="name" type="string" 
             nxsd:style="surrounded"
             nxsd:surroundedBy="^"/>        
          <element name="address"
                   type="tns:addressType" />
       </sequence>
    </complexType>  
       
 
    <complexType name="addressType"> 
       <sequence>
          <element name="street1"
                            type="string"
             nxsd:style="fixedLength"
             nxsd:length="15" 
                     nxsd:padStyle="tail" 
             nxsd:paddedBy=" "/>
          <element name="street2" type="string" 
             nxsd:style="fixedLength"
             nxsd:length="10"
                      nxsd:padStyle="tail"
             nxsd:paddedBy=" "/>
          <element name="city" type="string" 
             nxsd:style="fixedLength"
             nxsd:length="15" nxsd:padStyle="tail"
             nxsd:paddedBy=" "/>
          <element name="postal-code" type="string"
             nxsd:style="fixedLength"
             nxsd:length="5" 
             nxsd:padStyle="none"/>
          <element name="country" type="string" 
             nxsd:style="fixedLength"
             nxsd:length="2"
                       nxsd:padStyle="none"/>
          <element name="state" type="string"
             nxsd:style="fixedLength"
             nxsd:length="2" nxsd:padStyle="none"/>
          <element name="phone" type="string"
             nxsd:style="terminated"
             nxsd:terminatedBy="${eol}"/>
       </sequence>
    </complexType>
 
    <complexType name="line-itemType"> 
       <sequence>
          <element name="uid" type="string"
             nxsd:style="fixedLength"
             nxsd:length="3" nxsd:padStyle="none"/>     
          <element name="description" type="string"
             nxsd:style="surrounded"
             nxsd:surroundedBy="|"/>
          <element name="price" type="double"
             nxsd:style="terminated"
               nxsd:terminatedBy=","/>
          <element name="quantity" type="integer"
               nxsd:style="terminated"
               nxsd:terminatedBy=","/>
          <element name="line-total" type="double"
               nxsd:style="surrounded"
               nxsd:surroundedBy="+"/>
       </sequence>
    </complexType>
 
</schema>

  13. Click Test. The Test NXSD Schema dialog is displayed, as shown in Figure 6-44.

    Figure 6-44 Test NXSD Schema Dialog

    Description of Figure 6-44 follows
    Description of "Figure 6-44 Test NXSD Schema Dialog"

  14. Click the Generate XML icon. The Result XML is displayed on the right pane of the Test NXSD Schema dialog, as shown in Figure 6-45.

    Figure 6-45 Test NXSD Schema Dialog - Result XML

    Description of Figure 6-45 follows
    Description of "Figure 6-45 Test NXSD Schema Dialog - Result XML"

    The translated XML is shown in the following example.

    Example - Translated XML

    <invoice xmlns="http://xmlns.oracle.com/pcbpel/
                 demoSchema/invoice-nxsd">
  <purchaser>
    <uid>6335722</uid>
    <name>Company One</name>
    <address>
      <street1>First Street</street1>
      <street2>999</street2>
      <city>San Jose</city>
      <postal-code>95129</postal-code>
      <country>US</country>
      <state>CA</state>
      <phone>650-801-6250</phone>
    </address>
  </purchaser>
  <seller>
    <uid/>
    <name>Oracle</name>
    <address>
      <street1>Bridge Parkway</street1>
      <street2>1600</street2>
      <city>Redwood Shores</city>
      <postal-code>94065</postal-code>
      <country>US</country>
      <state>CA</state>
      <phone>650-506-7000</phone>
    </address>
  </seller>
  <line-item>
    <uid>001</uid>
    <description>BPEL Process Manager Enterprise
                Edition</description>
    <price>20000</price>
    <quantity>2</quantity>
    <line-total>40000</line-total>
  </line-item>
  <line-item>
    <uid>002</uid>
    <description>BPEL Process Manager Standard
                  Edition</description>
    <price>10000</price>
    <quantity>5</quantity>
    <line-total>50000</line-total>
  </line-item>
  <line-item>
    <uid>003</uid>
    <description>BPEL Process Manager Developer
                  Edition</description>
    <price>1000</price>
    <quantity>20</quantity>
    <line-total>20000</line-total>
  </line-item>
  <total>110000</total>
</invoice>

  15. Click OK. The Generated Native Format File page is displayed, as shown in Figure 6-43.

  16. Click Next. The Native Format Builder Finish page is displayed, as shown in Figure 6-15.

  17. Click Finish. The Adapter Configuration Wizard Messages page is displayed, containing the generated NXSD, as shown in Figure 6-16.

6.4.4 Removing or Adding Namespaces to XML with No Namespace

When the native data is XML and that XML has no namespace, you can use the Native Format Translator to add a namespace to an inbound XML document and remove the namespace from an outbound XML document.

The XML has no namespace when either of the following is true:

  • The XML has a corresponding XML schema, and there is no target namespace specified in that XML schema.

  • The XML has a corresponding DTD, which was converted to the XML schema.

In both cases, you must create a wrapper schema with targetNamespace specified, and the wrapper schema must include the actual schema. In addition, the wrapper schema must also have the nxsd:version attribute set to DTD. For example:

--wrapper.xsd
<?xml version="1.0" encoding="UTF-8"?> 
<schema xmlns="http://www.w3.org/2001/XMLSchema"
   targetNamespace="myNamespace"
   xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
   nxsd:version="DTD">
   <include schemaLocation="actual.xsd"/>
</schema>

Note:

Ensure that elementFormDefault="qualified" is specified in the actual schema.

Using this wrapper.xsd file for the original .xsd file would add the myNamespace namespace to the inbound XML and would remove the myNamespace namespace from the outbound XML.

6.4.5 Defining the Choice Condition Schema for a Complex File Structure

In this use case, the Native Format Builder uses order.txt, a complex type file, which contains multiple record types such as order, customer, and items. Also, using this use case you can generate the NXSD and test it. Perform the following steps to run this use case:

  1. The data in a sample text file, order.txt, is: 
    Order, ID41678, 20May2000
Item1, GigaWidget, 60, $75
Item2, MegaBucket, 48, $125
Cust1, Hopkins Associates, ID26490
Order, ID41680, 20May2000
Item3, Rt.Clopper, 40, $100
Item4, Lt.Clopper, 50, $100
Cust2, Jersey WebInovaters, ID46786
  2. Create the following complex types by dragging one row each of order, customer, and item native data:

    • OrderType

    • ItemType

    • CustomerType

    For more information about creating a complex type, see Defining the Schema for a Complex File Structure.

    The Native Format Builder Design Schema page is displayed, as shown in Figure 6-46.

    Figure 6-46 Native Format Builder Design Schema Page

    Description of Figure 6-46 follows
    Description of "Figure 6-46 Native Format Builder Design Schema Page"
  3. Click Add Choice Node. The Choice Option Type dialog is displayed.
  4. Set the options in the Choice Option Type dialog, as shown in Figure 6-47, and then click OK.

    Figure 6-47 The Choice Option Type Dialog

    Description of Figure 6-47 follows
    Description of "Figure 6-47 The Choice Option Type Dialog"
  5. Select choice and click the Add Element icon. A <new_element> is added to the choice node.
  6. Rename the newly added element to OrderChoice, and then drag and drop the OrderType complex type element to OrderChoice.
  7. Select OrderChoice - string and click the Edit Node icon. The Element Details dialog is displayed.
  8. Enter Order in the Choice Value field, as shown in Figure 6-48, and then click OK.

    Note:

    You should specify four characters in Choice Value field as the Length field has the value 4 in it.

    Figure 6-48 The Element Details Dialog

    Description of Figure 6-48 follows
    Description of "Figure 6-48 The Element Details Dialog"
  9. Follow Step 5 to 8 to create the ItemChoice choice complex type with ItemType data type and CustomerChoice choice complex type with CustomerType data type. The Native Format Builder Design Schema dialog is displayed, as shown in Figure 6-49.

    Figure 6-49 Native Format Builder Design Schema Page

    Description of Figure 6-49 follows
    Description of "Figure 6-49 Native Format Builder Design Schema Page"
  10. Click Next. The Generated Native Format Schema File page is displayed, as shown in Figure 6-50, which displays the native format file.

    Figure 6-50 Generated Native Format Schema File Page

    Description of Figure 6-50 follows
    Description of "Figure 6-50 Generated Native Format Schema File Page"

    Native Schema

    The native schema definition corresponding to the preceding native data can be defined in the following example.

    Example - Native Schema Definition

    <?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:nxsd=
             "http://xmlns.oracle.com/pcbpel/nxsd"
            xmlns:tns="http://TargetNamespace.com/test"
            targetNamespace=
                   "http://TargetNamespace.com/test"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified"
            nxsd:version="NXSD"
            nxsd:stream="chars"
            nxsd:encoding="ASCII"
>
  <xsd:element name="Root-Element">
    <xsd:complexType>
      <xsd:choice minOccurs="1" 
                    maxOccurs="unbounded"
 nxsd:choiceCondition="fixedLength" 
                      nxsd:length="4">
        <xsd:element name="OrderChoice"
             type="tns:OrderType"
 nxsd:conditionValue="Orde" />
        <xsd:element name="ItemChoice"
              type="tns:ItemType"
 nxsd:conditionValue="Item" />
        <xsd:element name="CustomerChoice" 
             type="tns:customerType"
 nxsd:conditionValue="Cust" />
      </xsd:choice>
    </xsd:complexType>
  </xsd:element>
  <xsd:complexType name="customerType">
    <xsd:sequence>
      <xsd:element name="C1" 
                       type="xsd:string" 
           nxsd:style="terminated"
 nxsd:terminatedBy="," />
      <xsd:element name="C2" type="xsd:string" 
           nxsd:style="terminated"
 nxsd:terminatedBy="," />
      <xsd:element name="C3" type="xsd:string" 
           nxsd:style="terminated"
 nxsd:terminatedBy="${eol}" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:complexType name="ItemType">
    <xsd:sequence>
      <xsd:element name="C1" 
            type="xsd:string"
            nxsd:style="terminated"
 nxsd:terminatedBy="," />
      <xsd:element name="C2" 
                        type="xsd:string"
            nxsd:style="terminated"
 nxsd:terminatedBy="," />
      <xsd:element name="C3" 
                      type="xsd:string"
            nxsd:style="terminated"
 nxsd:terminatedBy="," />
      <xsd:element name="C4" 
                     type="xsd:string"
        nxsd:style="terminated"
 nxsd:terminatedBy="${eol}" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:complexType name="OrderType">
    <xsd:sequence>
      <xsd:element name="C1" type="xsd:string"
            nxsd:style="terminated"
 nxsd:terminatedBy="," />
      <xsd:element name="C2" type="xsd:string"
            nxsd:style="terminated"
 nxsd:terminatedBy="," />
      <xsd:element name="C3" type="xsd:string"
            nxsd:style="terminated"
 nxsd:terminatedBy="${eol}" />
    </xsd:sequence>
  </xsd:complexType>
</xsd:schema>
  11. Click Test. The Test NXSD Schema dialog is displayed.
  12. Click the Generate XML icon. The Result XML is displayed on the right pane of the Test NXSD Schema dialog, as shown in Figure 6-51.

    Figure 6-51 Test NXSD Schema Dialog

    Description of Figure 6-51 follows
    Description of "Figure 6-51 Test NXSD Schema Dialog"

    Translated XML Using the Native Schema

    The translated XML is shown in the example below.

    Example - Translated XML Using the Native Schema

    <?xml version = '1.0' encoding = 'UTF-8'?>
<Root-Element xmlns="http://TargetNamespace.com/test">
   <OrderChoice>
      <C1>r</C1>
      <C2> ID41678</C2>
      <C3> 20May2000</C3>
   </OrderChoice>
   <ItemChoice>
      <C1>1</C1>
      <C2> GigaWidget</C2>
      <C3> 60</C3>
      <C4> $75</C4>
   </ItemChoice>
   <ItemChoice>
      <C1>2</C1>
      <C2> MegaBucket</C2>
      <C3> 48</C3>
      <C4> $125</C4>
   </ItemChoice>
   <CustomerChoice>
      <C1>1</C1>
      <C2> Hopkins Associates</C2>
      <C3> ID26490</C3>
   </CustomerChoice>
   <OrderChoice>
      <C1>r</C1>
      <C2> ID41680</C2>
      <C3> 20May2000</C3>
   </OrderChoice>
   <ItemChoice>
      <C1>3</C1>
      <C2> Rt.Clopper</C2>
      <C3> 40</C3>
      <C4> $100</C4>
   </ItemChoice>
   <ItemChoice>
      <C1>4</C1>
      <C2> Lt.Clopper</C2>
      <C3> 50</C3>
      <C4> $100</C4>
   </ItemChoice>
   <CustomerChoice>
      <C1>2</C1>
      <C2> Jersey WebInovaters</C2>
      <C3> ID46786</C3>
   </CustomerChoice>
</Root-Element>
  13. Click OK. The Generated Native Format File page is displayed.
  14. Click Next. The Native Format Builder Finish page is displayed.

6.4.6 Defining Choice Condition With LookAhead for a Complex File Structure

In this use case, the Native Format Builder uses address.txt, a complex type file, which contains multiple records with different addresses. In this use case, you would build a schema which has 2 record types. The RecOne record takes data for records ending with text "YES" and the RecTwo record takes data for records ending with text "NO ".

Also, using this use case you can generate the NXSD and test it.

Perform the following steps to run this use case:

  1. The data in a sample text file, address.txt is: 
    Name1,"2 Old Street, Old Town,Manchester",20-08-1954,"0161-499-1718", YES
Name2,"2 Old Street, Old Town,Manchester",20-08-1954,"0161-499-1718", NO 
Name3,"2 Old Street, Old Town,Manchester",20-08-1954,"0161-499-1718", NO 
Name4,"2 Old Street, Old Town,Manchester",20-08-1954,"0161-499-1718", YES
  2. Launch the Adapter Configuration Wizard and navigate to the Messages page, and click Define Schema For Native Format. The Native Format Builder Welcome page is displayed.
  3. Click Next. The Choose Type page is displayed.
  4. Select Complex Type and click Next. The Native Format Builder File Description page is displayed.
  5. Click Browse and select the address.txt file, and enter Address in the Root Element field.
  6. Click Next. The Native Format Builder Design Schema page is displayed.
  7. Click the Add Complex Type icon. A Complex Type, <new_complex_type> is created in the Schema Tree under Address.
  8. Select the first row of the sample text from the right-hand pane of the Sample File section, and drag and drop it on the <new_complex_type> node. The Complex Type Details dialog is displayed.
  9. Enter RECORD1 in the Complex Type Name field and select Comma (,) in the Delimited By list.
  10. Click OK. The Native Format Builder Design Schema page is displayed, as shown in Figure 6-52.

    Figure 6-52 Native Format Builder Design Schema Page

    Description of Figure 6-52 follows
    Description of "Figure 6-52 Native Format Builder Design Schema Page"
  11. Similarly, create another complex type node called RECORD2. The Native Format Builder Design Schema page is displayed, as shown in Figure 6-53.

    Figure 6-53 Native Format Builder Design Schema Page

    Description of Figure 6-53 follows
    Description of "Figure 6-53 Native Format Builder Design Schema Page"
  12. Click Add Choice Node. The Choice Option Type dialog is displayed.
  13. Set the options in the Choice Option Type dialog, as shown in Figure 6-54, and then click OK.

    Figure 6-54 The Choice Option Type Dialog

    Description of Figure 6-54 follows
    Description of "Figure 6-54 The Choice Option Type Dialog"
  14. Select choice and click the Add Element icon. A <new_element> is added to the choice node.
  15. Click the Edit Node icon. The Element Details dialog is displayed.
  16. Enter RECONE in the Element Name field and select RECORD1 as the Data Type set choice condition as YES, and then click OK.
  17. Follow Step 14 to 16 to create the RECTWO choice element for the choice node and set choice condition as NO.

    Note:

    There is one space after characters NO, because you must match the total number of characters to three.

    The Native Format Builder Design Schema dialog is displayed, as shown in Figure 6-55.

    Figure 6-55 Native Format Builder Design Schema Page

    Description of Figure 6-55 follows
    Description of "Figure 6-55 Native Format Builder Design Schema Page"
  18. Drag and drop the RECORD1 complex type to the RECONE element under choice and the RECORD2 complex type to the RECTWO element under choice. The Native Format Builder Design Schema dialog is displayed.
  19. Click Next. The Generated Native Format Schema File page is displayed, as shown in Figure 6-56, which displays the native format file.

    Figure 6-56 Generated Native Format Schema File Page

    Description of Figure 6-56 follows
    Description of "Figure 6-56 Generated Native Format Schema File Page"

    Native Schema

    The native schema definition corresponding to the preceding native data can be defined as follows:

    Example - Native Schema for Defining Choice Condition With LookAhead for a Complex File Structure

    <?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd=
                   "http://www.w3.org/2001/XMLSchema"
            xmlns:nxsd=
                   "http://xmlns.oracle.com/pcbpel/nxsd"
            xmlns:tns="http://TargetNamespace.com/tesNew"
            targetNamespace=
                   "http://TargetNamespace.com/tesNew"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified"
            nxsd:version="NXSD"
            nxsd:stream="chars"
            nxsd:encoding="ASCII"
>
  <xsd:element name="Root-Element">
    <xsd:complexType>
      <xsd:choice minOccurs="1"
                 maxOccurs="unbounded"
 nxsd:choiceCondition="${X}" nxsd:lookAhead="70"
 nxsd:scanLength="3"
 nxsd:assignTo="${X}">
        <xsd:element name="RECTWO" 
         type="tns:RECORD2"
              nxsd:conditionValue="NO "
 />
        <xsd:element name="RECONE" 
         type="tns:RECORD1"
           nxsd:conditionValue="YES"
 />
      </xsd:choice>
    </xsd:complexType>
  </xsd:element>
  <xsd:complexType name="RECORD2">
    <xsd:sequence>
      <xsd:element name="C1" 
          type="xsd:string"
       nxsd:style="terminated"
       nxsd:terminatedBy="," />
      <xsd:element name="C2" 
           type="xsd:string" 
       nxsd:style="terminated"
       nxsd:terminatedBy="," />
      <xsd:element name="C3"
               type="xsd:string"
       nxsd:style="terminated"
       nxsd:terminatedBy="," />
      <xsd:element name="C4" 
                  type="xsd:string"
       nxsd:style="terminated"
       nxsd:terminatedBy="," />
      <xsd:element name="C5" 
                  type="xsd:string"
       nxsd:style="terminated"
       nxsd:terminatedBy="${eol}" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:complexType name="RECORD1">
    <xsd:sequence>
      <xsd:element name="C1" 
                   type="xsd:string"
        nxsd:style="terminated"
        nxsd:terminatedBy="," />
      <xsd:element name="C2"
                 type="xsd:string" 
        nxsd:style="terminated"
        nxsd:terminatedBy="," />
      <xsd:element name="C3" 
                  type="xsd:string" 
        nxsd:style="terminated"
        nxsd:terminatedBy="," />
      <xsd:element name="C4" 
                      type="xsd:string" 
        nxsd:style="terminated"
        nxsd:terminatedBy="," />
      <xsd:element name="C5"
                    type="xsd:string" 
        nxsd:style="terminated"
        nxsd:terminatedBy="${eol}" />
    </xsd:sequence>
  </xsd:complexType>
</xsd:schema>
  20. Click Test. The Test NXSD Schema dialog is displayed.
  21. Click the Generate XML icon. The Result XML is displayed on the right pane of the Test NXSD Schema dialog, as shown in Figure 6-57.

    Figure 6-57 Test NXSD Schema Dialog

    Description of Figure 6-57 follows
    Description of "Figure 6-57 Test NXSD Schema Dialog"

    Translated XML Using the Native Schema

    The translated XML is shown in the example below.

    Example - Translated XML Using the Native Schema

    <?xml version = '1.0' encoding = 'UTF-8'?>
<Root-Element xmlns="http://TargetNamespace.com/tesNew">
   <RECONE>
      <C1>Name1</C1>
      <C2>2 Old Street, Old Town,Manchester</C2>
      <C3>20-08-1954</C3>
      <C4>0161-499-1718</C4>
      <C5> YES</C5>
   </RECONE>
   <RECTWO>
      <C1>Name2</C1>
      <C2>2 Old Street, Old Town,Manchester</C2>
      <C3>20-08-1954</C3>
      <C4>0161-499-1718</C4>
      <C5> NO </C5>
   </RECTWO>
   <RECTWO>
      <C1>Name3</C1>
      <C2>2 Old Street, Old Town,Manchester</C2>
      <C3>20-08-1954</C3>
      <C4>0161-499-1718</C4>
      <C5> NO </C5>
   </RECTWO>
   <RECONE>
      <C1>Name4</C1>
      <C2>2 Old Street, Old Town,Manchester</C2>
      <C3>20-08-1954</C3>
      <C4>0161-499-1718</C4>
      <C5> YES</C5>
   </RECONE>
</Root-Element>

    Note:

    There are 2 recordtypes: RECONE and RECTWO. RECONE takes records that end with character YES and RECTWO takes records that end with character NO.

  22. Click OK. The Generated Native Format File page is displayed.
  23. Click Next. The Native Format Builder Finish page is displayed.

6.4.7 Defining Array Type Schema for a Complex File Structure

In this use case, the Native Format Builder uses array.txt, a complex type file, which contains an array of items. The sample data has four names which are separated by a semicolon and ending with a period. In this use case, you would create a schema with array type which has member names separated by a semicolon and array terminated by a period. Also, using this use case you can generate the NXSD and test it.

Perform the following steps to run this use case:

  1. The data in a sample text file, array.txt, is: 
    John;Steve;Paul;Todd.
  2. Launch the Adapter Configuration Wizard and navigate to the Messages page and click Define Schema For Native Format. The Native Format Builder Welcome page is displayed.
  3. Click Next. The Choose Type page is displayed.
  4. Select Complex Type and click Next. The Native Format Builder File Description page is displayed.
  5. Click Browse and select the array.txt file, as shown in Figure 6-58. The Native Format Builder File Description page is displayed.

    Figure 6-58 Native Format Builder File Description Page

    Description of Figure 6-58 follows
    Description of "Figure 6-58 Native Format Builder File Description Page"
  6. Click Next. The Native Format Builder Design Schema Page is displayed.
  7. Create a global element called NewArray and drag and drop the native data to the newly created global element.
  8. Select NewArray, as shown in Figure 6-59, and click the Edit Node icon. The Element Details dialog is displayed.

    Figure 6-59 Native Format Builder Design Schema Page

    Description of Figure 6-59 follows
    Description of "Figure 6-59 Native Format Builder Design Schema Page"
  9. Set the options in the Element Details dialog, as shown in Figure 6-60, and then click OK.

    Figure 6-60 Element Details Dialog

    Description of Figure 6-60 follows
    Description of "Figure 6-60 Element Details Dialog"

    The Native Format Builder Design Schema dialog is displayed.

  10. Click Next. The Generated Native Format Schema File page is displayed, as shown in Figure 6-61, which displays the native format file.

    Figure 6-61 Generated Native Format Schema File Page

    Description of Figure 6-61 follows
    Description of "Figure 6-61 Generated Native Format Schema File Page"

    Native Schema

    The native schema definition corresponding to the preceding native data can be defined as follows:

    <?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
            xmlns:tns="http://TargetNamespace.com/testnewArray"
            targetNamespace="http://TargetNamespace.com/testnewArray"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified"
            nxsd:version="NXSD"
            nxsd:stream="chars"
            nxsd:encoding="ASCII"
>
  <xsd:element name="Root-Element">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="NewArray" type="xsd:string" maxOccurs="unbounded"
 nxsd:style="array" nxsd:cellSeparatedBy=";" nxsd:arrayTerminatedBy="." />
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>
  11. Click Test. The Test NXSD Schema dialog is displayed.
  12. Click the Generate XML icon. The Result XML is displayed on the right pane of the Test NXSD Schema dialog, as shown in Figure 6-62.

    Figure 6-62 Test NXSD Schema Dialog

    Description of Figure 6-62 follows
    Description of "Figure 6-62 Test NXSD Schema Dialog"

    Translated XML Using the Native Schema

    The translated XML looks as follows:

    <?xml version = '1.0' encoding = 'UTF-8'?>
<Root-Element xmlns="http://TargetNamespace.com/testnewArray">
   <NewArray>John</NewArray>
   <NewArray>Steve</NewArray>
   <NewArray>Paul</NewArray>
   <NewArray>Todd</NewArray>
</Root-Element>
  13. Click OK. The Generated Native Format File page is displayed.
  14. Click Next. The Native Format Builder Finish page is displayed.

6.4.8 Defining the Schema for a DTD File Structure

This use case takes you through the procedure for defining the schema for the native data type, DTD file.

Use the DTD to be converted to XSD option in the Native Format Builder wizard when creating the XML schema for this native file.

In this use case, the Native Format Builder uses a DTD file type *.dtd. You can generate the corresponding NXSD and also test it. Perform the following steps to run the use case:

  1. Use any DTD file.
  2. Launch the Adapter Configuration Wizard and navigate to the Messages page, as displayed in Figure 6-4, and click Define Schema For Native Format. The Native Format Builder Welcome page is displayed, as shown in Figure 6-5.
  3. Click Next. The Choose Type page is displayed, as shown in Figure 6-26.
  4. Select DTD to be converted to XSD. The Choose Type page is displayed, as shown in Figure 6-63.

    Figure 6-63 Native Format Builder Wizard Choose Type Page

    Description of Figure 6-63 follows
    Description of "Figure 6-63 Native Format Builder Wizard Choose Type Page"
  5. Click Next. The Native Format Builder DTD Description page is displayed.
  6. Click Browse and select the db.dtd file, and select DatabaseInventory from the Root Element list, as displayed in Figure 6-64.

    Figure 6-64 Native Format Builder Wizard File Description Page

    Description of Figure 6-64 follows
    Description of "Figure 6-64 Native Format Builder Wizard File Description Page"
  7. Click Next. The Generated Native Format File page is displayed, as shown in Figure 6-65.

    Figure 6-65 Native Format Builder Wizard Field Properties Page

    Description of Figure 6-65 follows
    Description of "Figure 6-65 Native Format Builder Wizard Field Properties Page"

    The resulting generated Native Format file is shown in the example below.

    Example - Native Format Generated File

    <?xml version="1.0" encoding="UTF-8" ?>
<!--This Schema has been generated from a DTD. 
A target namespace has beenadded to the schema.-->
<xs:schema xmlns:
          xs="http://www.w3.org/2001/XMLSchema"
targetNamespace=
              "http://TargetNamespace.com/ReadUI"
xmlns="http://TargetNamespace.com/ReadUI" 
                 nxsd:version="DTD"
 xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd">
   <xs:element name="GlobalDatabaseName" 
                      type="xs:string"/>
   <xs:element name="DatabaseAttributes">
      <xs:complexType>
         <xs:attribute name="Type" 
                         use="required">
            <xs:simpleType>
               <xs:restriction base="xs:NMTOKEN">
                  <xs:enumeration 
                             value="Production"/>
                  <xs:enumeration 
                             value="Development"/>
                  <xs:enumeration 
                             value="Testing"/>
               </xs:restriction>
            </xs:simpleType>
         </xs:attribute>
         <xs:attribute name="Version" 
                    use="optional" default="9i">
            <xs:simpleType>
               <xs:restriction base=
                             "xs:NMTOKEN">
                  <xs:enumeration value="7"/>
                  <xs:enumeration value="8"/>
                  <xs:enumeration value="8i"/>
                  <xs:enumeration value="9i"/>
               </xs:restriction>
            </xs:simpleType>
         </xs:attribute>
      </xs:complexType>
   </xs:element>
   <xs:element name="Comments" type="xs:string"/>
   <xs:element name="Administrator">
      <xs:complexType>
         <xs:simpleContent>
            <xs:extension base="xs:string">
               <xs:attribute name="EmailAlias"
                    use="required"
 type="xs:string"/>
               <xs:attribute name="Extension" 
                   use="optional" type="xs:string"/>
            </xs:extension>
         </xs:simpleContent>
      </xs:complexType>
   </xs:element>
   <xs:element name="OracleSID"
                  type="xs:string"/>
   <xs:element name="DatabaseName">
      <xs:complexType>
         <xs:sequence>
            <xs:element 
                 ref="GlobalDatabaseName"/>
            <xs:element
                 ref="OracleSID"/>
            <xs:element
                 ref="DatabaseDomain"/>
            <xs:element 
              maxOccurs="unbounded" ref="Administrator"/>
            <xs:element
              ref="DatabaseAttributes"/>
            <xs:element 
              ref="Comments"/>
         </xs:sequence>
      </xs:complexType>
   </xs:element>
   <xs:element name="DatabaseDomain" 
                   type="xs:string"/>
   <xs:element name="DatabaseInventory">
      <xs:complexType>
         <xs:sequence>
            <xs:element 
                   maxOccurs="unbounded"
                    ref="DatabaseName"/>
         </xs:sequence>
      </xs:complexType>
   </xs:element>
</xs:schema>
  8. Click Next. The Native Format Builder Finish page is displayed.
  9. Click Finish. The Adapter Configuration Wizard Messages page is displayed containing the generated NXSD.

6.4.9 Defining the Schema for a COBOL Copybook File Structure

This use case shows how the Oracle File and FTP Adapters process a file in COBOL Copybook format (through use of the Native Format Builder wizard) to create a native schema file for translation.

The following COBOL Copybook examples are provided:

6.4.9.1 Multiple Root Levels

A COBOL Copybook can have multiple root levels. If all root levels are at 01 level, then each such group implicitly redefines the other.

In this use case, the Native Format Builder uses a fixed-length file type, po-ccb.cpy, that contains the purchase order details such as buyer name, address, and items. Every element in this po-ccb.cpy native file has a fixed length. The data in the sample text file, po-ccb.cpy, appears as follows:

05 PO-RECORD.
10 PO-BUYER.
15 PO-UID PIC 9(7).
15 PO-NAME PIC X(15).
15 PO-ADDRESS.
20 PO-STREET PIC X(15).
20 PO-CITY PIC X(10).
20 PO-ZIP PIC 9(5).
20 PO-STATE PIC X(2).
10 PO-ITEM.
15 POITEM OCCURS 3 TIMES.
20 PO-LINE-ITEM.
25 PO-ITEM-ID PIC 9(3).
25 PO-ITEM-NAME PIC X(40).
25 PO-ITEM-QUANTITY PIC 9(2).
25 PO-ITEM-PRICE PIC 9(5)V9(2).
10 PO-TOTALPIC 9(7)V9(2).

You can generate the corresponding NXSD and also test it. Perform the following steps to run the use case:

  1. Get the following files from the artifacts.zip file contained in the Adapters-105CobolCopyBook sample.

    • artifacts/samples/po-ccb.cpy

    • artifacts/samples/po-ebcdic.data

    You can obtain the Adapters-105CobolCopyBook sample by accessing the Oracle SOA Sample Code site.

    Copy these files to your samples directory.

  2. Launch the Adapter Configuration Wizard and navigate to the Messages page, as displayed in Figure 6-4, and click Define Schema For Native Format. The Native Format Builder Welcome page is displayed, as shown in Figure 6-5.
  3. Click Next. The Choose Type page is displayed, as shown in Figure 6-26.
  4. Select Cobol Copybook to be converted to native format. The Choose Type page is displayed, as shown in Figure 6-66.

    Figure 6-66 Native Format Builder Wizard Choose Type Page

    Description of Figure 6-66 follows
    Description of "Figure 6-66 Native Format Builder Wizard Choose Type Page"
  5. Click Next. The Native Format Builder Cobol Copybook Description page is displayed.
  6. Click Browse and select the po-ccb.cpy file, as shown in Figure 6-67.

    Figure 6-67 Native Format Builder Wizard File Description Page

    Description of Figure 6-67 follows
    Description of "Figure 6-67 Native Format Builder Wizard File Description Page"
  7. Enter PurchaseOrder in the Root-Element field, and click Next. The Generated Native Format File page is displayed, as shown in Figure 6-68.

    Figure 6-68 Native Format Builder Wizard Generated Native Format File Page

    Description of Figure 6-68 follows
    Description of "Figure 6-68 Native Format Builder Wizard Generated Native Format File Page"

    The top level payroll records are enclosed in a choice model group. Each payroll record also has two attributes, nxsd:lookAhead and nxsd:lookFor that help identify the type of record during runtime processing of the data file. So, you must add values for these attributes. For example, assume PAYROLL-F-RECORD occurs when the PAYROLL-F-TRANS-CODE field has a value of FR. The record element then looks as follows:

    <xsd:element name="PAYROLL-F-RECORD" nxsd:lookAhead="10" nxsd:lookFor="FR">

    The value 10 indicates the position of the lookahead field. The following COBOL Copybook has multiple root elements at the 05 level:

    05 ORG-NUM           PIC 99.
05 EMP-RECORD. 
  10 EMP-SSN       PIC 9(4)V(6).
  10 EMP-WZT       PIC 9(6).

    The native schema is shown in the example below:

    Example - Native Schema

    <?xml version="1.0" encoding="UTF-8" ?>
<!--Native format was generated from COBOL copybook : C:\Documents and
 Settings\vdinesh\Desktop\sample_files\po-ccb.cpy-->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
 xmlns:extn="http://xmlns.oracle.com/pcbpel/nxsd/extensions"
 targetNamespace="http://TargetNamespace.com/Read"
xmlns:tns="http://TargetNamespace.com/Read" 
                            elementFormDefault="qualified"
 attributeFormDefault="unqualified" nxsd:version="NXSD" 
                            nxsd:encoding="cp037"
 nxsd:byteOrder="bigEndian" nxsd:stream="chars">
   <xsd:element name="PurchaseOrder">
      <xsd:complexType>
         <xsd:sequence>
            <!--COBOL declaration : 05 PO-RECORD-->
            <xsd:element name="PO-RECORD"
                               minOccurs="1"
                                  maxOccurs="unbounded">
               <xsd:complexType>
                  <xsd:sequence>
                     <!--COBOL declaration : 10 PO-BUYER-->
                     <xsd:element name="PO-BUYER">
                        <xsd:complexType>
                           <xsd:sequence>
                              <!--COBOL declaration : 
                                          15 PO-UID PIC 9(7)-->
                              <xsd:element name="PO-UID"
                                       type="xsd:long"
                                nxsd:style="fixedLength" 
                                         nxsd:padStyle="head"
                                nxsd:paddedBy="0"
                                nxsd:length="7"/>
                              <!--COBOL declaration :
                                         15 PO-NAME PIC X(15)-->
                              <xsd:element name="PO-NAME"
                                         type="xsd:string"
                                nxsd:style="fixedLength"
                                         nxsd:padStyle="tail"
                                nxsd:paddedBy=" "
                                nxsd:length="15"/>
                              <!--COBOL declaration : 
                                           15 PO-ADDRESS-->
                              <xsd:element name="PO-ADDRESS">
                                 <xsd:complexType>
                                    <xsd:sequence>
                                       <!--COBOL declaration :
                                           20 PO-STREET PIC X(15)-->
                                       <xsd:element name="PO-STREET"
                                        type="xsd:string"
                                        nxsd:style="fixedLength"
                                        nxsd:padStyle="tail"
                                        nxsd:paddedBy=" "
                                              nxsd:length="15"/>
                                       <!--COBOL declaration :
                                         20 PO-CITY PIC X(10)-->
                                       <xsd:element name="PO-CITY"
                                        type="xsd:string"
                                        nxsd:style="fixedLength"
                                        nxsd:padStyle="tail"
                                        nxsd:paddedBy=" "
                                               nxsd:length="10"/>
                          <!--COBOL declaration : 20 PO-ZIP PIC 9(5)-->
                                       <xsd:element name="PO-ZIP"
                                        type="xsd:long"
                                        nxsd:style="fixedLength"
                                        nxsd:padStyle="head"
                                        nxsd:paddedBy="0" nxsd:length="5"/>
                                       <!--COBOL declaration : 20 PO-STATE PIC
 X(2)-->
                                       <xsd:element name="PO-STATE"
                                        type="xsd:string"
                                        nxsd:style="fixedLength"
                                        nxsd:padStyle="tail"
                                        nxsd:paddedBy=" " nxsd:length="2"/>
                                    </xsd:sequence>
                                 </xsd:complexType>
                              </xsd:element>
                           </xsd:sequence>
                        </xsd:complexType>
                     </xsd:element>
                     <!--COBOL declaration : 10 PO-ITEM-->
                     <xsd:element name="PO-ITEM">
                        <xsd:complexType>
                           <xsd:sequence>
                              <!--COBOL declaration : 
                                           15 POITEM OCCURS 3 TIMES-->
                              <xsd:element name=
                                    "POITEM" minOccurs="3" maxOccurs="3">
                                 <xsd:complexType>
                                    <xsd:sequence>
                                       <!--COBOL declaration 
                                             : 20 PO-LINE-ITEM-->
                                       <xsd:element name="PO-LINE-ITEM">
                                          <xsd:complexType>
                                             <xsd:sequence>
                               <!--COBOL declaration :
                                             25 PO-ITEM-ID PIC 9(3)-->
                               <xsd:element name="PO-ITEM-ID"
                               type="xsd:long"
                               nxsd:style="fixedLength"
                                                 nxsd:padStyle="head"
                               nxsd:paddedBy="0" nxsd:length="3"/>
                              <!--COBOL declaration : 
                                           25 PO-ITEM-NAME PIC X(40)-->
                               <xsd:element name="PO-ITEM-NAME"
                               type="xsd:string" 
                               nxsd:style="fixedLength"
                               nxsd:padStyle="tail" 
                               nxsd:paddedBy=" 
                              " nxsd:length="40"/>
                               <!--COBOL declaration :
                                      25 PO-ITEM-QUANTITY PIC 9(2)-->
                                      <xsd:element name=
                                           "PO-ITEM-QUANTITY"
                                        type="xsd:long"
                                        nxsd:style="fixedLength"
                                        nxsd:padStyle="head" 
                                        nxsd:paddedBy="0" 
                                        nxsd:length="2"/>
                               <!--COBOL declaration :
                                          25 PO-ITEM-PRICE PIC 9(5)V9(2)-->
                                         <xsd:element name=
                                            "PO-ITEM-PRICE"
                                          type="xsd:decimal"
                                          nxsd:style="virtualDecimal"
                                 extn:assumeDecimal="5" 
                                          extn:picSize="7"/>
                                             </xsd:sequence>
                                          </xsd:complexType>
                                       </xsd:element>
                                    </xsd:sequence>
                                 </xsd:complexType>
                              </xsd:element>
                           </xsd:sequence>
                        </xsd:complexType>
                     </xsd:element>
                     <!--COBOL declaration :
                         10 PO-TOTAL PIC 9(7)V9(2)-->
                     <xsd:element name="PO-TOTAL" 
                       type="xsd:decimal"
                       nxsd:style="virtualDecimal"
                       extn:assumeDecimal="7" extn:picSize="9"/>
                  </xsd:sequence>
               </xsd:complexType>
            </xsd:element>
         </xsd:sequence>
      </xsd:complexType>
   </xsd:element>
</xsd:schema>
  8. Click Test. The Test NXSD Schema dialog is displayed.
  9. Click Browse and select the po-ebcdic.data file in the File Name field. The Test NXSD Schema dialog is displayed, as shown in Figure 6-69.

    Figure 6-69 Test NXSD Schema Dialog

    Description of Figure 6-69 follows
    Description of "Figure 6-69 Test NXSD Schema Dialog"
  10. Click the Generate XML icon. The Result XML is displayed on the right pane of the Test NXSD Schema dialog, as shown in Figure 6-70.

    Figure 6-70 Test NXSD Schema Dialog

    Description of Figure 6-70 follows
    Description of "Figure 6-70 Test NXSD Schema Dialog"

    The native data using the corresponding native schema format is translated to the following XML, as shown in the example below.

    Example - Native Data Using the Corresponding Native Schema

    <?xml version = '1.0' encoding = 'UTF-8'?>
<PurchaseOrder 
            xmlns="http://TargetNamespace.com/Read">
   <PO-RECORD>
      <PO-BUYER>
         <PO-UID>6335722</PO-UID>
         <PO-NAME>Company One</PO-NAME>
         <PO-ADDRESS>
            <PO-STREET>First Street</PO-STREET>
            <PO-CITY>San Jose</PO-CITY>
            <PO-ZIP>95129</PO-ZIP>
            <PO-STATE>CA</PO-STATE>
         </PO-ADDRESS>
      </PO-BUYER>
      <PO-ITEM>
         <POITEM>
            <PO-LINE-ITEM>
               <PO-ITEM-ID>1</PO-ITEM-ID>
               <PO-ITEM-NAME>
                     BPEL Process Manager Enterprise
 Edition</PO-ITEM-NAME>
               <PO-ITEM-QUANTITY>2
                           </PO-ITEM-QUANTITY>
               <PO-ITEM-PRICE>40000.0
                           </PO-ITEM-PRICE>
            </PO-LINE-ITEM>
         </POITEM>
         <POITEM>
            <PO-LINE-ITEM>
               <PO-ITEM-ID>2</PO-ITEM-ID>
               <PO-ITEM-NAME>
                         BPEL Process Manager Standard
 Edition</PO-ITEM-NAME>
               <PO-ITEM-QUANTITY>5
                         </PO-ITEM-QUANTITY>
               <PO-ITEM-PRICE>50000.0
                         </PO-ITEM-PRICE>
            </PO-LINE-ITEM>
         </POITEM>
         <POITEM>
            <PO-LINE-ITEM>
               <PO-ITEM-ID>3</PO-ITEM-ID>
               <PO-ITEM-NAME>
                       BPEL Process Manager Developer
 Edition</PO-ITEM-NAME>
               <PO-ITEM-QUANTITY>20
                           </PO-ITEM-QUANTITY>
               <PO-ITEM-PRICE>20000.0
                          </PO-ITEM-PRICE>
            </PO-LINE-ITEM>
         </POITEM>
      </PO-ITEM>
      <PO-TOTAL>730000.0</PO-TOTAL>
   </PO-RECORD>
</PurchaseOrder>

    In this (non-01 level) case, an unbounded sequence of the root level items is generated.

  11. Click OK. The Generated Native Format File page is displayed.
  12. Click Next. The Native Format Builder Finish page is displayed.
  13. Click Finish. The Adapter Configuration Wizard Messages page is displayed, containing the generated NXSD.

6.4.9.2 Single Root Level, Virtual Decimal, Fixed-Length Array

The following COBOL Copybook has a single root level item PO-RECORD. In a single root level case, the level number does not matter because the converter works in the same way. This COBOL Copybook also shows an example of a field declared as a virtual decimal (PO-ITEM-PRICE).

05 PO-RECORD. 
      10 PO-BUYER. 
        15 PO-UID    PIC 9(7). 
        15 PO-NAME   PIC X(15). 
        15 PO-ADDRESS. 
            20 PO-STREET PIC X(15). 
            20 PO-CITY   PIC X(10). 
            20 PO-ZIP    PIC 9(5). 
            20 PO-STATE  PIC X(2). 
      10 PO-ITEM. 
        15 POITEM OCCURS 3 TIMES. 
            20 PO-LINE-ITEM. 
              25 PO-ITEM-ID       PIC 9(3). 
              25 PO-ITEM-NAME     PIC X(40). 
              25 PO-ITEM-QUANTITY PIC 9(2). 
              25 PO-ITEM-PRICE    PIC 9(5)V9(2). 
      10 PO-TOTAL PIC  9(7)V9(2).

The generated schema looks as follows:

Example - Generated Schema

<?xml version="1.0" encoding="UTF-8" ?> 
<!--Native format was generated from COBOL copybook:D:\work\
jDevProjects\CCB\Copybooks\po-ccb.cpy--> 
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
       xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd" 
       xmlns:extn="http://xmlns.oracle.com/
                              pcbpel/nxsd/extensions" 
       targetNamespace=
                  "http://TargetNamespace.com/ccb/singleRoot" 
       xmlns:tns="http://TargetNamespace.com/ccb/singleRoot" 
       elementFormDefault="qualified" 
                    attributeFormDefault="unqualified" 
       nxsd:version="NXSD" nxsd:encoding=
                   "cp037" nxsd:byteOrder="bigEndian" 
       nxsd:stream="chars"> 
 <xsd:element name="Root-Element"> 
  <xsd:complexType> 
   <xsd:sequence> 
    <!--COBOL declaration : 05 PO-RECORD --> 
    <xsd:element name="PO-RECORD" 
                        minOccurs="1" 
                     maxOccurs="unbounded"> 
     <xsd:complexType> 
      <xsd:sequence> 
       <!--COBOL declaration : 10 PO-BUYER--> 
       <xsd:element name="PO-BUYER"> 
        <xsd:complexType> 
         <xsd:sequence> 
          <!--COBOL declaration : 15 PO-UID PIC 9(7)--> 
          <xsd:element name="PO-UID" 
                                  type="xsd:long" 
                  nxsd:style="fixedLength" 
                                  nxsd:padStyle="head" 
                  nxsd:paddedBy="0" nxsd:length="7"/> 
          <!--COBOL declaration : 
                           15 PO-NAME PIC X(15)--> 
          <xsd:element name="PO-NAME"
                                type="xsd:string" 
                  nxsd:style="fixedLength"
                                nxsd:padStyle="tail" 
                  nxsd:paddedBy=" " 
                         nxsd:length="15"/> 
          <!--COBOL declaration : 15 PO-ADDRESS--> 
          <xsd:element name="PO-ADDRESS"> 
                  <xsd:complexType> 
                  <xsd:sequence> 
          <!--COBOL declaration :
                         20 PO-STREET PIC X(15)--> 
          <xsd:element name="PO-STREET" 
                            type="xsd:string" 
                  nxsd:style="fixedLength" 
                  nxsd:padStyle="tail" nxsd:paddedBy=" " 
                  nxsd:length="15"/> 
          <!--COBOL declaration : 
                             20 PO-CITY PIC X(10)--> 
          <xsd:element name="PO-CITY" 
                                    type="xsd:string" 
                  nxsd:style="fixedLength" 
                  nxsd:padStyle="tail" 
                                   nxsd:paddedBy=" " 
                  nxsd:length="10"/> 
          <!--COBOL declaration : 
                              20 PO-ZIP PIC 9(5)--> 
          <xsd:element name="PO-ZIP" 
                                 type="xsd:long" 
                  nxsd:style="fixedLength" 
                  nxsd:padStyle="head"
                             nxsd:paddedBy="0" 
                  nxsd:length="5"/> 
          <!--COBOL declaration : 
                           20 PO-STATE PIC X(2)--> 
          <xsd:element name="PO-STATE" 
                                type="xsd:string" 
                  nxsd:style="fixedLength" 
                  nxsd:padStyle="tail" 
                               nxsd:paddedBy=" " 
                  nxsd:length="2"/> 
         </xsd:sequence> 
        </xsd:complexType> 
       </xsd:element> 
      </xsd:sequence> 
     </xsd:complexType> 
    </xsd:element> 
    <!--COBOL declaration : 10 PO-ITEM--> 
    <xsd:element name="PO-ITEM"> 
     <xsd:complexType> 
      <xsd:sequence> 
       <!--COBOL declaration : 
                  15 POITEM OCCURS 3 TIMES--> 
       <xsd:element name="POITEM" minOccurs="3"
                         maxOccurs="3"> 
        <xsd:complexType> 
         <xsd:sequence> 
          <!--COBOL declaration : 20 PO-LINE-ITEM--> 
          <xsd:element name="PO-LINE-ITEM"> 
           <xsd:complexType> 
            <xsd:sequence> 
             <!--COBOL declaration :
                      25 PO-ITEM-ID PIC 9(3)--> 
             <xsd:element name="PO-ITEM-ID" 
                                  type="xsd:long" 
                     nxsd:style="fixedLength" 
                     nxsd:padStyle="head" 
                     nxsd:paddedBy="0" 
                             nxsd:length="3"/> 
             <!--COBOL declaration : 
                   25 PO-ITEM-NAME PIC X(40)--> 
             <xsd:element name="PO-ITEM-NAME" 
                     type="xsd:string" 
                     nxsd:style="fixedLength" 
                     nxsd:padStyle="tail" 
                     nxsd:paddedBy=" " 
                               nxsd:length="40"/> 
             <!--COBOL declaration :
                          25 PO-ITEM-QUANTITY 
                               PIC 9(2)--> 
             <xsd:element name="PO-ITEM-QUANTITY" 
                     type="xsd:long" 
                     nxsd:style="fixedLength" 
                     nxsd:padStyle="head" 
                     nxsd:paddedBy="0" 
                             nxsd:length="2"/> 
             <!--COBOL declaration :
                       25 PO-ITEM-PRICE PIC 
                                   9(5)V9(2)--> 
             <xsd:element name="PO-ITEM-PRICE" 
                     type="xsd:decimal" 
                     nxsd:style="virtualDecimal" 
                     extn:assumeDecimal="5" 
                     extn:picSize="7"/> 
            </xsd:sequence> 
           </xsd:complexType> 
          </xsd:element> 
         </xsd:sequence> 
        </xsd:complexType> 
       </xsd:element> 
      </xsd:sequence> 
     </xsd:complexType> 
       </xsd:element> 
       <!--COBOL declaration : 10 PO-TOTAL PIC 9(7)V9(2)--> 
       <xsd:element name="PO-TOTAL" type="xsd:decimal" 
               nxsd:style="virtualDecimal"
                     extn:assumeDecimal="7" 
               extn:picSize=" "/> 
      </xsd:sequence>
     </xsd:complexType>
    </xsd:element> 
   </xsd:sequence> 
  </xsd:complexType> 
 </xsd:element> 
</xsd:schema>

6.4.9.3 Variable Length Array

05 EMP-RECORD . 
   10 EMP-NAME         PIC X(30). 
   10 EMP-DIV-NUM      PIC 9(5). 
   10 DIV-ENTRY OCCURS 1 TO 50 TIMES 
      DEPENDING ON EMP-DIV-NUM. 
      20 DIV-CODE             PIC X(30).

The generated schema is shown in example below.

Example - The Generated Schema for Variable Length Array

<?xml version="1.0" encoding="UTF-8" ?> 
<!--Native format was generated from COBOL copybook:D:\work\
jDevProjects\CCB\Copybooks\odo.cpy--> 
<xsd:schema xmlns:xsd=
                "http://www.w3.org/2001/XMLSchema" 
       xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd" 
       xmlns:extn="http://xmlns.oracle.com/
                       pcbpel/nxsd/extensions" 
       targetNamespace=
                      "http://TargetNamespace.com/
                       ccb/varLengthArray" 
       xmlns:tns="http://TargetNamespace.com/
                       ccb/varLengthArray" 
       elementFormDefault="qualified" 
                      attributeFormDefault=
                            "unqualified" 
       nxsd:version="NXSD" nxsd:encoding="cp037"
                      nxsd:byteOrder="bigEndian" 
       nxsd:stream="chars"> 
 <xsd:element name="Root-Element"> 
  <xsd:complexType> 
   <xsd:sequence> 
    <!--COBOL declaration :05 EMP-RECORD --> 
    <xsd:element name="EMP-RECORD" 
                minOccurs="1" 
                    maxOccurs="unbounded"> 
     <xsd:annotation> 
      <xsd:appinfo> 
       <nxsd:variables> 
        <nxsd:variable name="DIV-ENTRY_var0"/> 
       </nxsd:variables> 
      </xsd:appinfo> 
      </xsd:annotation> 
      <xsd:complexType> 
       <xsd:sequence> 
        <!--COBOL declaration:10 EMP-NAME PIC X(30)--> 
        <xsd:element name="EMP-NAME" 
                           type="xsd:string" 
                nxsd:style="fixedLength"
                      nxsd:padStyle="tail" 
                nxsd:paddedBy=" " 
                           nxsd:length="30"/> 
        <!--COBOL declaration:10 EMP-DIV-NUM PIC 9(5)--> 
        <xsd:element name="EMP-DIV-NUM" 
                            type="xsd:long" 
                nxsd:style="fixedLength" 
                            nxsd:padStyle="head" 
                nxsd:paddedBy="0" 
                          nxsd:length="5"> 
         <xsd:annotation> 
          <xsd:appinfo> 
           <nxsd:variables> 
            <nxsd:assign name="DIV-ENTRY_var0" 
                                value="${0}"/> 
           </nxsd:variables> 
          </xsd:appinfo> 
         </xsd:annotation> 
        </xsd:element> 
       <!--COBOL declaration :10 DIV-ENTRY OCCURS 1 TO 50 TIMES DEPENDING ON 
          EMP-DIV-NUM--> 
        <xsd:element name="DIV-ENTRY" 
                              nxsd:style="array" 
                nxsd:arrayLength=
                         "${DIV-ENTRY_var0}" 
                               minOccurs="1" 
                maxOccurs="50"> 
         <xsd:complexType> 
          <xsd:sequence> 
           <!--COBOL declaration : 20 DIV-CODE PIC X(30)--> 
           <xsd:element name=
                        "DIV-CODE" type="xsd:string" 
                   nxsd:style="fixedLength" 
                              nxsd:padStyle="tail" 
                   nxsd:paddedBy=" " 
                            nxsd:length="30"/> 
          </xsd:sequence> 
         </xsd:complexType> 
        </xsd:element> 
       </xsd:sequence> 
      </xsd:complexType> 
     </xsd:element> 
    </xsd:sequence> 
   </xsd:complexType> 
  </xsd:element> 
</xsd:schema>

6.4.9.4 Numeric Types

01   NUMERIC-FORMATS. 
     05    Salary         PIC 9(5) COMP-3. 
     05    Rating         PICTURE S9(5).  
     05    Age            PIC 9(3) USAGE COMP. 
     05    Revenue        PIC 9(3)V9(2). 
     05    Growth         PIC S9(3) SIGN IS LEADING. 
     05    Computation    COMP-1.

The generated schema is shown in the example below.

Example - Generated Schema for Numeric Types

<?xml version="1.0" encoding="UTF-8" ?> 
<!--Native format was generated from COBOL copybook : 
D:\work\jDevProjects\CCB\Copybooks\numeric.cpy--> 
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
       xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd" 
       xmlns:extn="http://xmlns.oracle.com/pcbpel/nxsd/extensions" 
       targetNamespace="http://TargetNamespace.com/ccb/numeric" 
       xmlns:tns="http://TargetNamespace.com/ccb/numeric" 
       elementFormDefault="qualified" 
                        attributeFormDefault="unqualified" 
       nxsd:version="NXSD" nxsd:encoding="cp037" 
                        nxsd:byteOrder="bigEndian" 
       nxsd:stream="bytes"> 
  <xsd:element name="Numerics"> 
   <xsd:complexType> 
    <xsd:sequence> 
      <!--COBOL declaration :01 NUMERIC-FORMATS--> 
       <xsd:element name="NUMERIC-FORMATS" 
                     minOccurs="1" maxOccurs="unbounded"> 
        <xsd:complexType> 
         <xsd:sequence> 
          <!--COBOL declaration : 05 Salary PIC 9(5) COMP-3--> 
          <xsd:element name="Salary"
                        type="xsd:long" nxsd:style="comp3" 
                  extn:sign="unticked" extn:picSize="5"/> 
          <!--COBOL declaration:05 Rating PICTURE S9(5)--> 
          <xsd:element name="Rating" 
                               type="xsd:string" 
                  nxsd:style="signZoned" extn:sign="ticked" 
                  extn:picSize="5" 
                           extn:signPosn="tailUpperNibble"/> 
          <!--COBOL declaration:05 Age PIC 9(3) USAGE COMP--> 
          <xsd:element name="Age" type="xsd:long"
                                   nxsd:style="comp" 
                  extn:picSize="3" extn:sign="unticked"/> 
          <!--COBOL declaration:05 Revenue PIC 9(3)V9(2)--> 
          <xsd:element name="Revenue" type="xsd:decimal" 
                  nxsd:style="virtualDecimal" 
                                   extn:assumeDecimal="3" 
                  extn:picSize="5"/> 
          <!--COBOL declaration : 05 Growth PIC S9(3) SIGN IS LEADING--> 
          <xsd:element name="Growth" type="xsd:string" 
                  nxsd:style="signZoned" 
                                  extn:sign="ticked" 
                  extn:picSize="3" 
                            extn:signPosn="headUpperNibble"/> 
          <!--COBOL declaration : 05 Computation COMP-1--> 
          <xsd:element name="Computation" 
                                  type="xsd:float" 
                  nxsd:style="comp1" extn:sign="ticked"/> 
         </xsd:sequence> 
        </xsd:complexType> 
       </xsd:element> 
      </xsd:sequence> 
    </xsd:complexType> 
  </xsd:element> 
</xsd:schema>

In this case, all numeric types follow formats specified according to IBM COBOL formats. If the data file originates from a different system by using different layouts, the generated schema requires modification.

6.5 Command Line Tool for Testing NXSD Translator

You might want to test your nXSD schema to ensure that nXSD annotations are correct and that generated XML/native data conforms to your business semantics. If you want to do that currently, you must write a BPEL process with an inbound or outbound File Adapter partner link, or both, configured with the appropriate nXSD schema and test them on the SOA server. This is both time-consuming and error prone.

A simple standalone test client is available that can enable you to verify your nXSD schemas. You can download the test tool jar from http://download.oracle.com/otndocs/test-translator.jar

6.5.1 Prerequisites

Before you use the test client to verify your nXSD schemas, add the following jars in the classpath. These jars (except for test-translator.jar) are available as a part of your SOA installation. You must use Java 6 to run the test client.

  • bpm-infra.jar. This is the nXSD runtime jar available under $SOA_HOME/soa/modules/oracle.soa.fabric_11.1.1

  • xmlparserv2.jar. This is the Oracle XDK library for parsing available under $FMW_HOME/oracle_common/modules/oracle.xdk_11.1.0

  • xml.jar This is the Oracle XDK library for schema validation available under $FMW_HOME/oracle_common/modules/oracle.xdk_11.1.0

  • mail.jar .This is the Java mail API.

  • test-translator.jar. You must rename the extension from jarr to jar.

6.5.2 Running the Test Tool

Now you can run java xlator.util.Translate -help and the usage should be displayed as shown in Figure 6-71. When supply the -help option, the tool supplies a list of options and defaults.

Figure 6-71 Running java xlator.util.Translate -help

Description of Figure 6-71 follows
Description of "Figure 6-71 Running java xlator.util.Translate -help"

The following example sample execution of the test client converts the address-csv.txt file to address-csv.xml.

The command is:java xlator.util.Translate -inbound -schema address-csv.xsd -root Root-Element -input address-csv.txt -output address-csv.xml

Figure 6-72 Using the Test Tool to Convert txt to xml

Description of Figure 6-72 follows
Description of "Figure 6-72 Using the Test Tool to Convert txt to xml"

Sample execution of the test client to convert address-csv.xml to address-csv.txt:

java xlator.util.Translate -outbound -schema address-csv.xsd -root Root-Element -input address-csv.xml -output address-csv.txt

Figure 6-73 Using the Test Tool to Convert xml to txt

Description of Figure 6-73 follows
Description of "Figure 6-73 Using the Test Tool to Convert xml to txt"

The following sample execution of the test client converts address-csv.txt to a series of address-csv.xml_batch_%SEQ%.xml files using de-batching.

java xlator.util.Translate -inbound -debatch 1 -schema address-csv.xsd -root Root-Element -input address-csv.txt -output address-csv.xml

Figure 6-74 Using the Test Tool to Convert address-csv.txt to a Series of batch xml Files

Description of Figure 6-74 follows
Description of "Figure 6-74 Using the Test Tool to Convert address-csv.txt to a Series of batch xml Files"

6.5.3 Using the Native Format Builder to Perform MFL Conversion

Oracle WebLogic integration uses a specific XML file format, called MFL format Language, which is a proprietary language that describes native data. MFL is an XML but not a schema file, and MFL cannot be used for SOA transformation/mapping without a an nXSD file.

The MFL conversion feature provides pluggability of MFL in the existing framework, and generates schema corresponding to the MFL format. You can then use the generated schema at runtime.

See the Open Service Bus documentation on MFL, "Defining Data Structures with Message Format Language" in Developing Services with Oracle Service Bus.

6.5.3.1 Converting an MFL Format File to Schema Format

To accomplish the first step, you tell JDeveloper to convert MFL to NXSD Schema files.

6.5.3.2 Generating the Schema File and Adding it to the SOA Composite Process

You then use JDeveloper to generate the schema file, which is consumed by the Native Format Builder translator. Because MFL files do not have a target namespace associated with them, you must provide the target namespace for the generated schema file.

If you saved the generated schema file in SOA Project XSD directory when converting the MFL to Schema files, you can skip this step.

If you have generated the schema file in a directory other than that of SOA Project, you must add the schema file generated in Step 1 to the SOA Composite Project's XSD folder.

Once you have added the schema file to the SOA Project, you can use this schema file as you would use any schema file in the project for payload transformation or payload mapping to a variable. The translator runtime uses the attributes defined in the schema file to invoke the MFL Translator at runtime.

6.5.3.2.1 Sample MFL File

A sample MFL file is:

<?xml version='1.0' encoding='windows-1252'?>
<!DOCTYPE MessageFormat SYSTEM 'mfl.dtd'>
<MessageFormat name='Root-Element' version='2.01'>
    <StructFormat name='Address' repeat='*'>
      <FieldFormat name='Name' type='String' delim=',' codepage='windows-1252'/>
      <FieldFormat name='Street1' type='String' delim=','            codepage='windows-1252'/>
    </StructFormat>
</MessageFormat>
6.5.3.2.2 Sample Schema File Created from the Sample MFL File

The schema file created from the MFL file has two new namespaces:

  • xmlns:mfl="http://www.bea.com/mfl"

  • xmlns:nxsd=http://xmlns.oracle.com/pcbpel/nxsd

Additionally, the version of the NXSD translator in the schema is set to MFL: nxsd:version="MFL"

A sample schema file produced from the MFL file is shown in the example below.

Example - Sample Schema File Produced from MFL File

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
                      xmlns="http://MyTNS1"
targetNamespace="http://MyTNS1" 
                    xmlns:mfl="http://www.bea.com/mfl" xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd" 
                  elementFormDefault="qualified"
                    nxsd:version="MFL">
    <xsd:import namespace="http://www.bea.com/mfl" 
                    schemaLocation="mfl.xsd"/>
      <xsd:element name="Root-Element">
          <xsd:annotation>
            <xsd:appinfo>
<mfl:MessageFormat encoding="windows-1252"/>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Address" minOccurs="1" 
                       maxOccurs="unbounded">
<xsd:annotation>
<xsd:appinfo>
<mfl:StructFormat repeat="*"/>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Name" type="mfl:String">
                                <xsd:annotation>
                                    <xsd:appinfo>
                                        <mfl:FieldFormat delim=","
                                          codepage="windows-1252"/>
                                    </xsd:appinfo>
                                </xsd:annotation>
                            </xsd:element>
                            <xsd:element name=
                               "Street1" type="mfl:String">
                                <xsd:annotation>
                                    <xsd:appinfo>
                                        <mfl:FieldFormat delim=","
                                         codepage="windows-1252"/>
                                    </xsd:appinfo>
                                </xsd:annotation>
                            </xsd:element>
                        </xsd:sequence>
                    </xsd:complexType>
                </xsd:element>
            </xsd:sequence>
        </xsd:complexType>
    </xsd:element>
</xsd:schema>

6.5.3.3 Native Format Builder Wizard Flow for MFL File Conversion

Follow these steps to use the Native Format Builder Wizard to convert MFL files and generate a schema from them.

  1. On the Choose Type page, select Create New-->> MFL to be created to NXSD.

    Figure 6-75 Native Format Builder Choose Type Screen with MFL to be Converted to XSD Selected

    Description of Figure 6-75 follows
    Description of "Figure 6-75 Native Format Builder Choose Type Screen with MFL to be Converted to XSD Selected"
  2. The Native Format Builder Wizard displays the Description Screen. Provide the location of the MFL file you want converted to XSD and a target namespace you want specified in the schema file. Click Next.

    Figure 6-76 Native Format Builder Wizard Showing the MFL Description Screen

    Description of Figure 6-76 follows
    Description of "Figure 6-76 Native Format Builder Wizard Showing the MFL Description Screen"
  3. Once you have provided the file location and target namespace, the Wizard displays the generated schema file. You can edit the generated schema file, if required, and save it to the location you want, typically the location of the xsd folder in the SOA Composite Project.

    Figure 6-77 Native Format Builder Screen Showing the Generated Native Format Schema File

    Description of Figure 6-77 follows
    Description of "Figure 6-77 Native Format Builder Screen Showing the Generated Native Format Schema File"
  4. Click Next to display the Native Format Builder Finish Screen, which indicates where the schema file resides.

    Figure 6-78 The Native Format Builder Finish Screen

    Description of Figure 6-78 follows
    Description of "Figure 6-78 The Native Format Builder Finish Screen"

By clicking Finish you complete the generation of schema file from the MFL file. The generated schema file is saved at the desired location.

6.5.4 Multi-Character Streaming Support

Often fixed length data length is available in terms of Bytes rather than that of Characters. The field data is in multi-byte character encoding.

In this case, the number of Bytes is not equivalent to the number of Characters in the field. Reading this type of data is not supported by the NXSD Translator.

Currently, the Translator assumes length in terms of Characters only. The Translator uses the Character Reader to read the specified number of Characters.

With support for Multi-Byte Streaming, you can specify the length of a field in terms of Bytes. Translator uses the Byte Reader to read the specified number of Bytes and convert read bytes to characters. These characters are then placed in the generated XML.

Similarly, the outbound Translator converts the XML Data to the specified byte length and write those bytes to the output stream

6.5.5 Shared Delimiters

You often use delimiters when using the Native Format Builder. The behavior of delimiters within the Native Format Builder often depends on the context of their use.

For instance, if a schema document has optional nodes, the existence of the delimiter of their parent could suggest that the native stream does not have data corresponding to these optional nodes. Alternatively, it could be that the delimiter of the parent itself is part of the data for an optional node. It all depends on context.

Similarly, for an outbound scenario, while processing the last field of a group, the NXSD Translator might require hints related to whether placing the last field delimiter followed by group delimiter or simply by a group delimiter would suffice.

With the Shared Delimiter approach, the NXSD Translator addresses such nuances related to the implied meaning of delimiters based on context and provides custom annotations for you to control the meaning of delimiters in context.

6.5.5.1 Basic Concepts for NXSD Translator with Inbound Shared Delimiter Processing

A shared delimiter indicates that the delimiter marks both the end of the group of data, and the end of the last field of the group. The delimiter is shared between the last field of the group and the end of the group.

6.5.5.1.1 Terminating the Cell and the Array

Within the NXSD framework, arrays are used to define repeating structures. nxsd:cellSeparatedBy construct defines the delimiter for each cell in the array. This delimiter is used to terminate both the cell and last field of the structure if found before the delimiter of the last field of this structure.

The nxsd:arrayTerminatedBy construct marks the end of array itself; it is used to terminate the cell and the array if it is found before the cellSeparatedBy delimiter.

6.5.5.1.2 Important Terminology

The following terms are important in understanding the concept of shared delimiters:

  • Last non-optional node: The node is in a sequence structure which is wrapped by an array. This node is required, and all trailing nodes after this are optional.

  • Trailing optional node: The node is in a sequence structure which is wrapped by an array. This node is optional and all trailing nodes after this node are optional.

  • Pending delimiters list: List containing all delimiters starting from the immediate parent array delimiter (which itself could be the last required node of an array which has a shared delimiter).

  • Array: A collection of cells.

  • Array terminator marks the end of array

  • Cell separator: marks the end of each cell of the array.

  • Each cell can contain a structure - typically the structure repeats and that is why it is surrounded by an array.

  • Structure can contain required and optional elements.

  • Delimiters can be at different levels:

    • Field Level

    • Group Levels

6.5.5.1.3 Sharing Cell Separator and Array Terminators

Either the cell separator or the array terminator or both can be shared with the elements of group. The cell separator defines the sharing boundary of a cell; the array terminator defines the array and specifies if the array contains any trailing optional fields.

You can specify the terminators as being shared with the elements of group with the following two annotations:

  • nxsd:cellSeparator="shared" Defines that the array cell separator is shared with the last non-optional field delimiter or with any of the trailing optional field delimiters. The default value for this annotation is "nonshared". This means that under shared mode, when the translator encounters a cell separator while processing any last non optional or trailing optional field in an array, the Translator assumes that this field is over and that the array does not contain any trailing optional field. If the field is over, and there is no trailing optional field, the Translator then closes the current field along with the cell.

  • nxsd:arrayTerminator="shared" The array terminator is shared with the cell separator and with the last non optional field or with any trailing optional field.

    The default value for this attribute is nonshared. This means that when the Translator encounters an array terminator while processing the last non-optional field or any trailing optional field, the Translator assumes that the current field is over and array do not contains any trailing optional fields.

    If the array is over, and does not contain any trailing optional fields, the Translator closes the current field, current cell and also the array.

6.5.5.1.4 Behavior

Shared delimiter behavior also depends on the nature of the cell. There are three main types of behavior, in addition to a miscellaneous type:

  • Terminated

  • Fixed Length

  • Surrounded

Terminated behavior depends on if the trailing optional children have a delimiter, or if one of the parent delimiters is found.

  • If trailing optional children are terminated, the Translator reads from the native data looking for both the child terminator and the pending delimiters.

  • If the trailing optional child's terminator is found, generate the optional child.

  • However, if one of the parent delimiters is found, map the currently read data to the current optional child, generate it in xml, ignore all optional trailing and close the parent structure till the level the parent delimiter was found.

Fixed length behavior is related to a trailing optional child being fixed length, or if a pending delimiter exists.

  • If the trailing optional child is fixed length, before processing the child, look for pending delimiters.

  • If one of the parent delimiters is found, ignore trailing optional and close the structures till the parent delimiters structure.

  • If pending delimiter does not exist, the Translator reads fixed length number of characters corresponding to this optional node, bypasses pending delimiters if they come as part of the fixed length, generates optional node in XML.

Note:

The NXSD Translator does not handle the scenarios where the shared delimiter is actually present at the start of the fixed length data (that is, fixed length data cannot be escaped as quoted)

Surrounded behavior depends on if a child is surrounded, the behavior of the surroundedBy delimiter, and the existence of a parent delimiter.

  • If trailing optional child is surrounded, before processing the child, look for pending delimiters.

  • If a pending delimiter does not exist, read the surrounded native data corresponding to this optional node, bypass the pending delimiters if they come before the surroundedBy delimiter, and generate an optional node in XML. Repeat this logic for the next trailing optional node.

  • If one of the parent delimiters is found, ignore the trailing optional and close the structures until the parent delimiters structure is determined.

    Note that when the comma is used as both shared cell and array separator in NXSD schema, it results in first and only element in the output.

    For example, Input native data is Field1,Field2,Field3,Field4,Field5 and

    cellSeparatedBy=',' and arrayTerminatedBy=',' and both are shared, so the result is only first Field. For example,

    <sharedDelim xmlns="http://xmlns.mydomain.com/pcbpel/nxsd/test"> 
    <Group1> 
       <Group2> 
          <Field1>Field1</Field1> 
       </Group2> 
    </Group1> 
 </sharedDelim>

6.5.5.2 Terminated Use Cases

The use cases in this section relate to terminated behavior: whether trailing optional children are terminated, if trailing optional child's terminator is found, and if one of the parent delimiters is found.

Refer to Figure 6-79 for an illustration of the schema for the use cases, and to Table 6-11 for a description of the use cases. The description includes a list of the fields

Figure 6-79 Schema for Terminated Use Cases

Description of Figure 6-79 follows
Description of "Figure 6-79 Schema for Terminated Use Cases"

Table 6-11 Terminated Use Cases

Num Name Use Case Description Output

1

Terminated_example_1.xsd

Field1#Field2$@Field11#Field22$^Field3%!

---

2 cells of group2 followed by field3 comprise one and only cell of group1.

 
<sharedDelim>    
 <Group1>      
    <Group2>         
         <Field1>Field1</Field1>        
         <Field2>Field2</Field2>      
    </Group2>      
    <Group2>         
         <Field1>Field11</Field1>         
         <Field2>Field22</Field2>      
    </Group2>      
    <Field3>Field3</Field3>   
  </Group1> 
</sharedDelim>

2

Terminated_example_2.xsd

Field1@Field11#Field22$^Field3%!

---

2 cells of group2. In the first, optional Field2 is missing, in the second, optional Field2 is present. Along with Field3 comprise one cell of array Group1

 
<sharedDelim> 
    <Group1> 
        <Group2> 
            <Field1>Field1</Field1> 
        </Group2> 
        <Group2> 
            <Field1>Field11</Field1> 
            <Field2>Field22</Field2> 
        </Group2>

3

Terminated_example_3.xsd

Field1@Field11#Field22!

---

2 cells of group2. In the first, optional Field2 is missing, in the second, optional Field2 is present. Optional Field3 is missing and this comprises a cell of Group1.

 
<sharedDelim> 
    <Group1> 
        <Group2> 
            <Field1>Field1</Field1> 
        </Group2> 
        <Group2> 
            <Field1>Field11</Field1> 
            <Field2>Field22</Field2> 
       </Group2> 
    </Group1> 
</sharedDelim>

4

Terminated_example_4.xsd

Field1!

---

1 cell of Group2 with missing optional Field2 comprises a cell of Group1 with missing optional Field3.

 
 <sharedDelim>     <Group1>         <Group2>             <Field1>Field1</Field1>         </Group2>     </Group1> </sharedDelim>

5

Terminated_example_5.xsd

Field0!Field1#Field2$@Field11#Field22$^Field3%!Field111!

---

3 cells of Group1. First cell has 1 cell of Group2 with missing optional Field2 and missing optional Field3. Second cell has 2 cells of Group2 with both the fields and also contains optional Field3.

Third cell again is same as first cell.

 
<sharedDelim> 
    <Group1> 
        <Group2> 
            <Field1>Field0</Field1> 
        </Group2> 
    </Group1> 
    <Group1> 
     <Group2> 
            <Field1>Field1</Field1> 
            <Field2>Field2</Field2> 
        </Group2> 
        <Group2> 
            <Field1>Field11</Field1> 
            <Field2>Field22</Field2> 
        </Group2> 
        <Field3>Field3</Field3> 
    </Group1> 
    <Group1> 
    <Group2> 
            <Field1>Field111</Field1> 
    </Group2> 
    </Group1> 
</sharedDelim>

6.5.5.3 Fixed Length Use Cases

The use cases in this section are all fixed length use cases.

See Figure 6-80 for an illustration of the schema for the use cases and Table 6-12 for a description of the use cases. The description includes a list of the fields

Figure 6-80 Fixed Length Use Cases Schema

Description of Figure 6-80 follows
Description of "Figure 6-80 Fixed Length Use Cases Schema"

Table 6-12 provides the names, use case descriptions and resulting output for fixed length use cases.

Table 6-12 Fixed Length Use Cases

Num Name Use Case Description Output

1

Fixed_length_example1.xsd

Field01#Field02@Field11#Field12^! --- Only cell of Group1 has two cells of Group2. Each cell of Group2 has both the required terminated Field1 element and optional fixed length Field2. Optional fixed Field3 is missing group Group1.

 
<fo_1> 
  <Group1> 
   <Group2> 
            <Field1>Field01</Field1> 
            <Field2>Field02</Field2> 
        </Group2> 
        <Group2> 
            <Field1>Field11</Field1> 
            <Field2>Field12</Field2> 
    </Group2> 
    </Group1> 
</fo_1>








2




Fixed_length_example2.xsd




Field01! --- First cell of Group2 has required fixedLength Field01 and missing optional fixedLength Field2. Group1 has missing optional fixedLength Field3.




  <fo_1>    <Group1>    <Group2>             <Field1>Field01</Field1>      </Group2>     </Group1> </fo_1>








3




Fixed_length_example3.xsd




Field01!Field11Field02@Field21Field12^Field03!Field31! --- Group1 has 3 cells. First cell only contains the required fixedLength Field1.Second cell contains two cells of Group2. Each of the two cells contain both the fixedLength fields Field1 and Field2. second cell of Group1 also contains fixedLengthOptional Field3. Third cell of Group1 is same as first cell.




<fo_1> 
    <Group1> 
        <Group2> 
            <Field1>Field01</Field1> 
        </Group2> 
    </Group1> 
    <Group1> 
        <Group2> 
            <Field1>Field11</Field1> 
            <Field2>Field02</Field2> 
        </Group2> 
        <Group2> 
            <Field1>Field21</Field1> 
            <Field2>Field12</Field2> 
        </Group2> 
        <Field3>Field03</Field3> 
    </Group1> 
    <Group1> 
        <Group2> 
            <Field1>Field31</Field1> 
        </Group2> 
    </Group1> 
</fo_1>

















6.5.5.4 Surrounded Use Cases






Surrounded uses cases include those where the Translator looks for ".


If the trailing optional child is surrounded, it looks for pending delimiters, or if the pending delimiter does not exist, it reads the surrounded data corresponding to this optional node, bypass pending delimiters if they come before the surroundedBy delimiter, and finally generate the optional node in XML.


See Figure 6-81 for an illustration of the schema for the use cases and Table 6-13.




Figure 6-81 Shared Delimiter Surround Schema

Description of Figure 6-81 follows

Description of "Figure 6-81 Shared Delimiter Surround Schema"









Table 6-13 Surrounded Use Cases






Num
Name
Use Case Description
Output








1




Surrounded_example_1.xsd




Field01#Field02@Field11#Field12^[Field03]! --- Group1 has 1 cell comprising of repeating structure Group2 and optional surrounded Field3. Group2 has 2 cells with both the required terminated Field1 and optional surrounded Field2.




<sharedDelim>    
 <Group1>      
    <Group2>         
         <Field1>Field1</Field1>        
         <Field2>Field2</Field2>      
    </Group2>      
    <Group2>         
         <Field1>Field11</Field1>         
         <Field2>Field22</Field2>      
    </Group2>      
    <Field3>Field3</Field3>   
  </Group1> 
</sharedDelim>










2




Surrounded_example_2.xsd




Field01#@Field11#Field12^! |--- Group1 as 1 cell comprising of repeating structure Group2 and missing optional surrounded Field3. Group2 has 2 cells. First cell has the required terminated Field1 but misses the optional surrounded Field2. Second cell contains both the fields.




    <fo_1>     <Group1>         <Group2>             <Field1>Field01</Field1>         </Group2>         <Group2>             <Field1>Field11</Field1>             <Field2>Field12</Field2>         </Group2>     </Group1> </fo_1>   








3




Surrounded_example_3.xsd




Field01! --- Group1 has 1 cell comprising of 1 cell of Group2 comprising of required fixedLength Field1 and missing optional surrounded Field2. Group1 also misses optional surrounded Field2.




<fo_1> <Group1> <Group2> <Field1>Field01</Field1> </Group2> </Group1> </fo_1>









4




Surrounded_example_4.xsd




Field01!Field11-Field02-@Field21-Field12-^[Field03]!Field31!


---


Group1 has 3 cells. First cell has a cell of Group2 which contains only the required FixedLength Field1 and misses the optional surrounded Field2. Second cell of Group1 contains 2 cells of Group2 (both complete) and Field3. Third cell of Group1 is same as First.




<fo_1> 
    <Group1> 
        <Group2> 
            <Field1>Field01</Field1> 
        </Group2> 
    </Group1> 
    <Group1> 
        <Group2> 
            <Field1>Field11</Field1> 
            <Field2>Field02</Field2> 
        </Group2> 
        <Group2> 
            <Field1>Field21</Field1> 
            <Field2>Field12</Field2> 
        </Group2> 
        <Field3>Field03</Field3> 
    </Group1> 
    <Group1> 
        <Group2> 
            <Field1>Field31</Field1> 
        </Group2> 
    </Group1> 
</fo_1>

















6.5.5.5 Miscellaneous Use Cases




The following use cases are a miscellany of different types of uses of shared delimiters.







6.5.5.5.1 Shared_array_Terminator.xsd




The sample data for this shared array Terminator use case is


"Smith, John","0161-499-1717"
Fred,"0161-499-1718"#^"Smith, John","0161-499-1717"
#*



Following is the XSD for this use case:


Example - Shared Array Terminator Sample XSD


<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">
 
<element name="arrayTerminator">
  <complexType>
    <sequence>
      <element name="arrayOfMembers" maxOccurs="unbounded"
          nxsd:style="array" nxsd:cellSeparator="nonshared" nxsd:cellSeparatedBy="^"  nxsd:arrayTerminatedBy="*">
    <complexType>
      <sequence>
       <element name="Member" maxOccurs="unbounded" 
            nxsd:style="array" nxsd:arrayTerminatedBy="#" nxsd:arrayTerminator="shared">
    <complexType>
     <sequence>
      <element name="Name" type="string" nxsd:style="terminated"          nxsd:terminatedBy="," nxsd:quotedBy='"'/>
      <element name="Telephone" type="string" nxsd:style="terminated" nxsd:terminatedBy="${eol}" nxsd:quotedBy='"'/>
     </sequence>
      </complexType>
           </element>
            </sequence>
           </complexType>
      </element>
    </sequence>
  </complexType>
</element>
 
</schema>
 



The generated XML is


Example - Generated SML for Shared Array Terminator Sample


<arrayTerminator xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
   <arrayOfMembers>
      <Member>
         <Name>Smith, John</Name>
         <Telephone>0161-499-1717</Telephone>
      </Member>
      <Member>
         <Name>Fred</Name>
         <Telephone>0161-499-1718</Telephone>
      </Member>
   </arrayOfMembers>
   <arrayOfMembers>
      <Member>
         <Name>Smith, John</Name>
         <Telephone>0161-499-1717</Telephone>
      </Member>
   </arrayOfMembers>
</arrayTerminator>








6.5.5.5.2 Shared_trailing_array.xsd




The sample data for shared.trailingArray.xsd is


"Smith, John","0161-499-1717"
Fred,"0161-499-1718"^"Smith, John","0161-499-1717"
#*



The sample NXSD schema for this use case is shown below.


Example - Shared Trailing Array Sample NXSD Schema


<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">
 
<element name="trailingArray">
  <complexType>
    <sequence>
       <element name="arrayOfMembers" maxOccurs="unbounded"
                                                nxsd:style="array" nxsd:cellSeparator="shared" nxsd:cellSeparatedBy="^"  nxsd:arrayTerminatedBy="*">
      <complexType>
       <sequence>
        <element name="Member" maxOccurs="unbounded" 
                     nxsd:style="array" nxsd:arrayTerminatedBy="#"                       nxsd:arrayTerminator="shared">
       <complexType>
        <sequence>
        <element name="Name type="string" nxsd:style="terminated"               nxsd:terminatedBy="," nxsd:quotedBy='"'/>
        <element name="Telephone" type="string" nxsd:style="terminated"               nxsd:terminatedBy="${eol}" nxsd:quotedBy='"' minOccurs="0"/>
    </sequence>
    </complexType>
     </element>
       </sequence>
           </complexType>
       </element>
    </sequence>
  </complexType>
</element>
</schema>



The generated XML for this use case is shown in the example below.


Example - Generated XML for Shared Trailing Array Use Case


<trailingArray xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
   <arrayOfMembers>
      <Member>
         <Name>Smith, John</Name>
         <Telephone>0161-499-1717</Telephone>
      </Member>
      <Member>
         <Name>Fred</Name>
         <Telephone>0161-499-1718</Telephone>
      </Member>
   </arrayOfMembers>
   <arrayOfMembers>
      <Member>
         <Name>Smith, John</Name>
         <Telephone>0161-499-1717</Telephone>
      </Member>
   </arrayOfMembers>
</trailingArray>
</element>








6.5.5.5.3 Shared_trailing_OptionalArray.xsd Use Case




This shared trailingOptionalArray use case sample data is given in the following examples:


Example - Shared Trailing Optional Array Use Case Sample Data


"Smith, John","0161-499-1717"
Fred^"Smith, John","0161-499-1717"#*



Example - Shared Trailing Optional Array Use Case NXSD


<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
        targetNamespace=
         "http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"
        nxsd:stream="chars"
        nxsd:version="NXSD">
 
<element name="trailingOptionalArray">
  <complexType>
    <sequence>
        <element name="arrayOfMembers" 
                       maxOccurs="unbounded"
      nxsd:style="array" nxsd:cellSeparator=
                "shared" nxsd:cellSeparatedBy="^"              nxsd:arrayTerminatedBy="*">
          <complexType>
            <sequence>
                <element name="Member" 
                             maxOccurs="unbounded" 
                  nxsd:style="array" 
                 nxsd:arrayTerminatedBy="#" 
                 nxsd:arrayTerminator="shared">
                   <complexType>
                      <sequence>
                      <element name=
                        "Name" type="string"
                   nxsd:style="terminated" 
                   nxsd:terminatedBy="," 
                   nxsd:quotedBy='"'/>  
                      <element name="Telephone"
                      type="string"
                      nxsd:style="terminated"
                      nxsd:terminatedBy="${eol}"                       nxsd:quotedBy='"' minOccurs="0"/>
                        </sequence>
                      </complexType>
                       </element>
                       </sequence>
                        </complexType>
                  </element>
    </sequence>
  </complexType>
</element>
</schema>



Example - Generated XML for the Shared Trailing Optional Array Use Case


 <trailingOptionalArray xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
   <arrayOfMembers>
      <Member>
         <Name>Smith, John</Name>
         <Telephone>0161-499-1717</Telephone>
      </Member>
      <Member>
         <Name>Fred</Name>
      </Member>
   </arrayOfMembers>
   <arrayOfMembers>
      <Member>
         <Name>Smith, John</Name>
         <Telephone>0161-499-1717</Telephone>
      </Member>
   </arrayOfMembers>
</trailingOptionalArray>