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:
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
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."
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 (#).
This option enables you to create native schemas for records, where all fields are of fixed lengths.
This option enables you to create native schema for records, where the fields may themselves be records having multiple delimiter types.
This option enables you to generate native schema from the user-supplied DTD, which contains information about the structure of an XML document.
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>
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
.
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 |
---|---|---|---|---|
|
|
|
|
Alphanumeric – An allowable character from the character set of the computer. Each X corresponds to one byte. |
|
|
|
|
Alphabetic – Any letter of the alphabet or space. Each A corresponds to one byte. |
|
|
|
|
Any character position that contains a numeral. Each nine is counted in the size of the item. |
|
|
|
Fixed-length array |
|
|
|
|
For |
|
|
|
|
Allows the same computer memory area to be described by different data items. |
|
|
|
|
Size = |
|
|
|
|
NA |
|
|
|
|
Ignored |
|
|
N |
N |
This is rarely seen in COBOL Copybooks |
|
|
N |
N |
Four-byte index |
|
|
|
I |
|
NA |
|
|
|
NA |
|
|
NA |
|||
|
|
|
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 |
---|---|---|---|---|
|
Y |
Y |
Both these keywords are optional. |
|
|
Y |
Y |
|
Length varies with
|
|
Y |
Y |
|
Single precision, floating point number that is four bytes long. |
|
|
|
|
Double precision, floating point number that is eight bytes long. |
|
|
|
|
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. |
|
|
|
|
Treated the same as a |
|
|
|
Capacity of the native binary representation. |
|
|
|
|
|
Sign nibble in the rightmost zone by default. |
|
|
|
Same as |
|
|
|
|
NA |
|
|
|
|
Length is the same as |
|
|
|
|
Length = |
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.
Edited Pictures | Supported Editing Types | Unsupported Editing Types |
---|---|---|
Edited alphanumeric |
Simple Insertion: B(blank) |
|
Edited float numeric |
Special insertion: |
|
Edited numeric |
|
|
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.
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 can not 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
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.
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:
Table 6-4 shows the constructs applicable only on the
<schema>
tag.
Table 6-4 Constructs Applicable Only on the <schema> Tag
Construct | Description |
---|---|
The byte order of the native data as |
|
The encoding in which the actual data is stored. UTF-8 is typically recommended for interoperability and Unicode support. You can specify any legal encoding supported by the Java runtime environment. For a complete listing of supported encodings, visit |
|
A positive integer specifying the number of lines to be skipped, before translating the native data. |
|
Skip until the specified string, before translating the native data. |
|
If declared, adds the standalone attribute in the XML declaration prolog of the translated XML, with the actual value as that specified in |
|
Whether the data is stored as characters or bytes. Allowed values are |
|
String specifying the unique message separator in the native data, in case of a batch of messages. |
|
The type of native data. Possible values are |
|
If declared, adds the XML declaration prolog to the translated XML with the actual value as that specified in |
|
String specifying the header value to be inserted in the outbound message. |
|
Integer specifying the number of lines to process in the native file. |
|
If set to Note: The field |
|
If set to |
|
If set to |
|
If set to |
|
If set to |
|
If set to |
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 |
---|---|
The length of the array being stored in the native data occupying the specified length |
|
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 nxsd:style="array" nxsd:arrayLength="10" This indicates that the array length is |
|
The last item in the array being terminated by the specified string |
|
Assigns a value to the variable that is declared |
|
The cells of the array in the native data being separated by the specified string |
|
Either |
|
Matches the string read from the native stream for the |
|
|
The value specified in this construct is used to translate only a portion of the data and not the entire data. |
A valid Java date format representing the date in the native data |
|
The number of characters and bytes in which the actual length of the data is stored |
|
The items in the list being separated by the specified string |
|
The native data surrounded |
|
The length of the native data to be read. Used with fixed-length style. |
|
The last item in the list being terminated by the specified string |
|
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 |
|
The string used for padding |
|
|
|
The native data being quoted by the specified string. By default, the specified string is |
|
Skips the specified number of bytes or characters |
|
Skips the number of lines specified |
|
Skips until the string specified |
|
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. |
|
The style used to read the native data from the input stream. Allowed values are |
|
The native data being surrounded by the specified string |
|
The native data being terminated by the string specified |
|
Declares a single variable |
|
Declares a set of variables or assigns the declared variables a valid value |
This section includes the following topics:
Section 6.2.2.15, "Defining Complex Condition in conditionValue"
Section 6.2.2.16, "Defining Complex Condition in choiceCondition"
Section 6.2.2.19, "Implementing Validation During Translation"
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
<?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>
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 "
("
). 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="""/> <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
<?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 "
("
), the Oracle File Adapter will fail 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 will not be part of the data for this field. In this example, we override the default nxsd:quotedBy
terminating mark to <
(<
) because we know that this character will never appear in field two:
<element name="FieldTwo" type="string" nxsd:style="terminated" nxsd:terminatedBy="," nxsd:quotedBy="<"/>
By contrast, for field three, we need 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="<"/> <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>
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>
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)
All Items Separated by the Same Mark, Including the Last Item (Unbounded)
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
<?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;
<?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>
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)
All Cells Separated by the Same Mark, Including the Last Cell (Unbounded)
Cells Not Separated by Any Mark, but the Last Cell Terminated by a Mark (Bounded)
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.#
<?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.
<?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 #
<?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
<?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>
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;
<?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>
This section provides the following examples of conditional processing:
Processing One Element Within a Choice Model Group Based on the Condition
Processing Elements Within a Sequence Model Group Based on the Condition
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
<?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
<?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>
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
<?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
<?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>
<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>
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
<?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=""" /> <element name="Address" type="string" nxsd:style="terminated" nxsd:terminatedBy="${var1}" nxsd:quotedBy="""/> <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>
In native format, when data is read, the specified data is prefixed, suffixed, or both, as shown in the following example.
Fred, "2 Old Street, Old Town,Manchester","20-08-1954",0161-499-1718
<?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=""" /> <element name="Address" type="string" nxsd:suffixWith="]]" nxsd:prefixWith="[[" 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="${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>
Translator skips, before or after the data is read, depending on the skipMode
construct, as shown in the following example:
Fred, "2 Old Street, Old Town,Manchester","20-08-1954",0161-499-1718
<?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=""" /> <element name="Address" type="string" nxsd:skipMode="before" nxsd:skip="3" nxsd:style="terminated" nxsd:terminatedBy="," nxsd:quotedBy="""/> <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>
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.
Fred,"2 Old Street, Old Town,Manchester","20-08-1954","0161-499-1718"
<?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=""" /> <element name="Age" type="string" fixed="16" /> <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="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>
The write
construct writes the literal at the current position in the output stream, either before writing the actual data or after writing it.
<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>
<?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=""" /> <element name="Address" type="string" nxsd:writeMode="after" nxsd:write="Over." 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="${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
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
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
<?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=""" /> <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> </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>
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
<?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>
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.<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>
<?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=""" /> <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="${eol}" nxsd:quotedBy='"'/> </sequence> </complexType> </element> </schema>
This is a header Fred,"2 Old Street, Old Town,Manchester",20-08-1954,0161-499-1718
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
<?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="""> </xsd:element> <xsd:element name="C2" type="xsd:string" nxsd:style="terminated" nxsd:terminatedBy="${eol}" nxsd:quotedBy="""> </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="""> </xsd:element> <xsd:element name="C2" type="xsd:string" nxsd:style="terminated" nxsd:terminatedBy="," nxsd:quotedBy="""> </xsd:element> <xsd:element name="C3" type="xsd:string" nxsd:style="terminated" nxsd:terminatedBy="${eol}" nxsd:quotedBy="""> </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="""> </xsd:element> <xsd:element name="C2" type="xsd:string" nxsd:style="terminated" nxsd:terminatedBy="${eol}" nxsd:quotedBy="""> </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>
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
<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>
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
<?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>
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
<?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>
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:
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 following levels:
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" >
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" >
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:
Thenxsd:validateNxsd="true"
validation flag does not affect payload level validations.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>
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:
This section describes the terminologies that you must understand for using translation XPath functions.
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 (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.
A translator may be required while reading and writing files. This section discusses the following translator XPath functions:
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:
|
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
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>
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>
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>
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
Define the base64-encoded element in the schema of the BPEL process, as follows:
<schema targerNamespace="…"> <element name="mtomElement" type="base64Binary"/> </schema>
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>
Assign the source file path that you need to 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
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>
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>
Assign the CSV data that you need to translate, as follows:
<assign name="assignCSVData">
<copy>
<from expression="'this, is, csv, data…'"/>
<to variable="csv_data"/>
</copy>
</assign>
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>
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:
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>
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>
Assign the CSV data that you need to 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.
The doTranslateToNative
XPath function translates an input DOM into string data or an attachment.
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:
|
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 needs to 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
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>
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>
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>
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:
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>
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>
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.
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.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. |
This section discusses the following features of batching transformation:
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:
Splitting the source document into multiple batches of one or more records
Performing the XSLT transformation one batch at a time
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
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
Define attachmentElement, as shown:
<schema targerNamespace="…"> <element name="attachmentElement"> <complexType> <attribute name="href" type="string"/> </complexType> </element> </schema>
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>
This section describes the following use cases:
Section 6.4.1, "Defining the Schema for a Delimited File Structure"
Section 6.4.2, "Defining the Schema for a Fixed Length File Structure"
Section 6.4.3, "Defining the Schema for a Complex File Structure"
Section 6.4.4, "Removing or Adding Namespaces to XML with No Namespace"
Section 6.4.5, "Defining the Choice Condition Schema for a Complex File Structure"
Section 6.4.6, "Defining Choice Condition With LookAhead for a Complex File Structure"
Section 6.4.7, "Defining Array Type Schema for a Complex File Structure"
Section 6.4.8, "Defining the Schema for a DTD File Structure"
Section 6.4.9, "Defining the Schema for a COBOL Copybook File Structure"
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.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:
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
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
The Native Format Builder Welcome page is displayed, as shown in Figure 6-5.
Figure 6-5 Native Format Builder Wizard Welcome Page
Click Next. The Choose Type page is displayed, as shown in Figure 6-6.
Figure 6-6 Native Format Builder Wizard Choose Type Page
Click Next. The Native Format Builder File Description page is displayed.
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
Click Next. The Record Organization page is displayed, as shown in Figure 6-8.
Figure 6-8 Native Format Builder Wizard Record Organization Page
Select File contains multiple record instances, then select Multiple records are of single type, and then click Next. The Specify Elements page is displayed.
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
Click Next. The Specify Delimiters page is displayed, as shown in Figure 6-10.
Figure 6-10 Native Format Builder Wizard Specify Delimiters Page
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
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
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=""" /> <xsd:element name="Street1" type="xsd:string" nxsd:style="terminated" nxsd:terminatedBy="," nxsd:quotedBy=""" /> <xsd:element name="Street2" type="xsd:string" nxsd:style="terminated" nxsd:terminatedBy="," nxsd:quotedBy=""" /> <xsd:element name="City" type="xsd:string" nxsd:style="terminated" nxsd:terminatedBy="," nxsd:quotedBy=""" /> <xsd:element name="State" type="xsd:string" nxsd:style="terminated" nxsd:terminatedBy="," nxsd:quotedBy=""" /> <xsd:element name="Country" type="xsd:string" nxsd:style="terminated" nxsd:terminatedBy="${eol}" nxsd:quotedBy=""" /> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema>
Click Test. The Test NXSD Schema dialog is displayed, as shown in Figure 6-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.
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>
Click OK. The Generated Native Format Schema File page is displayed, as shown in Figure 6-12.
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
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
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
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.
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:
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
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
.
Click Next. The Choose Type page is displayed.
Select Fixed Length as the file type, as shown in Figure 6-17.
Figure 6-17 Native Format Builder Wizard Choose Type Page
Click Next. The Native Format Builder File Description page is displayed.
Click Browse and select the address.txt
file, as displayed in Figure 6-18.
Figure 6-18 Native Format Builder Wizard File Description Page
Click Next. The Record Organization page is displayed, as shown in Figure 6-19.
Figure 6-19 Native Format Builder Wizard Record Organization Page
Select Multiple records are of single type, and click Next. The Specify Elements page is displayed.
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
Click Next. The Field Lengths for Multiple Record Files page is displayed.
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
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
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
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>
Click Test. The Test NXSD Schema dialog is displayed, as shown in Figure 6-24.
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.
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>
Click OK. The Generated Native Format File page is displayed, as shown in Figure 6-23.
Click Next. The Native Format Builder Finish page is displayed, as shown in Figure 6-15.
Click Finish. The Adapter Configuration Wizard Messages page is displayed, as shown in Figure 6-16, that contains the generated NXSD.
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:
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
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
.
Click Next. The Choose Type page is displayed, as shown in Figure 6-26.
Figure 6-26 Native Format Builder Wizard Choose Type Page
Select Complex Type (Contains records whose fields may themselves be records having multiple delimiter types).
Click Next. The Native Format Builder File Description page is displayed.
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
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
Create the partner-type Complex Type
The schema structure that you can build using the invoice.txt
sample is as follows:
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.
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
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.
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
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.Enter id, name, and address in the Name field, as shown in Figure 6-31.
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.
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.
Click OK. The Complex Type Details dialog is displayed with the field properties that you selected.
Verify or edit the field properties for id
and address
Name fields.
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
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.
Create another <new_complex_type> node in the Schema Tree. See Step 1 in Create the partner-type Complex Type
.
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.
Enter address-type in the Complex Type Name field.
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
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
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.
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
Create 'buyer' and 'seller' Global Elements
Select Invoice, and click the Add Element icon. An element, <new_element>
, is created in the Schema Tree under the root element, Invoice.
Rename it to buyer.
Again, select Invoice, and click the Add Element icon. An element, <new_element>
, is created in the Schema Tree under Invoice.
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
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.
Select Invoice, and click the Add Element icon. An element, <new_element>
, is created in the Schema Tree under Invoice.
Rename it to items.
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
Drag and drop item-type complex type to the items element to assign item-type to this element.
Select items - item-type and click the pencil icon. The Element Details dialog is displayed.
Set the following properties in the Element Details dialog, as shown in Figure 6-40:
Set Max. Occurence - UNBOUNDED
Select Array. The Cell Separator and Array Separator are enabled.
Set Cell Separator - ${eol}
Set Array Separator - #
Note:
The elementitems
is defined as an array of item-type
.Click OK.
Create the invoice-total element, and drag and drop the sample text (110000) on the <new_element> node. The Element Details dialog is displayed.
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
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.
Click OK in the Alert message. The Element Details dialog is displayed.
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
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
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>
Click Test. The Test NXSD Schema dialog is displayed, as shown in Figure 6-44.
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
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>
Click OK. The Generated Native Format File page is displayed, as shown in Figure 6-43.
Click Next. The Native Format Builder Finish page is displayed, as shown in Figure 6-15.
Click Finish. The Adapter Configuration Wizard Messages page is displayed, containing the generated NXSD, as shown in Figure 6-16.
When the native data is XML and that XML has no namespace, the Native Format Translator can be used 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 thatelementFormDefault="qualified"
is specified in the actual schema.Using this wrapper.xsd
file in place of the original .xsd
file would add the myNamespace
namespace to the inbound XML and would remove the myNamespace
namespace from the outbound XML.
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:
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
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
Click Add Choice Node. The Choice Option Type dialog is displayed.
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
Select choice and click the Add Element icon. A <new_element> is added to the choice node.
Rename the newly added element to OrderChoice, and then drag and drop the OrderType complex type element to OrderChoice.
Select OrderChoice - string and click the Edit Node icon. The Element Details dialog is displayed.
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.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
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
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>
Click Test. The Test NXSD Schema dialog is displayed.
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.
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>
Click OK. The Generated Native Format File page is displayed.
Click Next. The Native Format Builder Finish page is displayed.
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:
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
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.
Click Next. The Choose Type page is displayed.
Select Complex Type and click Next. The Native Format Builder File Description page is displayed.
Click Browse and select the address.txt file, and enter Address in the Root Element field.
Click Next. The Native Format Builder Design Schema page is displayed.
Click the Add Complex Type icon. A Complex Type, <new_complex_type> is created in the Schema Tree under Address.
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.
Enter RECORD1
in the Complex Type Name field and select Comma (,) in the Delimited By list.
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
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
Click Add Choice Node. The Choice Option Type dialog is displayed.
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
Select choice and click the Add Element icon. A <new_element> is added to the choice node.
Click the Edit Node icon. The Element Details dialog is displayed.
Enter RECONE
in the Element Name field and select RECORD1 as the Data Type set choice condition as "YES", and then click OK.
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 need to 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
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.
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
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>
Click Test. The Test NXSD Schema dialog is displayed.
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.
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.Click OK. The Generated Native Format File page is displayed.
Click Next. The Native Format Builder Finish page is displayed.
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:
The data in a sample text file, array.txt, appears as below:
John;Steve;Paul;Todd.
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.
Click Next. The Choose Type page is displayed.
Select Complex Type and click Next. The Native Format Builder File Description page is displayed.
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
Click Next. The Native Format Builder Design Schema Page is displayed.
Create a global element called NewArray and drag and drop the native data to the newly created global element.
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
Set the options in the Element Details dialog, as shown in Figure 6-60, and then click OK.
The Native Format Builder Design Schema dialog is displayed.
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
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>
Click Test. The Test NXSD Schema dialog is displayed.
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.
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>
Click OK. The Generated Native Format File page is displayed.
Click Next. The Native Format Builder Finish page is displayed.
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:
Use any DTD file.
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
.
Click Next. The Choose Type page is displayed, as shown in Figure 6-26.
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
Click Next. The Native Format Builder DTD Description page is displayed.
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
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
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>
Click Next. The Native Format Builder Finish page is displayed.
Click Finish. The Adapter Configuration Wizard Messages page is displayed containing the generated NXSD.
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:
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:
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
The Adapters-105CobolCopyBook
sample is available at the following location:
http://www.oracle.com/technology/sample_code/products/adapters
Copy these files to your samples directory.
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
.
Click Next. The Choose Type page is displayed, as shown in Figure 6-26.
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
Click Next. The Native Format Builder Cobol Copybook Description page is displayed.
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
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
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>
Click Test. The Test NXSD Schema dialog is displayed.
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.
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.
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.
Click OK. The Generated Native Format File page is displayed.
Click Next. The Native Format Builder Finish page is displayed.
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>
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>
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, then the generated schema requires modification.