webMethods Flat File新手指南

需积分: 10 146 浏览量更新于2024-07-16 收藏 1.4MB PDF 举报

"WebMethods Flat File用户指南是针对WebMethods Flat File操作的手册，特别适合新手学习，涵盖了WebMethods在企业应用集成（EAI）、电子数据交换（EDI）和B2B（Business-to-Business）领域的应用。" 在WebMethods平台中，FlatFileSchema是核心组件之一，它用于处理和解析平面文件，这些文件在集成不同系统时非常常见，特别是在与那些使用非结构化或半结构化数据格式的系统交互时。平面文件可以是CSV、XML或其他自定义格式，WebMethods Flat File模块提供了一种灵活的方式来定义、读取和写入这些文件。在WebMethods Integration Server的上下文中，Flat File Schema开发者指南，版本6.5，服务包2，提供了关于如何设计和操作平面文件模式的详细指导。该指南可能包括以下内容： 1. **Flat File Schema设计**：介绍如何创建和配置平面文件模式，以定义文件的结构，包括字段类型、长度、顺序和分隔符等。 2. **数据转换**：阐述如何在WebMethods中将平面文件数据转换为其他格式（如XML），以便进一步处理或与其他系统交换。 3. **错误处理**：讲解如何处理解析或生成平面文件时可能出现的错误，包括验证规则和异常管理。 4. **集成实践**：展示如何在webMethods Broker、webMethods Developer、webMethods Fabric等工具中使用Flat File Schema进行实际集成项目。 5. **性能优化**：提供有关提高处理大量平面文件效率的建议和策略。 6. **WebMethods组件的配合使用**：解释如何与webMethods的其他组件，如webMethods Access、webMethods Monitor、webMethods Workflow等协同工作，以实现全面的企业级解决方案。 7. **API和脚本支持**：可能涵盖如何通过编程接口（API）或脚本语言与Flat File Schema交互，以自动化特定任务或扩展功能。 8. **案例研究和示例**：可能包含实际应用场景的示例，帮助读者理解概念并应用于实际工作中。 9. **第三方集成**：可能会提到与其他公司产品（如Adobe Acrobat/Reader、Amdocs ClarifyCRM、Ariba、BEA WebLogic Server等）的集成，以及如何利用这些工具增强WebMethods平台的功能。 10. **故障排查和维护**：提供了解决常见问题的方法，以及定期维护和升级Flat File Schema的指导。这份用户指南对于那些需要处理平面文件数据并在WebMethods环境中进行集成工作的开发人员和管理员来说，是非常宝贵的资源。通过深入学习，用户将能够熟练掌握平面文件处理，从而更有效地实现企业系统的集成和数据交换。

CHAPTER 1 Concepts

16    Flat File Schema Developer’s Guide Version 6.5, Service Pack 2

equivalents when processing Asian characters. Another example is the use of Unicode

combining and pre–composed sequences. In all cases, fields are matched using a strict

binary comparison of Unicode character values in the separate fields.

You also should exercise care when selecting the encoding of the file being processed.

Some encodings are very similar to one another. For example, the Shift–JIS and MS932

encodings commonly used with Japanese language text are very similar, but they map

some characters differently. This can result in the WmFlatFile package not finding a

match where you otherwise would expect one to exist.

Extractors

Extractors take data out of a parsed record and place it in the output of the

pub.flatFile:convertToValues service. If extractors are not defined in the flat file schema, the

parser returns a series of records that contain no fields or composites.

Fields and composites are extracted from a record based on the position of the field

delimiter. From the beginning of the record to the first field delimiter is the first field in

the record. From the first field delimiter to the second field delimiter is the second field in

the record, and so on. Everything from the last field delimiter to the record delimiter (the

end of the record) is considered part of the final field.

Fields also can be extracted from a record based on a substring of the original record

starting at a particular byte count and ending at a particular byte count. The user specifies

the start of the field by specifying the number of bytes from the beginning of the record to

the start of the field and specifying the number of bytes from the beginning of the record

to the end of the field.

If a value is a composite, it is simply a field that can be further parsed into more fields.

Instead of a field delimiter, a subfield delimiter is used to separate a composite into fields.

Fields are extracted from a composite based on either the position of the subfield delimiter

in the composite or on a substring of the composite. Remember that all positions used in

extracting fields from a composite are referenced from the beginning of the composite, not

the start of the record.

Undefined Data

In some cases, the data resulting from the pub.flatFile:convertToValues service might contain

records that were not recognized, known as undefined data. This could be a result of the

complexity of the flat file, or of the lack of detail in the flat file schema (such as no record

identifier). When the convertToValues service processes an unrecognized record, it puts a

placeholder named unDefData in the resulting IS document (IData object) and stores the

record as a string in the pipeline.

Note: Although fixed length and variable length record parsers do not use record

delimiters, they can have field delimiters.

How Is a Flat File Schema Used to Parse Records?

Flat File Schema Developer’s Guide Version 6.5, Service Pack 2    17

You can select a default record when creating a flat file schema. Any record that cannot be

recognized will be parsed using this default record. If a default record is not selected,

unrecognized records will be placed into the output IS document with the undefined data

tag, which might produce errors.

For some types of documents, undefined data should not be allowed in the document and

if encountered should generate validation errors in the output. In other cases, undefined

data is expected and should not generate validation errors. In still other cases, all

unidentified records should be parsed using a default record definition, as described in

“Default Records” on page 18.

You can choose whether you want errors to be generated for a flat file schema when

undefined data is encountered. You do so using a combination of two fields:

 The Allow Undefined Data check box on the Settings tab

 The Allow Undefined Data check box for each record in the flat file schema on the Flat File

Structure tab

When the Allow Undefined Data check box on the Settings tab is selected, which it is not the

default, and the Allow Undefined Data check box for a particular record is selected, no errors

will be generated if the record contains undefined data. If either the Allow Undefined Data

check box on the Settings tab or the Allow Undefined Data check box for a particular record is

cleared, errors will be generated if the record contains undefined data.

Working with undefined data involves three steps:

1 Configuring the flat file schema and record–level Allow Undefined Data settings.

2 Ignoring undefined data, OR parsing the undefined data in each record based on the

document structure.

3 Writing logic to handle the parsed data, such as logic to map the parsed data to

another service or perform error handling.

Note: If the file is encoded using a multi-byte encoding, and if you use a fixed length or

variable length parser (running on JVM version 1.4 or later), the service puts two

placeholders into the pipeline: unDefData and unDefBytes.

Note: If your flat file does not contain record identifiers, you must select a default record.

By selecting a default record, a CSV (comma separated values) file can be parsed as a

special case of record with no record identifier, but with fixed field and record delimiters.

CHAPTER 1 Concepts

18    Flat File Schema Developer’s Guide Version 6.5, Service Pack 2

Default Records

If the pub.flatFile:convertToValues service cannot recognize a record (for example, the record

does not have a record identifier), the record will be treated as undefined data unless you

specify a default record definition to be used to parse all unrecognized records of a

particular type. In fact, if your flat file schema does not contain any record identifiers, you

must specify a default record. A default record can only be defined in a flat file dictionary.

For example, if you have a CSV (comma separated values) flat file that simply lists the

name, address, and phone number of a group of customers, none of the records would

have a record identifier:

John Doe, 123 Main St Washington DC, 888–555–1111;

Jane Smith, 321 Oak Dr Memphis TN, 800

–555–2222;

If you specified a default record definition to parse this particular type of record, the file

can be properly parsed and converted to an IS document (IData object) of the name

recordWithNoID. By default, each recordWithNoID record appears as a child of the record

above it, in an array. To modify this default behavior, see “Customizing the Flat File

Configuration Settings” on page 74.

If a default record has not been specified, the record will be treated as undefined data, as

described in “Undefined Data” on page 16.

What Is a Flat File Dictionary?

A flat file schema can contain either record definitions or references to record definitions

that are stored elsewhere in the namespace in a flat file dictionary. A flat file dictionary is

simply a repository for elements that you reference from flat file schemas. This allows you

to create record definitions in a dictionary that can be used across multiple flat file

schemas. Reusing record definitions reduces the amount of memory consumed by a flat

file schema.

Flat file dictionaries are created as namespace elements in the Integration Server and

contain definitions of records, composites, and fields. When you change a definition in a

flat file dictionary that is referenced in multiple flat file schemas, the element definition is

updated automatically in all of the flat file schemas.

When creating an element definition in a flat file dictionary, you specify only certain

properties. You then specify the remaining properties in the instance of the element

definition in a particular flat file schema.

For an example of how to build a flat file dictionary, see the Flat File Tutorial in the

WmFlatFileSamples package. This package is located in the Knowledge Base on the

Advantage Web site.

Note: You can reference a flat file dictionary definition in any flat file schema regardless of

whether the dictionary and schema are located in the same package.

When Should I Create a Flat File Dictionary?

Flat File Schema Developer’s Guide Version 6.5, Service Pack 2    19

When Should I Create a Flat File Dictionary?

The decision to define records in a flat file dictionary versus in a flat file schema depends

on the type of flat files that you intend to parse. The Electronic Document Interchange

(EDI) ANSI X12 standard defines a large set of document structures that reuse the same

record, field, and composite definitions many times. Defining these records, fields, and

composites in a dictionary allows for them to be reused throughout the entire set of EDI

ANSI X12 document flat file schemas. Reusing definitions reduces the amount of memory

consumed by the webMethods Integration Server.

EDI ANSI X12 also has different versions of these documents (for example, 4010). Each

version of the document set should have its own dictionary. In this way, you can be certain

that changes to a record, field, or composite between versions are maintained.

A more complex scenario would involve multiple families of documents and multiple

versions of those families. An example of this is EDI ANSI X12 and UN/EDIFACT

documents. One dictionary should be created for each version of EDI ANSI X12

documents and one dictionary should be created for each version of EDI UN/EDIFACT

documents. A separate dictionary would not be required for each flat file schema in the

same version. All flat file schemas in one version of the same family should use the same

dictionary.

In a scenario in which you intend to parse only one flat file, or flat files that do not share

record, composite, or field definitions, you can define these elements directly in the flat

file schema. This allows for the entire document to be edited in a single view, without

referencing a flat file dictionary.

If a clear choice does not exist between these two scenarios, the best approach is to create

the definitions in the flat file dictionary and reference them in a flat file schema. The

definitions then can be reused at a later time.

剩余151页未读，继续阅读

EvanTan

粉丝: 1
资源: 7

webMethods Flat File新手指南

EDI webmethods user Guide

webMethods Developer Users Guide

webMethods Integration Server Clustering Guide 6.5

webMethods Advanced Troubleshooting Guide

webMethods Developer Guide

webMethods Adapter Development Kit Installation Guide

webmethods api

webmethods sftp client

webMethods Administrator workshop

Webmethods EAI 工具

最新资源