Transport Types

Included in Link

The following outbound transport types are included in the Link:

• FTP
  BizTalks FTP adapter is configured dynamically for transmission.
• eMail
  BizTalks SMTP adapter is configured dynamically for transmission.
• File
  BizTalks FILE adapter is configured dynamically for transmission.
• Reflection
  A fully qualified type name is specified in the transport configuration, so that developers can make custom transport types very easy and fast.
• Oracle
  Can be configured to invoke stored procedures on Oracle databases.
• SOAP
  Can be configured to call webservices.
• AS2
  Can be configured to transmit messages through the AS2 protocol.
• StaticPort
  Can be used to refer to at static port in BizTalk server. The Static port must have a filter that reference the same name you setup in Link. E.g. Ebex.EdiPortal.Common.BizTalkCommonProperty.StaticPortName == ToVans
  • In case you need to divide into different staticport you have the option of promoting a value from the ingoing document to Link common property schema Transport, with name "StaticPortFilterKey1" (or StaticPortFilterKey2) and you can then use this property on your send port as well to subscribe to in case you need to hit a different staticport depending on a value in the ingoing document.
    

Custom transport types

Any BizTalk adapter that supports dynamic transmission can be incorporated into the Link as a transport type. The way this works is that you implement a pipeline that populates the context properties necessary for dynamic transmission. This pipeline will be executed before sending the message to the dynamic send port.

A transport type needs to be created with the Link Administration application (later described in this document). It is possible to retrieve values from fields declared for the given transport types with the Link API.

The following assembly files needs to be referenced in the pipeline component implementation.

• EdiPortal.Common.dll
• EdiPortal.Common.PipelineComponents.EdiPortalExtensions.dll

The method below can be used to load information about the transport configuration during runtime (extension method for IBaseMessage located in namespace Ebex.EdiPortal.Common.PipelineComponents.EdiPortalExtensions):

TransportConfiguration transportConfiguration = inmsg.LoadTransportCongurationFromContext();

After loading the configuration field values can be requested with the GetValue method on the TransportConfiguration object.

string url = transportConfiguration.GetValue("DestinationUrl", true);
string authenticationType = transportConfiguration.GetValue("AuthenticationType", true);

These values can then be used to populate the context properties necessary for dynamic configuration and execution of the adapter.

There are two special context properties that needs to have values:

• Address (target namespace: https://Ebex.EdiPortal.MessageFlow.Transport.Schemas.AdapterConfiguration).
  This value is passed to Microsoft.XLANGs.BaseTypes.Address when the adapter is being configured.
• TransportType (target namespace https://Ebex.EdiPortal.MessageFlow.Transport.Schemas.AdapterConfiguration).
  This value is passed to Microsoft.XLANGs.BaseTypes.TransportType when the adapter is being configured.

Additional ways of transmitting data

If you have a requirement for a type of outbound transport, that can’t be met by the transport types in the Link, there are two ways of doing this: use the Reflection transport type mentioned above or use the EDI Administration Tool to add a new transport type. The difference of these to is that adding a new transport type means adding support for a new BizTalk adapter in the Link. It is required that the adapter can be configured dynamically to transmit messages (read about how to do this in the section about using the tool). For using the Reflection transport type you need to implement a public method with one of the following signatures:

public void SendMessage(XmlDocument xml);
public void SendMessage(string argString, XmlDocument xml);

So when you have compiled your assembly, and deployed it to the GAC for your BizTalk servers you can create a partner location in the user interface, where you specify the following:

• Fully qualified assembly name
• Class name
• Method name
• Parameter Xml

The first three are self-explanatory. The last is passed to the “argString” parameter. If you used the signature with only one parameter, any value inserted in this field will be ignored. Even though the user interface indicates that it has to be an XML string, it is not so. But it is however a nice and easy way to pass multiple arguments to your method. The “xml” parameter in both signatures will be the body of the message being transmitted.