EDI子系统开发流程

EDI子系统开发流程

1. EDI架构介绍

1.1. 在FOCUS系统中的位置划分

EDI子系统是FOCUS系统和外部系统进行数据交换的接口，负责生成/接收符合一定格式要求的数据文件（报文）。在生成报文的时候，出于FOCUS系统业务流程的末尾；在接收报文的时候，处于FOCUS系统业务流程的开始。

1.2. EDI子系统模块划分

EDI子系统可以分为： Command、YakInterface（接口）、WPG、YakFront（前置机）及部分。其中Command是按照FOCUS系统的Command接口要求完成的，用来与客户端进行交互的部分；YakInterface为EDI子系统的核心部分，完成接收业务数据、业务规则校验、代码翻译、日志管理；WPG为第三方中间件，主要用来完成报文格式的转换工作；YakFront为EDI子系统的前置机，完成报文中字符的特殊处理和报文的发送、接收。

1.2.1. EDI子系统的物理架构

船公司AppServerEDI ServerGUIClientBrowserDB前置机船代系统其他外部系统其中EDI Server既是EDI子系统。

1

1.2.2. EDI子系统发送EDI报文业务流程

EDI文件传递方向代码翻译程序EDI打包程序客户①客户EDIXML客户端应用程序服务器XMLEDI客户EDI④④④业务人员②。。。EDI③EDI④前置机EDI服务器客户文件生成&分发程序其中各步骤的过程为：

① 业务员将要生成EDI文件的XML格式的数据上传到应用程序服务器；

②（业务处理YakInterface） 应用程序服务器通过“EDI打包程序”和“代码翻译程序”，将收到的XML格式的数据转换为XML格式的EDI报文，发送到EDI服务器；

③（映射、WPG格式转换） EDI服务器将收到的XML格式的报文转换为EDI文件,并附上说明信息，通过数据流发送到前置机上或应用程序服务器上，应用程序服务器再将EDI数据流发送到客户端；

④ （前置机业务处理YakFront）前置机上的“文件生成&分发程序”将接收到的EDI数据流转换为EDI文件，并根据附加信息分发给不同的客户，或客户端的“文件生成程序”将接收到的EDI数据流转换为EDI文件，并通过E-Mail或其它方式发送。

2

1.2.3. EDI子系统接收EDI报文业务流程

报文传递方向代码翻译程序EDI解包程序客户Email或其他方式⑤EDI查询④DataEDI查询结果客户EDI客户端①业务人员⑥应用程序服务器XML数据库服务器EDI客户EDI①①①①③。。。EDI②EDI前置机EDI服务器客户监视&发送程序EDI校验程序其中各步骤的过程如下：

① 客户将EDI文件上传到前置机或通过E-Mail等方式发送给业务人员，再由业务人员上传到前置机；

② 前置机上的“监视&发送程序”将接收到的EDI文件直接传送到EDI服务器进行解包；（前置机处理）

③ EDI服务器上的“格式自动识别程序”和“EDI校验程序”对EDI文件进行预处理，经过预处理的EDI文件通过格式转换，生成XML格式的报文，发送到应用程序服务器；（WPG映射处理）

④ 应用程序服务器通过“EDI解包程序”和“代码翻译程序”，将收到的XML格式的报文转换为XML格式的数据包，发送到客户端或存入数据库；（YakInterface）

1.3. Command

主要与客户端进行交互，完成与业务操作相关的发送EDI的准备，并生成符合

YakInterface要求的数据，在该Command中调用Agent来完成相应的生成、发送报文的操作。包括EDICommand和商务相关的Command。

EDICommand主要完成发送订舱单、提单确认、装箱单三种类型报文的发送工作。根据不同的报文类型，EDICommand对业务数据（主要是委托以及相关的数据）进行重新整理，生成符合EDI子系统（YakInterface）要求的报文（MessageObject）。商务相关的Command

3

在商务子系统中完成，用来生成SAP和用友的财务接口文件。

在FOCUS系统中，启动时会自动加载EDI子系统的入口程序Controller，需要使用EDI子系统的Command根据各自的业务需要，通过该Controller来获得EDI子系统提供的不同类型的EDI功能模块实例来完成其要求。具体的调用方式如下：

EDIAgent ediAgent = null; try { }

ediAgent = (EDIAgent) Controller.getInstance().getService(\} catch (Exception e){

其中EDIAgent.Instance表示提供发送与订舱业务相关EDI报文的功能模块，系统目前支持下列不同的功能模块： 功能模块名称 EDIAgent.Instance SAPAgent.Instance UFAgent.Instance 功能描述 发送与订舱业务相关EDI报文的 根据SAP财务系统的格式要求，把FOCUS系统的相关商务数据生成SA报文 根据SAP财务系统的格式要求，把FOCUS系统的相关商务数据生成SA报文 获得所需要的功能模块的实例以后，按照下面方式来调用：

MessageObject responseMO = null;

MessageObject requestMO = new MessageObject(); responseMO = ediAgent.getResult(requestMO);

其中requestMO是业务Command根据发送EDI的要求，经过对特定业务数据处理后生成的，这里用new操作来代替。

1.4. YakInterface

YakInterface是EDI子系统的核心部分，完成了EDI收、发的主要业务功能。

发送报文时，从Command接收业务数据，根据报文格式和接收方调用不同的Policy，完成业务规则校验、代码翻译、日志处理，并将其转换成统一的YakInterface内部EDI格式，再发送到WPG进行格式转换。

接收报文时，从WPG接收转换后的统一的YakInterface内部格式，根据“壳”信息中的数据，来调用不同的Policy完成业务规则校验、数据保存、日志处理。

其设计结构上的核心为以下两点： ? 数据耦合

在YakInterface内部各组件之间，使用共享的数据缓冲区来完成数据的交换，以适应未来可能会发生变化的业务处理方式。

4

? Policy模式

在发送和接收报文的过程中，对于具体的业务处理，采取多级Policy的设计模式，能够灵活应对不同报文格式和接收方的要求。

1.4.1. YakInterface逻辑架构

Interface Sub-System（接口子系统）子系统控制器Application ServerEDI ServergetService()Agent InstanceController控制器)()r(et)r)s)(e(i(rtrresegetitetsgsrsieiCacheigrggeeerr缓存r器)(retsFormattertransfer()TransferigP2&UP4. erBizgetResult(MO)格式转换代码翻Command器译器业务功能组件准备数据get()|put()put()|get()Return MOAgent任务代理DataBuffer数据交换区get()|put()MessageTargetQueueQueueDelegateMQClientEDI Server目标代理QueueMessageQueue﹒如果调用方式为同步调用，返回MO中包含实际转换后数据（目前不使用同步模式）﹒如果调用方式为异步调用，C1. 接收返回MO中仅包含操作状态数据P3&UP3. 转发数据P4&UP2. 生成数据C1:表示统一入口。 P2-P4:表示打包的流程。 UP2-UP4:表示解包的流程。

5

1.4.2. YakInterface组件架构

Application ServerEDI ServerFront 前置机LogEDI Formatter格式转化器Code MappingSAP_Accounting FormatterBiz Components业务功能模块Agent任务代理UF_Accounting Formatter Transfer Component代码翻译器Controller控制器TargetDelegate目标代理IBM WPGCommunicationAgentPostProcessor&PreProcessor[PolicyEngine]Validate BizRule&Log2DB&Save2DBCacheManager缓存管理HibernateComponent

其中各组件的说明如下：

① EDI处理模块与其他处理模块之间的交互都通过代理完成，其中Agent负责服务器端业务功能组件与EDI处理模块之间的交互；TargetDelegate负责EDI处理模块与EDI Server之间的交互。

② EDI Formatter：负责对EDI进行打包和解包

③ SAP_Accounting Formatter: 负责对SAP格式报文进行打包 ④ UF_Accounting Formatter：负责对用友格式报文进行打包

⑤ Transfer： 代码转换，即将系统定义的代码转换为目标格式代码 ⑥ PolicyEngine：业务策略引擎（根据定义的策略进行业务规则校验、记录数据库日志，回填业务数据）

⑦ Controller： 负责控制Agent之间的交互 ⑧ log： 操作日志组件

⑨ CacheManager：缓存组件

⑩ Hibernate Component：数据映射组件，使用框架公用组件完成数据持久化

11 PostProcessor&PreProcessor：前置机对打包后处理和解包预处理的组件，主要完成○

对EDI报 文的特殊字符的处理和还原以及脱壳和加壳处理

1.5. WPG

WPG为第三方中间件，用来完成报文格式的转换。

发送报文时，接收YakInterface发送的标准格式的报文，再根据不同的报文格式和接收方，生成具体的基本符合接收方要求的报文，并加上与报文处理相关的“壳”信息，再将生成的报文发送到前置机进行最后的处理。

6

接收报文时，接收前置机发送的不同格式的报文，转换成统一的接口内部格式，发送给YakInterface。

WPG主要使用与之配合客户端工具DISClient进行报文格式的定义和报文格是的转换。

1.6. YakFront

发送报文时，收到WPG发送的报文，再根据配置信息和报文中的“壳”信息，对报文进行字符的校验和特殊处理，并去掉“壳”信息，最后通过指定的方式把报文发送出去。

在接收报文时，根据配置信息和不同的发送方，对报文进行特殊字符处理，并加上“壳”信息，再发送到WPG。

2. EDI开发步骤

2.1. 报文格式分析

发送报文时，系统支持交通部和UN/EDIFACT两种标准，另外有些船公司的报文为其自定义格式。交通部标准的报文，以上海亿通的报文格式为标准和基础，UN/EDIFACT标准的报文，以WPG提供的报文格式为标准和基础。下面以亿通格式的订舱报文（IFTMBF）为例进行说明，UN/EDIFACT标准和自定义格式的报文处理方式类似。

例如：收到船公司A的订舱报文，检查其格式说明文件，发现其报文内容组成形式基本符合亿通订舱报文，但是修改了某些段（记录、Segment）和字段（Item），将不同的部分进行记录，记录的内容包括：增加/删除/修改、循环次数、数据类型、数据长度。如果船公司同时提供了代码表，则表示在生成报文时需要进行代码映射；如果没有提供代码表，并不表示不需要进行代码映射，有可能会在后期用户测试阶段提出代码映射的要求。

根据记录的报文格式中发生变化的数据，检查FOCUS系统的“订舱委托表”（T_CO_OCEANORDER），以及相关的“预配信息表”（T_CO_OCEANPRELOAD）、“货物表”（T_CO_CARGO）、“参与方表”（T_CO_OCEANORDER，存放收货人、发货人、通知人信息），如果发现这些表不能提供生成报文所需的信息，则检查报文格式说明，该信息是否为生成报文的必须信息，如果不是则忽略该信息；如果是必须信息，则与业务组协商，如何补充该信息。

处理完报文以后，还需要获得的信息为：报文发送方式、发送方代码、接收方代码，这些信息可以先使用虚拟数据代替，在客户测试阶段更新为真实数据。

2.2. 增加Policy

YakInterface里面的Policy分为两级，第一级处理不同的报文格式，第二级处理不同的报文接收方。每一个Policy对应系统中的一个实现类，第一级的类放在yak.sysinterface.edi.policy包中，第二级的类放在yak.sysinterface.edi.rule报中。报文格式与实现类、接收方与实现类的对应关系放在FOCUS系统的配置文件PolicyEngine.properties中。

文件的内容如下：

7

######################################################################## ## POLICY ENGINE CONFIGURE SECTION ## THE RULE IS:

## BUSINESS CODE = POLICY IMPLEMENT CLASS OF PROCESSING THAT BUSINESS ########################################################################

## BIZ RULE RELATED POLICY ########################################### IFTMBF=yak.sysinterface.edi.policy.IftmbfPolicy IFTMBC=yak.sysinterface.edi.policy.IftmbcPolicy IFTMIN=yak.sysinterface.edi.policy.IftminPolicy SAP=yak.sysinterface.sap.policy.SapPolicy …

## FILENAME RELATED POLICY ###########################################

## VALIDATE RULE POLICY ############################################## EASIPASS.RulePolicy=yak.sysinterface.edi.rule.EasiPassPolicy COSFRE.RulePolicy=yak.sysinterface.edi.rule.CosfrePolicy …

上半段内容是报文格式与实现类的配置信息，下半段内容是接收方与实现类的配置信息。

例如新增加一种报文格式，格式名称为“TESTFORMAT”，则需要实现下面几项内容：

? 完成该格式的实现类：

yak.sysinterface.edi.rule.TestFormatPolicy.java

? 在上面的配置文件中增加一行配置信息：

TESTFORMAT =yak.sysinterface.edi.policy.IftminPolicy

如果新增加一个报文接收方，名称为“TESTRECEIVER”，则需要实现下面几项内容：

? 完成该接收方的实现类：

yak.sysinterface.edi.rule.TestReceiverPolicy.java

? 在上面的配置文件中增加移行配置信息：

TESTRECEIVER.RulePolicy=yak.sysinterface.edi.rule.TestReceiverPolicy

第一级Policy（报文格式）在完成实现类时，要实现Policy接口，接口定义如下： public interface Policy {

public PolicyResult log2DB(String operation,Object o,String errorCode,String errorDesc) throws InterfaceException;

public final static String ERROR_HANDLE_POLICY = \; public final static String ERROR_SAVE_LOG_TO_DB = \;

public PolicyResult validateBizRule(String operation,Object o) throws

InterfaceException;

8

} 其中：

validateBizRule是业务规则校验的处理方法方法；可 log2DB是保存处理日志的方法；

save2DB是接收报文时，保存数据的方法；

这三个方法由FormatterTask（yak.sysinterface.edi.FormatterTask.java），根据当前处理的不同报文报文格式和处理阶段，自动调用。例如：在处理接收EDI订舱单（IFTMBF）时，FormatterTask会依次调用IFTMBFPolicy的validateBizRule、save2DB、log2DB。

如果某一种报文格式没有定义其对应的Policy，则系统在处理该报文格式时，会抛出InterfaceException。

public PolicyResult save2DB(String operation,Object o) throws InterfaceException;

第二级Policy（接收方）在完成实现类时，要实现RulePolicy接口，接口定义如下： public interface RulePolicy { }

public static final String RULE_POLICY_SUFFIX = \; public boolean validateIFTMBF(String ope ration,Object o); public boolean validateIFTMIN(String operation,Object o); public boolean validateCOSTCO(String operation,Object o);

其中： validateIFTMBF是处理订舱单报文的处理规则； validateIFTMIN是处理提单确认报文的处理规则； validateCOSTCO是处理装箱单报文的处理规则；

这三个方法由第一级Policy（报文格式Policy）来自动调用，例如：IFTMBFPolicy在处理发送到“TESTRECEIVER”订舱单的过程中会自动调用TestReceiverPolicy的validateIFTMBF。

如果某一接收方没有定义其对应的Policy，则系统在处理该报文格式时，在第一级Policy中查找是否有缺省的处理方式，如果找到则执行默认的处理方式，否则会抛出InterfaceException。

2.3. 增加数据库配置信息

在数据库中需要根据报文接收/发送方的不同要求，在下面的这些表中配置相应的信息。

2.3.1. EDI参与方（EDI_PARTNER）

用来记录FOCUS系统中目前所支持的报文接收方的主要信息，结构如下：

中文名称 EDI参与方主键 EDI参与方名称

字段名称 EDI_PATN_ID EDI_PATN_NAME 字段类型 NUMBER(12) VARCHAR2(40) 备注 9

EDI参与方代码 非EDI中心报文名称代码 非EDI中心接收方代码 系统合作伙伴ID 是否支持直接发送 是否支持EDI中心 是否EDI中心 删除标志 修改日期 EDI_PATN_CODE DR_MSG_CODE DR_RCV_CODE SYS_PATN_ID SPRT_DR SPRT_EDI_CNTR IS_EDI_CNTR IS_DELETED UPD_DATE VARCHAR2(40) VARCHAR2(40) VARCHAR2(40) NUMBER(12) VARCHAR2(20) VARCHAR2(20) CHAR(1) CHAR(1) TIMESTAMP 例如，上海中集的配置记录如下： 1009 主键 COSCO 客户端显示的名称 COSFRE EDI合作伙伴代码 直接发送时，报文类型代码，需要与WPG中定义的报文类型名称相匹配。例如，在WPGDR_MSG_CODE COSFRE 中上海中集的订舱报文的名称定义为“IFTMBF_COSFRE”，则该字段的取值必须是“COSFRE” 直接发送时，报文中的接收方DR_RCV_CODE 63148792 代码 SPRT_DR Y 允许直接发送报文给中集 SPRT_EDI_CNTR N 不支持通过EDI中心发送 在系统合作伙伴基础信息表SYS_PATN_ID 7000 中对应的ID IS_EDI_CNTR N 不是EDI中心 IS_DELETED N 没有被删除 12-12月-06 11.31.29.626025 上数据最后一次修改时间 UPD_DATE 午 上海亿通的配置记录如下：

字段名称 字段值 说明 EDI_PATN_ID 1010 主键 EDI_PATN_NAME 亿通 客户端显示的名称 EDI_PATN_CODE EASIPASS EDI合作伙伴代码 因为是EDI中心，不是具体的DR_MSG_CODE 业务合作伙伴，只是转发报文，不需要配置该数据 因为是EDI中心，不是具体的DR_RCV_CODE 业务合作伙伴，只是转发报文，不需要配置该数据

10

字段名称 EDI_PATN_ID EDI_PATN_NAME EDI_PATN_CODE 字段值 说明

支持直接发送 支持通过EDI中心发送 在系统合作伙伴基础信息表SYS_PATN_ID 1000 中对应的ID IS_EDI_CNTR Y 是EDI中心 IS_DELETED N 没有被删除 12-12月-06 11.31.29.626025 上数据最后一次修改时间 UPD_DATE 午 上海APL（美国总统）的配置记录如下： 字段名称 字段值 说明 EDI_PATN_ID 1000 主键 EDI_PATN_NAME APL 客户端显示的名称 EDI_PATN_CODE APL EDI合作伙伴代码 如果没有配置该项数据，则表DR_MSG_CODE 示不支持直接发送 如果没有配置该项数据，则表DR_RCV_CODE 示不支持直接发送 支持直接发送，但是还需要检查DR_MSG_CODE和SPRT_DR Y DR_RCV_CODE的值，都有才表示支持直接发送 SPRT_EDI_CNTR Y 支持通过EDI中心发送 在系统合作伙伴基础信息表SYS_PATN_ID 4616 中对应的ID IS_EDI_CNTR N 不是EDI中心 IS_DELETED N 没有被删除 12-12月-06 11.31.29.626025 上数据最后一次修改时间 UPD_DATE 午 SPRT_DR SPRT_EDI_CNTR Y Y 2.3.2. EDI连接方式（EDI_CONN_TYPE）

用来记录通过EDI中心发送报文的配置信息，表结构如下： 中文名称 字段名称 字段类型 连接方式主键 CONN_TYPE_ID NUMBER(12) 经EDI中心报文名称代码 EDI_CNTR_MSG_CODE VARCHAR2(40) EDI中心参与方主键 EDI_CNTR_PATN_ID NUMBER(12) 经EDI中心接收方代码 EDI_CNTR_RCV_CODE VARCHAR2(40) EDI参与方主键 EDI_PATN_ID NUMBER(12) 删除标志 IS_DELETED CHAR(1) 修改日期 UPD_DATE TIMESTAMP 例如，上海APL（美国总统）的配置数据记录如下： 字段名称 字段值

备注 说明 11

CONN_TYPE_ID 1 主键 经过EDI中心发送时，报文类型代码，需要与WPG中定义的报文类型名称相匹配。例如，在WPG中上EDI_CNTR_MSG_CODE EASIPASS 海亿通的订舱报文的名称定义为“IFTMBF_EASIPASS”,则亿通的本字段必须取“EASIPASS” EDI中心在EDI合作伙伴EDI_CNTR_PATN_ID 1010 表中的ID 经过EDI中心发送时，EDIEDI_CNTR_RCV_CODE APLMBF 合作伙伴在EDI中心的接收方代码 通过EDI中心发送报文的EDI_PATN_ID 1000 EDI合作伙伴，在EDI合作伙伴表中的ID IS_DELETED N 没有被删除 23-6月 -06 11.48.14.907085 上数据最后一次修改时间 UPD_DATE 午 2.3.3. EDI合作伙伴字段翻译（EDI_PATN_FIELD_TRANS）

用来保存每个EDI合作伙伴哪些类型的代码需要进行代码翻译，表结构如下： 中文名称 字段翻译主键 EDI合作伙伴主键 报文字段类型主键 是否需要翻译 字段名称 MSG_TRANS_ID EDI_PATN_ID MSG_FIELD_TYPE_ID NEED_TRANS 错误级别 错误替代代码 0：用来表示翻译该类代码发生错误时，不允许报文的发送/接收 ERROR_LEVEL NUMBER(3) 1：用来表示翻译该类代码发生错误时，允许报文的发送/接收 在发生代码翻译错误的时候，如ERROR_REPLACE_CODE VARCHAR2(50) 果错误级别ERROR_LEVEL是12

字段类型 NUMBER(12,0) NUMBER(12,0) NUMBER(12,0) CHAR(1) 备注

修改日期 UPD_DATE 例如，上海亿通港口代码的配置数据如下： 字段名称 字段值 MSG_TRANS_ID EDI_PATN_ID MSG_FIELD_TYPE_ID NEED_TRANS Y TIMESTAMP 1，则用该代码作为代码翻译的结果 说明 ERROR_LEVEL ERROR_REPLACE_CODE ZZZZZ 上海亿通箱形尺寸的配置数据如下：

字段名称 字段值 MSG_TRANS_ID EDI_PATN_ID MSG_FIELD_TYPE_ID NEED_TRANS ERROR_LEVEL ERROR_REPLACE_CODE 1007 主键 亿通在系统合作伙伴基础信1000 息表中对应的ID 代码类型在EDI代码类型表1 中的ID 需要翻译，如果为“N”，则表示该代码类型不需要翻译 允许代码翻译错误，如果发生1 错误，则使用“ZZZZZ”作为代码翻译的结果 说明 1001 主键 亿通在系统合作伙伴基础信1000 息表中对应的ID 代码类型在EDI代码类型表2 中的ID 需要翻译，如果为“N”，则表示该代码类型不需要翻译 不允许翻译错误，如果发生错0 误，则不能生成EDI Y 2.3.4. EDI合作伙伴报文格式（PATN_MSG_TYPE）

用来保存每个合作伙伴支持哪些类型的报文，以及对应的报文功能，表结构如下：

中文名称 合作伙伴报文格式主键 EDI合作伙伴主键 报文格式代码 报文格式操作方式 字段名称 字段类型 EDI_PATN_MSG_TYPE_ID NUMBER(12) SYS_PATN_ID NUMBER(12) MSG_TYPE_CODE VARCHAR2(17) CHAR(1) SUPPORT_TYPE IS_DELETED ALLOW_MULTI_MSG CHAR(1) CHAR(1) 备注 1：发送 2：接收 3：发送/接收 13

删除标志 是否允许多票发送

是否支持原始报文功能 SUPPORT_ORIG 是否支持修改报文功能 SUPPORT_CHANGE 是否支持增加报文功能 SUPPORT_ADD 是否支持删除报文功能 SUPPORT_DELETE 例如，上海亿通订舱报文的配置数据如下： 字段名称 字段值 EDI_PATN_MSG_TYPE_ID SYS_PATN_ID CHAR(1) CHAR(1) CHAR(1) CHAR(1) 说明 MSG_TYPE_CODE SUPPORT_TYPE IS_DELETED ALLOW_MULTI_MSG UPD_OPER_CD UPD_OPER_NM UPD_DATE SUPPORT_ORIG SUPPORT_CHANGE SUPPORT_ADD SUPPORT_DELETE 1 主键 亿通在系统合作伙1000 伴基础信息表中对应的ID 支持的报文类型代IFTMBF 码 支持发送和接收订3 舱报文 N 没有被删除 一个报文中不允许包含多票委托。如果N 为“Y”，则在一个报文中可以包含多票委托 最后一次数据更新ADMIN 人代码 最后一次数据更新系统管理员 人名称 最后一次数据更新02-11月-06 07.27.56.000000 下午 时间 支持“原始”报文功Y 能。如果为“N” 或空，则不支持 支持“修改”报文功Y 能。如果为“N”或空，则不支持。 不支“增加”报文功 能 不支持“删除”报文 功能 2.4. 增加WPG配置信息

参考WPG相关手册。

14

2.5. 增加前置机配置信息

各配置项信息需要严格区分大小写，路径信息要按照报文接收方提供的标准格式填写（与具体的操作系统有关）。每一个配置项目的各项之间必须使用“.”进行分割。

2.5.1. 发送方式配置信息（向EDI中心询问FTP和MAIL的参

数配置！！！）

该信息存放在前置机的配置文件FileTransport.properties中，包含了用来直接发送EDI报文的详细配置信息。目前系统支持FTP、Email两种自动发送方式。

2.5.1.1. FTP方式的配置信息

对于FTP发送方式，将EDI报文直接上传到指定的FTP服务器上。每一个配置项目的组成方式如下：

BU代码.报文直接接收方代码.FTP参数项名称=FTP参数项值 其中各项含义为：

? BU代码：为各BU在前置机中定义的代码，在config.properties文件中配置，例如

上海的在FOCUS中的BU代码为“501”，则在config.properties中的配置信息为：

501=CSHWL 表示在前置机中，“CSHWL”代表的是与上海BU相关的信息。 ? 报文直接接收方代码：在数据库中配置的直接接收方代码 ? FTP参数项名称：FTP必须配置的项目为： FtpServer：FTP服务器的IP地址 UserId：登陆给定IP地址的FTP服务器的用户名 Password：登陆密码 WorkingDirectory：登陆以后，上传EDI报文的存放路径

另外，根据具体的要求，还需要配置下面的FTP项目：

DownloadDirectory：如果需要从该FTP服务器下载EDI报文，则需要指定被下

载的报文在服务器上的存放位置

TESTMODE：是否打开测试方式。在进行EDI报文FTP测试阶段，如果发生报文

不明原因丢失的情况，可以打开此选项，只有唯一的值“UPLOAD_VALIDATE”。打开此选项后，还必须配置BAK_DIR项。此时，系统会先把报文上传到BAK_DIR所制定的目录，在移动到前面配置的WorkingDirectory

BAK_DIR：在测试方式下，报文的上传目录

LEAVE_BAK：在测试方式下，是否保留上传到BAK_DIR目录的报文。取值为YES和NO，YES则保留BAK_DIR中的报文，NO则不保留

? FTP参数项值：与具体参数项匹配的值 例如，上海的中集（中远集装箱）的配置信息为： CSHWL.COSFRE.FtpServer=192.168.129.30

15

CSHWL.COSFRE.UserId= CSHWL.COSFRE.Password=

CSHWL.COSFRE.WorkingDirectory= 前四行是发送报文需要添加的

CSHWL.COSFRE.DownloadDirectory= /usr/IBM/frontTest/out CSHWL.COSFRE.TESTMODE=UPLOAD_VALIDATE CSHWL.COSFRE.BAK_DIR=/

CSHWL.COSFRE.LEAVE_BAK=YES 后四行是接收报文时需要添加的

如果是新追加报文接收方，在前置机的config.property中加上 BU代码 503=CSHNT

2.5.1.2. Email方式的配置信息

对于Email发送方式，将EDI报文最为附件发送到指定的Email地址。每一个配置项目的组成方式如下：

BU代码.报文直接接收方代码.Email.Email参数项名称=Email参数项值 其中“Email”项必须包含，各项含义为：

? BU代码：为各BU在前置机中定义的代码，在config.properties文件中配置，例如

上海的在FOCUS中的BU代码为“501”，则在config.properties中的配置信息为：

501=CSHWL 表示在前置机中，“CSHWL”代表的是与上海BU相关的信息。 ? 报文直接接收方代码：在数据库中配置的直接接收方代码 ? Email：保留标签

? Email参数项名称：Email必须配置的项目为：

ToAddress：对方接收EDI报文的Email地址

ToName：与给定的接收Email地址相匹配的用户名 FromAddress：FOCUS系统发送EDI邮件的Email地址 FromName：与给定的发送Email地址相匹配的用户名 Subject：邮件主题 Content：邮件内容

? Email参数项值：与具体参数项匹配的值 例如，上海的OOCL（东方海外）的配置信息为：

CSHWL.OOCL.Email.ToAddress=exch@edi.cargosmart.com CSHWL.OOCL.Email.ToName=annie.fang

CSHWL.OOCL.Email.FromAddress=Caowei@coscologistics.sh.cn CSHWL.OOCL.Email.FromName=Cao Wei

CSHWL.OOCL.Email.Subject=Cosco Shanghai EDI Booking.

16

CSHWL.OOCL.Email.Content=Dear partner, \\n\\n This EDI message from COSCO.Please check the attachements and thank you.\\n\\n Best regards, \\n\\n

2.5.2. 工作目录配置信息

该信息保存在前置机的配置文件Pkg_postprocess.properties中，包含了每一个EDI合作伙伴的工作目录、中文/全角字符检查、发送方式信息。

? 工作目录：如果用户在生成报文的时候，不选择自动发送，则生成的报文会保存

在该目录中。配置项目的组成方式如下： BU代码.报文直接接收方代码=参数项值 例如，上海中集的配置信息为：

CSHWL.COSFRE=/usr/IBM/front/Production/SHANGHAI/CSHWL/Target/cosfre

? 中文/全角字符检查：是否允许生成的EDI报文中含有中文/全角字符。配置项目的

组成方式如下：

BU代码.报文直接接收方代码.NeedCheckSBC=参数项值 例如，上海中集的配置信息为：

CSHWL.COSFRE.NeedCheckSBC=false

表示发送到上海中集的报文中允许包含中文/全角字符。如果不允许包含中文/全角字符，则可以不配置该配置项或将配置项值设为“true”。

? 发送方式：用来确定发送到该EDI合作伙伴的EDI报文的发送方式。如果该合作伙

伴部能够直接接收EDI报文，则不需要配置该配置项。目前系统支持FTP和Email两种方式，对应的值分别为“FTP”和“SMTP”。配置项目的组成方式如下： BU代码.报文直接接收方代码. Connection =参数项值

例如，上海中集的发送方式为FTP，则其配置信息如下：

CSHWL.COSFRE.Connection=FTP

上海OOCL（东方海外）的发送方式为Email，其配置信息如下：

CSHWL.OOCL.Connection=SMTP

2.5.3. 特殊处理配置信息

该信息保存在前置机的配置文件PolicyEngine.properties中，包含了针对每一个EDI合作伙伴的特殊字符处理和接收报文配置信息。

? 特殊字符处理：是否在接收/发送报文的时候，对转译符、回车换行符、中文字符

进行处理。可取得值为“true”“false”。如果该EDI合作伙伴不直接接收EDI报文，则不需要侧配置向。如果某个EDI合作伙伴此处的配置值为“false”，则在Pkg_postprocess.properties中配置的是否检查中文/全角字符的配置项就不再起作用。配置项目的组成方式如下：

BU代码.报文直接接收方代码. SpecialProcess =参数项值

例如，上海中集不需要进行特殊字符、中文/全角字符的检查，其配置项为：

CSHWL.COSFRE.SpecialProcess=false

上海APL（美国总统轮船）需要进行特殊字符的处理，其配置项为：

CSHWL.APL.SpecialProcess=true

17

? 接收报文：用来配置能够接收的某一个EDI合作伙伴的报文类型和处理方式。由以

下几项配置项目：

1) 接收报文后的处理类：与YakInterface中的第二级Policy的开发、配置方

式相同。配置项目的组成方式如下： BU代码.报文直接接收方代码=参数项值

处理类放在yak.sysinterface.front.unpkg.policy包中，实现Policy接口，接口的定义如下：

public interface Policy {

public static final String ERROR_READ_EDI_HEAD = \;

public abstract String parseEdiType(BufferedReader bufferedreader) throws FrontException;

public abstract String genShell(YakEdiShell shell) throws FrontException; }

其中：

ParseEdiType：根据报文内容判断报文格式的方法 genShell：生成“壳”信息的方法

这两个方法被yak.sysinterface.front.unpkg.preprocess包里的PreProcessor.java调用。

例如，接收上海亿通（EASIPASS）的报文的配置如下：

CSHWL.EASIPASS=yak.sysinterface.front.unpkg.policy.EasiPassPolicy 2) 报文接收途径：是通过EDI中心还是直接从合作伙伴接收报文。配置项目

的组成方式如下：

BU代码.报文直接接收方代码. RouteEdiCenter =参数项值 可取值为“Y”和“N”。“Y”表示通过EDI中心接收某个合作伙伴的报文，“N”表示直接从某个合作伙伴接收报文。例如，接收上海中集的配置项如下：

CSHWL.COSFRE.RouteEdiCenter=N 表示直接从中集接收报文。

3) 报文接收、处理后发送途径：用来指示在接收报文并经过初步处理后，

将处理的结果发送到哪一个QUEUE上，以便WPG来接收和处理。配置项目的组成方式如下：

BU代码.报文直接接收方代码.报文类型. SendQueue =参数项值

“报文类型”是通过对应接收方的Policy的parseEdiType方法，分析收到的报文得到的；“参数项值”的取值则根据在WPG中定义的QUEUE的名称来取。例如，接收上海中集的订舱回执报文，其配置项如下： CSHWL.COSFRE.UIFRET.SendQueue=COSFRE_UIFRET_IN “UIFRET”为报文格式，在这里表示订舱回执；“COSFRE_UIFRET_IN”为WPG中定义的用来接收上海中集订舱回执的QUEUE的名称。 如何在WPG中定义QUEUE，参考WPG相关手册。

18

2.5.4. 报文接收目录配置信息

该信息保存在前置机的配置文件scanner.properties中，包含了接收合作伙伴的报文的目录，配置项的组成方式如下：

BU代码.报文直接接收方代码.参数项名称=参数项值 参数项包括下面三项： Dir：要接收的报文存放目录 Priority：处理目录中报文的比例，取值为小于等于1的正的两位小数。例如，1表示每次对该目录中所有报文都处理，0.54表示每次只对该目录中54%的报文进行处理 DownMode：报文的下载方式，只有需要我们自己去合作伙伴的FTP服务器上下载需要接收的报文时，才配置此项，而且目前只接受唯一值“INITIATIVE”。FTP服务器的地址从配置文件FileTransport.properties中获得。例如，上海中集的配置项如下： CSHWL.COSFRE.Dir=/usr/IBM/front/Production/SHANGHAI/CSHWL/cosfre CSHWL.COSFRE.Priority=1

CSHWL.COSFRE.DownMode=INITIATIVE

表示中集的报文都放在/usr/IBM/front/Production/SHANGHAI/CSHWL/cosfre目录下，每次对该目录下所有的报文都进行处理。要接收的报文从中集的FTP服务器上自行下载，下载后放到/usr/IBM/front/Production/SHANGHAI/CSHWL/cosfre目录下。 上海东方海外的配置项如下：

CSHWL.OOCL.Dir=/usr/IBM/front/Production/SHANGHAI/CSHWL/oocl CSHWL.OOCL.Priority=1

表示OOCL的报文都放在/usr/IBM/front/Production/SHANGHAI/CSHWL/oocl目录下，每次对该目录下所有的报文都进行处理。要接收的报文不需要去OOCL的FTP服务器下载。

2.6. 代码映射导入

代码映射导入主要是在增加一个新的EDI合作伙伴时，把用户提供的需要进行处理的代码一次性、大批量导入系统，减少客户的工作量。分为以下几个步骤：

2.6.1. 确认代码类型

拿到EDI合作伙伴提供的代码表后，要确认其代码类型，目前EDI子系统支持的代码类型有：

代码类型中文名称 承运人代码 箱经营人代码 SAP客户供应商代码 海运费条款代码 港口代码 箱型尺寸代码 付款方式代码 提单类型代码 货物类型代码

代码类型英文名称 carrier ctn_owner sap_patn freight_clause port ctn_type_size pay_type bl_type cargo_type 代码类型对应系统表 T_Sa_Patnbainfo T_Sa_Patnbainfo T_Sa_Patnbainfo T_Cd_Freightclause T_Cd_Port T_Cd_Ctnsizetype T_Cd_Colligate T_Cd_Colligate T_Cd_Colligate 代码类型对应合作伙伴表 T_Sa_CarrierEx T_Sa_CtnOwnerEx T_Sa_pPatnEx T_Cd_FreightclauseEx T_Cd_PortEx T_Cd_CtnsizetypeEx T_Cd_ColligateEx T_Cd_ColligateEx T_Cd_ColligateEx 19

船名代码 vessel T_Cd_Vessel T_Cd_VesselEx 如果EDI合作伙伴提供的代码类型不在此列表中，需要与客户和业务组讨论如何处理。 2.6.2. 初步确认与系统代码的映射关系

确认了代码类型以后，根据具体的EDI合作伙伴代码数据，在系统相应类型的代码表中，找到相对应的代码，然后记录在代码映射文档中。每一种代码类型生成一份代码映射文档。代码映射文档要包含下面几项内容：

? 合作伙伴代码名称 ? 合作伙伴代码 ? 系统对应代码

? 系统对应代码名称 ? 系统对应代码助记码 ? 系统对应代码ID

在建立映射关系时，除了SAP客户供应商类型，其他类型都允许“多对多”的映射。SAP客户供应商类型的代码，从系统内代码到SAP代码映射时，只允许“一对一”映射；从SAP代码到系统内代码映射时，允许“一对多”映射。

2.6.3. 客户的业务人员确认映射关系

将生成的代码映射文档，提交业务人员进行确认。根据业务人员确认的结果，修改代码映射文档。与业务人员的确认过程，可能需要进行多次，直至业务人员确认无误后，再导入系统。

2.6.4. 代码和映射关系导入系统

将业务人员最终确认后的代码映射文档，提交数据组，并协助数据组导入对应表。导入以后，要及时通知客户业务人员进行检查确认。

3. EDI测试

在前期代码开发和配置项完成以后，进入测试阶段，测试阶段主要是补充和完善业务规则校验以及代码翻译。

3.1. 开发测试

首先进行开发测试，这一步骤主要是检查下面几项内容：

? 业务规则是否有错误，主要是代码错误； ? 各个配置项是否有缺失、错误； ? 其他代码是否有错误；

20

? 生成的报文格式是否符合要求；

经过测试，以上几项都没有问题后，可以发布生产环境，提供给客户进行测试。

3.2. 用户测试

其次进行客户测试，客户测试阶段周期比较长，会重复进行多次。主要是配合客户测试的结果对业务校验规则、代码映射、发送方式进行修改、补充。每一次修改，都要在测试环境测试通过以后，再提交生产环境进行下一轮用户测试。

用户测试阶段要注意下面几项内容：

? 收集、保存客户提供的代码表，并配合客户、数据组完成代码表的数据导入工作； ? 对于业务规则的调整，要在代码中作详细记录；

21

? 生成的报文格式是否符合要求；

经过测试，以上几项都没有问题后，可以发布生产环境，提供给客户进行测试。

3.2. 用户测试

其次进行客户测试，客户测试阶段周期比较长，会重复进行多次。主要是配合客户测试的结果对业务校验规则、代码映射、发送方式进行修改、补充。每一次修改，都要在测试环境测试通过以后，再提交生产环境进行下一轮用户测试。

用户测试阶段要注意下面几项内容：

? 收集、保存客户提供的代码表，并配合客户、数据组完成代码表的数据导入工作； ? 对于业务规则的调整，要在代码中作详细记录；

21

本文来源：https://www.bwwdw.com/article/iqog.html