BizTalk Accelerator for RosettaNet的几个问题

        因公司业务需要，我们最近使用了Microsoft BizTalk Accelerator for RosettaNet平台实现B2B的双向通信，主要环境是微软提供的Microsoft SQL Server 2005数据库、Microsoft Visual Studio 2005（所用语言是c#）和一个叫做Microsoft BizTalk Accelerator for RosettaNet 3.5的框架式平台。这个东东比较复杂，公司没有人以前用过，国内用的公司估计也不多（可能是因为要花钱买吧，虽然比EDI要便宜不少），我们也是因为一个比较大的客户用了这个平台，然后要求我们以后跟他们之间的业务往来都要走这个平台，我们才硬着头皮上的。

        安装就很麻烦（要装好几个东东，据说还要配点东西，嘿嘿，这是俺们网管的活），在两台计算机上装上环境后，一台作为发送端的服务器，另一台作为接收端的服务器，根据微软官方的指导文档，在其中一台上生成一堆certifications，将它们在两台机子上配置好后，此两服务器就可以实现安全的双向通信了。然后根据文档的指导步骤，会配置几个系统自带的PIP（Partner Interface Process），他们可以在两个server之间实现自动的双向连接，但是在现实的业务往来时，特别是涉及不同的业务模块和业务类型，这几个PIP是远远不够的。我的主要工作就是上载新的PIP，并参照系统自带的PIP进行一系列的配置和开发，使之能自动实现双向的通信。说起来好像很轻松，事实上在日常的开发中，一些意想不到的问题出现了，我只能摸着石头过河，不断地发现问题、分析问题直至解决问题。下面是我遇到的几个典型的问题，附上详细的解决过程，以作备份。

        一、根据上面说的，上载完一个新的PIP后，模仿系统自带的module作了相关配置，然后进行通行测试，问题出现了：在接收端系统报错，大意是无法找到指定的dtd文件，隐约感觉到是哪里没有配置到。于是静下心来，好好研究一下从发送端到接收端信息的流程，所谓的PIP，其实是两个schema，一个以request标记，另一个则是response，他们之间以一个map实现两者之间的信息映射，所以流程步骤主要有以下几点：1、当发送端发出message后，接收端接收信息：2、接收端将接收的信息与对应的request的schema匹配，并将信息值逐条赋予request的schema；3、通过map将信息值自动映射到response的schema；4、接收端将信息回发给发送端。我们的问题就出现在步骤2，或者说1到2之间，收到的信息是不能与对应的request的schema完全相匹配的，在此之前需要将信息作一些change的，而change时去匹配修改的是PIP的两个属性PIP name和version，这就有问题了，系统自带的PIP当然会有配置这两个属性判断，但我新建的PIP是没有配的呀，那么在哪里配呢？发现DoubleAction中有个headerhelp.cs的文件，它主要是两个函数，实现的功能分别是：1、对接收的message的文件头部进行修改，使之可以与request的schema匹配；2、对从response的schema出来的信息头部进行修改，使之符合发送至发送端的要求。就是它了，于是加上对新的PIP进行判断和修改的语句，然后redeploy。

        二、上一步改后测试，但是没有得到我期望的效果，还是报一样的错，奇怪！用专业工具看headerhelp.cs编译后生成的headerhelp.dll文件，信息也是改后的，真奇怪！下猛药，将headerhelp.cs中的用于自带PIP的语句进行修改（往错里改），同时确认headerhelp.dll中的信息也是跟着改了，测试，没有看到期望的报错信息，太奇怪了！至此，只能说明一个问题，我对headerhelp.cs的任何改动都是在做无用功，或者说程序根本就没有走这里，但可以肯定的说，对信息header改动的逻辑控制就是该文件实现的，那到底问题出在哪里呢？？？还得看官方文档，研究后发现，文档中在自带的PIP配置完毕后，还有一个启动一个叫做setupx64.exe东东的动作，详细看其功能，其中有一个这样描述的："Compiles the HeaderHelper .NET project and registers the assembly in the global assembly cache."梦里寻它千百度啊！没错！就是它！于是双击启动setupx64.exe文件，我所期望的效果终于出现了，OK了！原来，当一开始配置系统自带PIP的时候，系统就产生了一个缓存的headerhelp的逻辑程式，我们在通信的时候，系统都是去调用这个缓存信息来进行逻辑判断的，这就难怪不管我们怎么改headerhelp.cs都石沉大海，一点都不起作用了，直到重新启动setupx64.exe，系统会根据当前的headerhelp.cs语句逻辑重新生成一个缓存，但是对doubleaction中其他部分的修改则没有必要启动这个exe，只要deploy就好，看来这个headerhelp是个特例，也许是因为微软认为很少会改到它才把这个功能设得这么麻烦吧。哈哈，终于找到原因了，感觉很爽！

        三、上面已经解决了接收端信息处理的问题，至此，接收端好像一马平川了，但是......但是问题没有结束，当接收端将处理好的信息回发给发送端，发送端报错了。报错信息是这样的："Receive pipeline rejected incoming message due to the following RNIF exception: UNP.SCON.VALERR : A failure occurred while validating the service content."我查了一下相关资料，该问题一般是由于发送端和接收端PIP的属性配置不一致引起的，好，那我就先让它一致了先，将一端的PIP直接copy到另一端，现在肯定是完全一致了，但问题依旧，这到底是什么原因呢？这个问题太难搞了，花了我很多的时间，我一般就是推断--排除--推断，考虑了N种可能，尝试了N种解决方法，渐渐的眼前的路也越来越清晰了。将从接收端回发的信息copy出来，系统不是说信息有错误吗？那我就找出错在哪里。在新的PIP所在的project中，将该PIP的response的dtd类型的schema的属性框打开，在Input Instance Filename属性中将路径指向copy出来的信息，然后右击该dtd文件，选择Validate Instance，结果跑出来一大堆error，都是针对栏位的，但不是所有的栏位都涉及，分析报错的栏位，这个时候我大概知道问题出在哪里了。request和response的dtd文件是PIP通信的模板，它们包含了所有的栏位，信息完整，而从发送端发过来的message是客户根据自身的业务需要制定的，它不可能也不需要面面俱到，很多栏位是缺省的，这样映射过去的用于回发的信息肯定是有问题啊，解决方法有两个：1、将发送端发过来的message补充完整；2、修改map，对于message中不存在的栏位信息就不映射。第一种显然不太现实，用第二种方法，问题解决了。

        四、还有一点，同一PIP不同version的问题，在二者之间进行通信时可能根本不用考虑此情形，但是当我们需要跟第二甚至更多家公司利用此平台展开业务的时候，很难说对于同一个PIP他们也选择与第一家公司一样的version，这个时候我们就要考虑同一PIP几个version共存的问题。这个问题考虑到了就好，实施起来倒不是很难，加个条件判断就好，就不多说了。

        这样，工作告一段落，但不能说功德圆满，我现在考虑的问题是进一步优化的问题，比如能不能对map进行优化，使之能有判断的功能，如果message栏位存在就映射，否则就不映射。嘿嘿，正在考虑当中。