BizTalk 2010 EDI 报文传输

EDI报文可以通过任何协议发送给我们的贸易合作伙伴,例如:SMTP、FILE、FTP、HTTP以及其他的许多协议,在这里就不一一列举了。但是,EDI标准仅支持VAN和AS2。VAN可以确保报文是有效的、将报文路由到合适的收件人以及会有交易的记录,而AS2是一种技术,可以让贸易合作伙伴允许使用S/MIME over HTTP/HTTPS安全地相互传输报文。BizTalk的强大功能可以将各种便准纳入同一个解决方案当中,让贸易合作伙伴无论是要使用AS2还是VAN,都可以通过BizTalk在单一的平台上来构建EDI解决方案。

在BizTalk中查看FTP和VAN与EDI的通信时,你会发现VAN提供的优秀功能,如报文验证、报文跟踪和报文传送等,如今也可以在BizTalk中找到了,在AS2解决方案中,BizTalk是一种“增值网络”。

AS2允许贸易合作伙伴直接通过安全的HTTP相互交流,当EDI中使用了AS2时,就会在端口处设置AS2标准的HTTP适配器来作为交互,或者是其他的相关适配器,不管采用那种方式,核心的概念都是相同的,实现安全的报文传输和对报文的验证。安全传输通过证书来进行处理,报文验证通过AS2、合作对象和BizTalk中的架构配置进行处理。

下图显示的是一个已经配置为允许通过标准的BizTalk HTTP适配器进行AS2传输的合作对象,合作对象已经设定AS2属性,并将用作HTTP适配器的一个扩展,当报文通过HTTP送达时,BizTalk会先将报文的信息和AS2的设置对比较,然后再打开EDI报文,接着会路由该报文,就像通过其他任一方法传送一样,AS2只是提供一种安全的方式,来传输数据以及任何相关的信封信息。

BizTalk 2010 EDI 报文传输_第1张图片

 

透过防火墙传送报文

在这里需要说明一个重要的概念,即如何将报文传送到位于防火墙后面的BizTalk Server服务器,也就是说BizTalk无法在网络上公开存取。当SOAP或HTTP接受端口添加到BizTalk时,该端口就会在本机IIS上工作,并且所有已发布数据都需要发送到该本机web服务器,例如,在使用BizTalk Web service 发布向导时,只能在安装了BizTalk 的本机IIS上创建该web service。

在无法从网络外部存取此IIS服务器的环境中,必须建立某种解决方案来路由通信,有多种解决方案可以解决这个问题,例如将BizTalk服务器置于网络的公共部分,或创建一个反向代理来通过防火墙的路由要求,从而让BizTalk位于private network中。

 

BizTalk 2010 EDI 报文传输_第2张图片

透过防火墙的通信可以通过编写代码的方式实现,因为将BizTalk服务器放在网络中的公共存取部分通常都不可接受,此时安全性的风险太高了。

在公用网络的公用IIS服务器上开发web service时,可以采用多种方法,其中一种是创建网关web service,另一种是创建代理web service。网关web service服务的建立,需要使用自定义编码,还需要进行复杂的格式转换,以符合BizTalk的预期格式,网关会接受来自公共网络的请求,并将其对应到向防火墙后面的web service发出的请求。另一方面,代理 Web 服务的建立,需要修改使用 BizTalk Web Services 发布向导生成的内容,然后将其副本置于公共 Web 服务器上。从其简单性来看,修改代理 Web 服务似乎是最理想的选择。

要创建代理 Web 服务,需要启动 BizTalk Web Services 发布向导。单击该向导中相应的选项,然后定义 Web 服务的发布位置(请注意,虚拟目录创建位置的唯一选项就是在本地 IIS 服务器上)。当向导创建 Web 服务时,实际上是创建了一个代理,该代理可以将来自 IIS 的传入呼叫重定向至 BizTalk MessageBox 中,以便将其路由到相应的业务流程。此代理 Web 服务会自动编码,并且已经进行了预配置,只要传入发布直接进入此 Web 服务器即可正常运行,无需用户进行任何更改。
要使发布进入网络的公共部分并路由到此 Web 服务中,需要执行三个基本步骤。第一步,创建代理到代理 Web 服务。当 Web 服务通过向导导出后,BizTalk 会将其称为代理 Web 服务。若要从外部客户端调用此 Web 服务,就必须在可将请求路由到的公共服务器上创建代理 Web 服务。此操作通过在公共 IIS 服务器上创建虚拟目录即可实现,其中的名称和界面要与生成的代理完全相同。创建虚拟目录后,将原始 BizTalk IIS 目录下所有生成的文件复制到公用服务器上的虚拟目录中。
第二步,修改面向公用网络的 Web 服务,将传入的 SOAP 信息重新路由到承载 BizTalk Server 的 IIS 服务器上的内部代理 Web 服务中,而不是发布到 BizTalk 引擎。要修改的代码会放在一个文件中,该文件位于发布 Web 服务的虚拟目录的 App_Code 子目录下。此文件名称取决于正在发布的实体的名称,但始终以 asmx.cs 结尾。打开此文件将显示类和 Web 方法声明,这就为调用实体提供了一个公共接口,并使这些请求能够直接推入 BizTalk MessageBox 中。
要查看这些生成的代码,需要使用 Web Services 发布向导导出具有双向 SOAP 端口的业务流程。此向导完成后,打开 App_Code 目录中的 asmx.cs 文件查看代码。Web 方法的名称基于业务流程中在端口上定义的操作的名称。此 Web 方法中,代码将接收传入发布并将其转换为可发布到 MessageBox 中的格式。Web 服务将传入发布推入 MessageBox 后,会等待一个响应,该响应对应于业务流程的双向端口中的出站请求,并将其回发给调用实体。将此代码复制并粘贴到公用网络中的新 IIS 服务器后,必须对其进行修改,使其能够将传入发布转发到 BizTalk Server 上的 Web 服务中。
可以使用下图中显示的代码来修改原始的代理 Web 服务代码。此代码首先覆盖原始 Web 服务中的 Web 方法,接着并不是将其发布到 MessageBox 中,而是加载 web.config 文件中的一些可配置字段,并将传入请求发布到 BizTalk IIS 服务器上的 Web 服务中。路由到 BizTalk 引擎的任务,仍然由原始的代理 Web 服务处理。
 
public BTSRedirect.SyncTransResponse Operation_SyncTrans(
  [System.Xml.Serialization.XmlElementAttribute(
  Namespace="http://GuardianProStar.BizTalk.Schemas.SyncTrans.SyncTransRequest", 
  ElementName="SyncTransRequest")] BTSRedirect.SyncTransRequest part)
{
  BTSRedirect.SyncTransRequest objSyncTransReq = part;
  BTSRedirect.SyncTransResponse objSyncTransRes = new BTSRedirect.SyncTransResponse();
  BTSRedirect.GuardianProStar_BizTalk_Orchestrations_SyncTrans_SyncTransactions_Port_SyncTrans 
    objWebServiceMethodCall = new 
    BTSRedirect.GuardianProStar_BizTalk_Orchestrations_SyncTrans_SyncTransactions_Port_SyncTrans();

  // authentication/credentials
  string strWSUser = System.Configuration.ConfigurationManager.AppSettings["WSUser"];
  string strWSPassword = System.Configuration.ConfigurationManager.AppSettings["WSPassword"];
  string strWSDomain = System.Configuration.ConfigurationManager.AppSettings["WSDomain"];
  string strWSAuthenticationType = 
    System.Configuration.ConfigurationManager.AppSettings["WSAuthenticationType"];
  objWebServiceMethodCall.Url = 
    System.Configuration.ConfigurationManager.AppSettings["RedirectURL"];

  System.Net.CredentialCache cache = new System.Net.CredentialCache();
  cache.Add(new System.Uri(objWebServiceMethodCall.Url), strWSAuthenticationType, 
    new System.Net.NetworkCredential(strWSUser, strWSPassword, strWSDomain));
  objWebServiceMethodCall.Credentials = cache;

  // set the response equal to the return value of the call to the web service
  objSyncTransRes = objWebServiceMethodCall.Operation_SyncTrans(objSyncTransReq);

  return objSyncTransRes;

}

由于这两种 Web 服务具有相同的 Web 界面,所以可以使用相同的客户端代码调用任一服务。因此,在开发过程中,您可以使用由向导发布的原始 Web 服务代码来验证是否所有元件都在按预期工作。代理对代理可以在测试和开发的最后阶段创建,也不会影响任何客户端代码。
使用代理对代理 Web 服务的最后一步,是修改公用 IIS 服务器上的 web.config 文件,以便使用可配置字段。新 Web 服务所需的字段如下所示:
由于这两种 Web 服务具有相同的 Web 界面,所以可以使用相同的客户端代码调用任一服务。因此,在开发过程中,您可以使用由向导发布的原始 Web 服务代码来验证是否所有元件都在按预期工作。代理对代理可以在测试和开发的最后阶段创建,也不会影响任何客户端代码。
使用代理对代理 Web 服务的最后一步,是修改公用 IIS 服务器上的 web.config 文件,以便使用可配置字段。新 Web 服务所需的字段如下所示:
 
<appSettings>
  <add key="RedirectURL"  
  value="[redirection URL]"/>
  <add key="WSUser" value = "UserName"/>
  <add key="WSPassword" value = "Password"/>
  <add key="WSDomain" 
    value = "DomainName [Not Always Applicable]"/>
  <add key="WSAuthenticationType" value = "basic"/>
</appSettings>

 

这些设置是针对身份验证值和重定向 URL 提供的。可配置字段的实际列表(以及它们实际存储在 web.config 文件中还是其他位置)由开发人员确定,此处显示的列表仅供说明使用。
通过防火墙的最复杂的发布路由就是 Web 服务的发布路由。HTTP 发布(和 AS2)可以使用相似的方式处理,但不需要复制和修改 BizTalk 中生成的代码。对于 HTTP 发布,可以使用非常简单的重定向模式进行路由,具体取决于发布的性质。许多组织在确定正确的 BizTalk 服务器路由方式时,可能会感到很困扰,重点是,这些类型的会话不应过于复杂,因为有很多简单的解决方案都可以解决这个常见问题。

 

你可能感兴趣的:(Web,服务器,service,防火墙,IIS,2010)