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 Oracle BPEL Process Manager (Oracle BPEL PM), or Oracle Mediator (Mediator). 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 Section 6.1.2, "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 run-time 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 run-time 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>

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.

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 Run-Time 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 rightmost 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 Run-Time 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 rightmost 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.

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.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.

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 run-time 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".

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 valid 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".

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

This format applies to lists with the following characteristics:

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>

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:

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>

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>

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>

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>

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

This section provides the following examples of conditional processing:

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
Websphere 025070,000.00
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>Websphere </Id>
            <Quantity>50</Quantity>
            <Price>70,000.00</Price>
         </Line-Item>
         <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>

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
Websphere 025070,000.00
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>Websphere </Id>
            <Quantity>50</Quantity>
            <Price>70,000.00</Price>
         </Line-Item>
         <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 example shows how to define dates.

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

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.

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.

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>

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 lookAhead Strategies for Conditional Processing of Record using RegEx Expressions

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

The Native Format Builder understands inbound native data it translates in terms of characters. The translator internally uses character data.

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.

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

To solve this, the translator supports specxifying the length of the field in terms of bytes. You can specify the length unit as either Byte or Char. The default value is Char. To specify this, use the following convention:

nxsd:lengthUnits="Byte|Char"

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

6.2.3.1 Specifying Padded Data

You can also specify padded data. When you do this,the translator strips off all the occurrences of padded data. To do this, you must let the translator know the format of the padded Byte data it will be stripping off.

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

See the following table for a description of the padded Data Type formats.

Format Description
Decimal Padded data specified is in decimal format. You must specify the decimal 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, 001002, 01213 represent additional bytes as padded data.
Binary Padded data specified is in Binary format. You need to 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, 001001100, 01010101.
Oct Padded data specified is in Octal format. You need to 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, 064, 070, 246.
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, AE, 07 .
string Padded data specified is in String format. Translator would use the encoding specified at schema level (nxsd:encoding).

6.2.3.2 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.3 Translator Behavior

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.

If the input stream does not contain sufficient data, the notEnoughData exception is raised.

Once theTranslator 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 Characterfor any reason, 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.4 SOSI Support

TheTranslator 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.2.3.5 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, theTranslator first removes any prefix or suffix (if present). 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, Translator adds the paddedBy data bytes at the start or end of generated bytes as specified in schema.

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 decides 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 Example 6-4 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 6-1 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 6-2 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 6-3 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 6-4 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:

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 decides 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 Example 6-6 for more details.
attachmentElement This parameter is optional. This is the attachment to which the translated data is written.

Example 6-5 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 6-6 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?')

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 SDOM or an Attachment element.
streamingXpathContext DOM representing the XPath context.
targetType This parameter decides 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.

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

<schema  targetNamespace="…">
    <element name="streamingcontext">
        complexType>
            <sequence>
                <element name="sourceSchema" type="string"/>
                <element name="sourceRootElement" type="string"/>
                <element name="sourceType" 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>

In context:

Schema Element Description
sourceSchema Source NXSD schema used to translate a native data to XML.
sourceRootElement Name of root element in source NXSD schema.
sourceType Set this to either xml or native depending on the input data.
xsl Relative path of the XSL file.
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

Example 6-7 implements the FlatStructure FileAdapter 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 6-7 Using Streaming Transformation XPath Function

  1. Define attachmentElement, as shown:

    <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.

      <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 Section 6.2.2.2, "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, appears as below:

    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 will represent 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.

    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 Section 6.2.2.2, "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, appears as below:

    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 will represent 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.

    <?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 the following 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, appears as below:

    6335722^Company One^First Street   999       San Jose       95129USCA650-801-6250
       ^Oracle^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.

  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 tries to interpret 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 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 so on.

  1. Create another <new_complex_type> 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, <new_complex_type>. 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 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.

    • 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.

    Now, 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. Occurence - 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:

    <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 looks as follows:

    <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, appears as below:

    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 Section 6.4.3, "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 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/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 looks as follows:

    <?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, appears as below:

    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 chars "NO", since you must match the total no. 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:

    <?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 looks as follows:

    <?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, appears as below:

    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 following is the sample native schema that is generated:

    <?xml version="1.0" encoding="UTF-8" ?>
<!--This Schema has been generated from a DTD. A target namespace has been
added 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:

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 run-time 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).

    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:

    <?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.

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:

<?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>

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 looks as follows: 

<?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>

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 looks as follows: 

<?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 the 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 run-time 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 below. 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"