http://www.cnblogs.com/isline/archive/2010/04/15/1712428.html

一、概述

    OracleEBS是Oracle公司的ERP产品，这个产品非常庞大，可以对企业的各个方面进行强大的管理功能，一般大型企业都会用到它的部分模块，根据公司的性质不同，选择的模块也会有所不同。对于生产型企业，所采购的模块中都会包括产品及价格等管理模块。

    ERP属于大型系统，能选择Oracle ERP的企业，规模一般也不会太小，所以在IT方面，除了ERP产品本身，一般还会有其它一些小型的专有业务系统来支撑，这些系统有些是在ERP上线之前就在一直使用的，并不能简单的用ERP产品来全部替换他们。根据实际情况来看，少不了要在各个系统与EBS之间，实现部分信息的同步，特别是产品信息，一般将会选择在ERP系统中维护，而其它系统可以直接引用ERP系统中的信息，这样保证产品信息只有一套，不会出现冗余，也不会出现歧义。

    我们公司在以前与ERP进行接口的时候，用到了很多的办法，其中最常用的就是直接从ERP里读取信息，然后直接写入业务系统，或者由业务系统发起，直接向ERP中写入信息。对于简单的信息，这种做法还基本能行的通，但是对于更复杂的业务逻辑，这种做法风险是不能小看的，因为根据使用EBS的经验来看，EBS的设计非常的复杂，表结构与套用关系也是错综复杂，有时感觉修改一个表就够了，但是在真正使用的时候，或用过一段时间之后，才发现ERP的数据一致性已经被破坏，有时甚至会造成ERP系统出现问题，并且有时候已经很难恢复，所以这种做法并不可取。

    EBS本身提供了一系列的接口表，所以向EBS写入数据的过程，Oracle公司都建议使用接口表，在临时数据写入接口表之后，OracleEBS的产品中会有相应的接口程序来实现对接口表的描述及导入生产表，这样会尽量维持EBS的数据完整性。当然从本质上来说，还是对数据库表的操作，但是这种做法已经安全了很多。

    以上所说的一般都是指应用系统与ERP系统都处于公司的同一个网段，这种情况下才有可能用数据库连接的方式来集成，但是对于有些应用系统位于不同的地理位置，甚至位于海外的时候，这种方式就显得力不从心了，因为从其它数据中心发起的请求是无法直接到达ERP的数据库的。

    其实很多系统的集成需求抽象出来，有很大的相似性，但是如果由各个厂商自己来制定标准，可能对EBS的影响比较大。出于此种情况，可以考虑将EBS的接口进行规范化。

    在对EBS接口进行规范化的时候，需要考虑几点问题

    Ø 数据的安全性

    接口只能开放相关系统需要的部分，不能让更多的业务数据向外开放；

    相关应用系统只能通过合法的手段进行接口验证，未授权的系统不能使用该接口。

    Ø 数据的一致性

    EBS系统的结构相当复杂，在数据写入的时候，一定要注意数据的完整性和一致性，如果系统中存在多个表的冗余，一定要把所有相关的表全部同时处理，如果所处理的表不全面，会造成EBS致命的错误。为了实现这个一致性，应该尽可能使用EBS自身的接口表系统，然后由EBS自身的标准请求来处理后续的工作。

    Ø 系统的通用性

    此接口系统需要考虑对目前需要接入的几个系统的通用性支持，即此接口系统尽量要做到与业务系统无关，通过简单的配置即可实现对不同的系统的支持；

    另一个需要考虑的因素就是接入EBS的第三方系统，有些位于企业总部，可以直接连接到EBS的数据库服务器，而有些系统位于海外，没有能力直接与EBS的数据库相连，为了实现这个通用性，考虑使用WebService的方式来处理，即发布一个公网的WebService，让它与EBS的数据库相连接，这样就可以实现不同地理位置的系统的连接。

二、架构

    系统从总体上分为两部分，一部为企业的EBS及接口系统，第二部分为第三方厂商自建系统。

    在企业总部系统部分，又分为两部分，一部分为WS接口系统，第二部分为原始EBS系统。

    在EBS部分，又可以分为正式表和接口表两部分。

    整体需求在技术上分为两类：

    Ø 只读EBS

    WS直接从EBS生产表或接口表中读取数据，因为不涉及到写入操作，所以只要清楚数据库结构即可得到所需要的数据；

    Ø 读写EBS（需要交互）

    这部分工作比较复杂，需要对EBS进行写入操作，因为EBS的复杂性，需要把内容写入到接口表中，由标准请求来处理接口表到正式表的导入。

    在数据导入到正式表的过程中，有可能发生验证失败的情况，这种情况下，标准请求一般会在接口表或其它地方记录出错的信息，如果第三方需要这个信息，可以调用接口表从而得出相应的结论。总之，第三方与EBS的交互可以靠两种方式组合得出，但是交互的效率可能会相对稍慢，即中间有一定的延时。

    所谓标准请求，是指EBS自带的一些功能，至于它都有哪些标准请求，需要查阅EBS的相关文档，它们有的就是有，它们没有的，谁也不能提供。

    在技术架构方面，WebService接口部分采用Visual Studio 2008来开发，因为WebService与具体的程序语言无关，所以只要使用标准的接口规则，就可以被多个第三方厂商所使用。

三、WebService接口实现

    WS服务器采用Windows2008+IIS来实现，由WS来实现第三方厂商与EBS的沟通及交互，保证第三方厂商的系统（无论是在总部还是在海外IDC）都可以顺利的与EBS进行通讯。在接口实现这一部分，将分多个部分进行说明：

Ø 安全通讯

    在第三方与WS通讯的时候，需要考虑通讯的安全性，WS本身将采用HTTPS的方式来工作。

    因为不能保证全部第三方系统都能采用域验证的方式来使用，所以在数据传输上，还需要考虑一些更通用的WS的验证方式。

    在每新增加一个第三方厂商的时候，系统会分配给他们一个密码串（32字节），这个密码串是每个厂商（系统）唯一的，也不会在不同的厂商之间互相通报，每次数据发送，都会带着这个密码串一起发过来，这样可以首先确定上载数据的合法性，同理，数据下传的时候也会采用此种方式。

Ø 灵活性

    WS设计的原则应该是尽量把数据库表进行封装，使得第三方无须过多的了解EBS的表结构即可以正常工作，但是同时还要考虑WS的扩展性，所以不能做太多的接口函数，应该尽量采用Schema的方式来描述，每个Schema将与具体的业务及操作相对应，Schema的扩展相当灵活，可以随着业务的发展和新的第三方厂商的介入不断的完善及发展，形成一个标准的EBS接口Schema库，并形成相应的说明，可以挑选合适的Schema来使用。

    到此为止，我们只说明了实现的两个方面，安全性和灵活性，在下一期中，我们将对其它几个方面进行说明。

Ø 读取数据

    读取数据使用专门的接口函数，并且只有一个函数，可以做几次重载来实现不同的需要，更多的情况是靠schema参数来区分操作的类型，返回的类型为XML文件，并且第三方会知道按何种方式来拆解此返回的XML。XML可以是单表，也可是多表的记录集的形式，具体返回格式完全由Schema来指定；在返回之前，考虑传输的效率，需要对返回的数据进行压缩，然后再二进制数组的形式来返回

² 函数原型

    public byte[] GetData(string schemaName,string whereClause,string password) //取出指定条件的记录集

² 参数

    schemaName

    指定的模式名称，对于模式及模式的使用方式，在后面会有专门的描述

    根据指定的模式，系统会找到相对应的表，返回所需要的字段

    whereClause

    它是根据一个查询条件来返回记录，这样可以实现很复杂的查询功能，返回的记录集遵循指定的Schema

    password

    由系统分配给第三方厂商（系统）的一个hash串，作为唯一的标识，服务器端接收到消息后，会检查这个密码串的合法性，如果系统中不存在这个串，则不能进行任何操作。

    关于密码串的具体说明和用法，在后面有专门的描述。

² 返回值

    返回值一律为字节数组，而不采用XML直接返回，这样可以在传输之前做更多的处理，比如压缩和加密，本次设计中暂不包括加密处理，压缩采用标准的压缩算法。

    第三方在收到字节数组后，使用标准的压缩算法将其解开，还原成一个XML文件

    在第三方客户端，会存在相应的Schema来解析这个XML，具体使用哪个Schema，由客户端自己来把握，与服务器端无关，信息拆解后如何使用，也由客户端自己把握。

    如果操作失败，返回的错误也会按字节数组的形式来返回，所以客户端接收后首先要检查操作是否成功，如果确认没有失败，再去检查具体的返回内容。

Ø 写入函数

    写入动作是指由客户端发起，向服务器写入相关的内容，在本系统中，写入的内容与业务无关，全部抽象为技术层面来处理。

² 函数原型

    public byte[] WriteData(string schemaName,byte[] content,string password)

² 参数

    schemaName

    与读取函数的功能相似。

    content

    要写入的内容，在客户端生成，首先生成一个XML文件，与schemaName相对应，生成XML后，在客户端进行压缩和加密等操作，生成一个二进制的字节数组上传    到服务器。

    password

    与读取函数功能相似。

² 返回值

    与读取函数类似，返回字节数组，客户端先要对其进行解压和解密方可使用，尽管很少量的内容返回压缩后反而会更大，但是为了统一的管理方式，仍采用这种方式来工作。

Ø 数据传递

    数据为双向传输，即有些是从第三方系统写入EBS，有些是从EBS读取返回给第三方系统。

    对于单向读取（EBS->第三方），没有数据一致性的风险，直接返回即可，完全通过Schema的添加和配置就可以实现数据安全有效的控制。

    但是对于另一个方面的传输（第三方->EBS），就存在着一个比较敏感的问题，因为EBS的数据结构非常复杂，很难完全掌握它的结构，所以这个方向的传输，一定要把握一个原则，就是只能写到EBS的接口表中，不能直接写入生产表。这部分内容会在Schema部分有更详细的说明。

    在下一期中，我们将来详细的介绍一下系统的安全性。

四、安全体系

    在上面的章节也提到了数据的安全及一些策略，在此将详细的论述安全的数据传输。

Ø SSL体系

    这是一个网络层的解决方案，具体做法是在IIS上配置相应的SSL证书，从而实现一个SSL的站点，安全证书采用VeriSign，可以从中国的代理机构购买。

    SSL的方式会增高系统的安全性，但是也会对性能有一点点的影向，不过不会成为系统的性能瓶颈。

    另外还需要验证是否所有的第三方厂商在写程序的时候都支持这种SSL方式，因此这个体系作为一个可选件存在，可以随时启用，不影响整体的架构。

Ø 压缩与加密

当数据在客户端与服务器通讯的时候，如果不采用SSL的方式，则信息在internet上是可以被截获并破解的，为了解决这个问题，需要对数据做一定的预处理，然后再    进行传输。

    压缩是必选项，采用标准的ZIP压缩算法，客户端采用何种工具进行压缩和解密由客户端自己把握，不提供专门的处理函数。

    对于加密算法，可以采用标准的加密算法，也可以采用自己定义的简单加密算法，也可以暂时不考虑加密，只用压缩来处理，本期暂不考虑加密算法。

Ø 密码串（识别码）

    系统会为每个第三方厂商（系统）分配一个唯一的识别码，为了加强此识别码的强度，采用32字节长度的密码串，此密码串本身没有任何含义，只作为唯一的标识，加大它的长度，即减少了被盗用的风险。

    关于密码串的分发，不考虑程序实现，只用手工处理即可，可以使用邮件的方式来发送。

    为了验证密码串，需要服务器端与客户端都同时存储这个密码串，这样才可以验证。这里的服务器指的是WebService服务器，而不是EBS服务器，因为不方便在EBS中添加过多的定制化内容。

    在服务器端，密码串的存储可以直接使用XML文件或平面文件都可以，这个可以在具体实现的时候再决定，在文件中仅需要简单的存储以下信息：

² 密码串

    用于沟通的字符串，32字节长，手工产生，随意生成，没有规则，只要保证能正确下发到相关的第三方厂商手中即可。

² 厂商名称

    用于标识，系统中不使用此标识。

² 有效起始日期

    大于此日期后，该密码串才被认为是合法的，此字段不能为空，可以靠很小的日期来处理特别情况。

² 有效结束日期

    小于此日期，该密码串才被认为是合法的，此字段不能为空，可以靠很大的日期来认为是无限期的，以上两个日期可以随时调整，以更改密码的可用性。

² 创建日期

    此条记录添加的日期。

² 创建人（字符串描述）

    是谁添加了这条记录。

² 最后修改日期

² 最后修改人

    在服务器IIS启动的时候，在Instance_Startup类型的函数中，加上特别的处理，把所有的密码串全部读出来，放入Global变量中（只读取密码串一个字段，其它均不读入），在WebService的GetData/WriteData函数中，首选检查传入的密码串参数是否是合法的，如果是合法的，再继续后面的操作，如果是非法的，直接返回“非法使用”之类的错误。

    验证函数如下：

    private bool ValidPassword(string password)

    客户端收到总部关于密码的邮件后，所有的操作均必须带着这个密码，如果因为密码填写错误，会造成一系列的错误，需要第三方自己把握。

    关于密码变更：

    密码变更在服务器上需要对原密码的有效结束日期进行更改，并记录更改人；

    同时添加一条新的记录，并确认结束日期合法；

    最后把新的密码下发给第三方厂商。

Ø 数据库表ACL

    原则上客户端会按照约定的规则来读取和写入数据，但是为了防止恶意读写，在此专门设置ACL，控制哪些表可以读写，ACL文件为标准的XML文件，包括以下三个属性：

    ² 表名（大写）

    ² 是否可读（BOOL型）

    ² 是否可写（BOOL型）

    同样，在系统启动的时候，会把这些信息读入到内存中备用。

Ø 私有信息

    同一张接口表中，可能会同时有多个厂商进行操作，这时要保证不同的厂商之间的操作不会互相影响，为此需要在相应的接口表中找一个合适的字段，来存储厂商的密码串。

    在后面的部分，我们将对Schema进行描述，这是数据通信的基本单位。

五、XML Schema

    为了实现更通用性的交互，Schema是最重要的一部分。

    这里的Schema是标准的模版xsd文档，遵循所有的标准规格。

    关于XML Schema的详细内容，在此不做描述，可以从其官方网站上得到解释。

    在读取数据和写入数据的时候，都会用到Schema，Schema就是用来实现对原始表的一个映射。

    在服务器端（WebService服务器）和客户端都存在一份Schema列表，在服务器上存储全部的Schema，但是在客户端，只存储和自己业务相关的部分，不会存储全部Schema。

Ø 数据读取

    Schema文件用于数据的描述，但是和数据库本身没有任何依赖关系，现在需要根据这个Schema来得到一个SQL语句才可以去数据库里取数据。为了简单快速的实现Schema与SQL语句的转换，可以再写一个专门的文件，文件名与Schema相同，扩展名为.select，表示是一个选择数据的SQL语句，此文件只存在于服务器上，客户端不知道此文件的存在。在Instance_Startup的函数中，将所有相关的SQL全部一次性读入到内存中，方便后期快速使用，当然如果有任何这种文件的变化，都需要IIS的重新起动。

    对于where条件，可以作为一个字符串直接拼接在SQL后面，得到一个真正的SQL语句，SQL中没有参数的概念，拼接完成的SQL，在数据库中可以直接使用，为保证SQL的可用性，客户端在写where条件的时候一定要遵循一定的规则，包括and / or 之类的匹配关系，小括号/单引号的使用等，一定要正确。

    对于标准的XML的生成，有两种方案：

    如果Oracle10g支持XML SQL，可以直接生成符合xsd标准的XML文件；

    如果不支持，只能返回一个DataSet，再参考Schema的格式，手工生成一个XML文件。

    生成XML后，调用压缩工具包对其进行相关的压缩处理，生成二进制数组，直接返回。

    如果使用过程中发生错误，则返回“查询错误”之类的代码，可以把相关的错误代码返回。

    在读取之前，需要判断此表在ACL列表中是否可读（如果不好判断，可以跳过此步骤，因为SQL不是客户端可以更改的）。

Ø 数据写入

    数据写入的函数里面有一个字节数组，首先对其进行解压及解密，生成一个XML文件，此文件与Schema配合，读入系统成为一个标准的DataSet，此时可以利用现有的技术直接把该内容写入到数据库中，在写入之前，一定要去ACL中检查一下，此表是否可以写入。

六、EBS端相关操作

    所有的写入操作均写入EBS的接口表中，不会直接写入正式表，因此写入接口表中后，需要调用EBS的标准请求来把接口表写入正式表。

    关于接口表，不同的模块有不同的接口表，并且有不同的操作方式，有不同的请求来实现，所以需要根据实际的接口情况，考虑EBS的接口表及标准请求，并研究标准请求返回的错误信息及含义，还有就是错误返回的存储位置，有些直接回写入接口表，有些会写入标准的错误日志表中，具体在操作的时候再确定。

七、总结

    以上方式已经在我公司得到真正的应用，并已经为多个业务系统服役，使用效果良好，希望大家参考后能有所帮助。

使用WebService与Oracle EBS进行集成