7

EDI

In the previous chapter we discussed Connectivity and Networking. We talked about the
advanced techniques for Connectiivty and Networking. This included IIS Configuration
and third-party adapters.
In this chapter we will be addressing EDI Administration in BizTalk 2010. The topics
will cover are:
 Trading Partner Management
 X12/EDIFACT/HIPAA Status and Error Reporting
 AS2 Functionality
 HL7 Accelerator for BizTalk 2010
 SWIFT and RosettaNet Accelerators

If we were to try and include everything that there is to know about these topics, it could
take several chapters for each. In this chapter we will only be able to provide what is
essential for Administering EDI in BizTalk 2010.

Hopefully we will be able to cover these topics in depth in a future edition of this
book.

Trading Partner Management

The BizTalk 2010 Management Console provides for an integrated management
dashboard to manage Trading Partners (Party). This feature is new to BizTalk 2010.

Creating a Trading Partner Management Solution

A Trading Partner Management Solution consists of the following:
 Trading Partners (Party) represent the different organizations involved.
 Business Profiles for each Trading Partner or organization within a Trading
Partner.
 B2B Protocol Settings for each Business Profile.
 Trading Partner Agreement (TPA) for each Business Profile.

Trading Partners (Party)

We start off with creating a Party by using the BizTalk Server Administration Console.
MSDN provides a good tutorial on the creation of a
Party.http://msdn.microsoft.com/en-us/library/aa561984.aspx

We could also migrate a party data from previous versions of BizTalk Server.
BizTalk Server 2010 include a Party Migration Tool. Using the tool, users can
migrate the existing party definitions to party definitions that are compatible with
BizTalk Server 2010.

The Party Migration Tool is available on the BizTalk Server on the installation
media in the BT Server\PartyMigrationTool folder.

Included with this tool is documentation on its use.

Business Profile
Once we have created our Party, we create a Business Profile. The Business Profile
contains the following information:
 The Business Profile name.
 Unique identity information that can be associated with the business profile.
 Encoding settings, for the X12 and EDIFACT messages, that will define how the
Business Profile can send or receive messages from another Party.
 Protocol settings for the AS2 Adapter.

Configuring settings for X12-encoded messages

The following diagram shows the step we take to configure our Business Profile for X12-
encoded messages.
2
The steps are as follows:
1. We start by entering the Name and Description for the Business Profile.
Additional Properties (Name/Value pair) can be added. These are for
information purposes only.
2. We then add the Protocol Settings for our X12-encoded messages.
3. First we enter the Name.
4. Next we configure our Inbound Validation settings. These define how
checking for duplicate control numbers is handled.

The following figure shows these settings.

3
 5. Then we configure our Local Host Settings. These govern how our EDI
messages are processed.

The following figure shows these settings.

4
6. We then configure the Transaction Set List. This is the lists of Transaction
Sets that are included or excluded while processing an EDI Interchange.

The following figure shows this setting.

7. Next we need to configure our Transaction Set Validation. These define

how the Transaction Sets are received from a party.

5
 The following figure shows these settings.

8. The last step for our Inbound Transaction Set is to configure Local Host
Settings. These define the schema which is used for processing and
validating the interchange.
The following figure shows this setting.

9. The first step in configuring our Outbound Interchange Settings is to set our
Identifiers. These are used to verify that the interchange is not being
received by unauthorized recipients.

The following figure shows this setting.

6
 Next we configure the outbound Acknowledgments. This specifies how
BizTalk Server 2010 generates acknowledgments in response to X12-
encoded interchanges received from a Party.

The following figure shows this setting.

10. We then configure our Envelopes. These define how the envelope of an
X12-encoded interchange, that is sent to a receiving Party, is generated.

7
 The following figure shows this setting.

11. Next, we configure Charset and Separators. These are used to validate
Party Properties when creating an Envelope for our outgoing X12 message.

The following figure shows this setting.

The Local Host Settings Control Number settings. According to TechNet,

the local host settings govern how the EDI interchanges are processed. The
settings on this page can be divided into two categories – receiver’s settings
(for incoming interchanges) and sender’s settings (for outgoing
interchanges). As part of the receiver’s settings, you can specify whether an
incoming batch will be split into transaction sets or preserved. If preserved,
8
 you can specify whether BizTalk Server suspends the interchange or
transaction set if an error occurs. As part of the sender’s settings, you can
specify how the control numbers are generated for outgoing messages.

The following figure shows this setting.

12. Our last step is to configure our Outbound Envelopes. This defines how
BizTalk Server 2010 generates the GS and ST segments for an X12-
encoded interchange that it sends to the party.

The following figure show this setting

9
 We can have more than one X12 encoding Protocol setting defined for a
Business Profile

Configuring settings for EDIFACT-encoded messages

The following diagram shows the step we take to configure our Business Profile for
EDIFACT-encoded messages.

10
The configuration steps similar to the X12-encoded messages. The steps are as follows:
1. We start by entering the Name and Description for the Business Profile.
Additional Properties (Name/Value pair) can be added. These are for
information purposes only.
2. We then add the Protocol Settings for our EDIFACT-encoded messages.
3. First we enter the Name.
4. Next we configure our Inbound Identifiers. These include the Sender,
Receiver, and Recipient Password.
The following figure shows these settings.

11
 5. Then we configure our Inbound Interchange Validation. This is used to
prevent duplicate control numbers.

The following figure shows these settings.

12
6. Next comes our Local Host Settings. Theses specify how the Interchanges
are processed.

7. The next step is to configure our Inbound Transaction Set List. These
define the schema which is used for processing and validating the
interchange.

The following figure shows these settings.

13
 8. Next is our Inbound Validation Settings. We use this to validate the
transaction sets received from a Party.

The following figure shows these settings.

9. Our last Inbound step is to configure the Local Host. This will determine the
schema that BizTalk Server needs for processing and validation the
interchange.

14
 The following figure shows these settings.

10. Next we configure our Outbound Identifiers. Like the Inbound Identifiers
these include the Sender, Receiver, and Recipient Password.

The following figure shows these settings.

15
 11. Our next step is to set how our Outbound Acknowledgments are handled.
We can specify the acknowledgment and send port types.

The following figure shows these settings.

12. Next comes our Charset and Separators. We use the character set (UNA)
to validate Party properties.

16
 The following figure shows these settings.

13. Next is our Local Host Settings Control Numbers which govern how the
EDIFACT interchanges are processed.

The following figure shows these settings.

17
 14. Lastly, we configure our Outbound Envelopes. These define how the UNG
and UNH segments are generated.
The following figure shows these settings.

18
 We can have more than one EDIFACT encoding Protocol setting defined for a
Business Profile

Configuring settings for AS2 Transport

The following diagram shows the step we take to configure our Business Profile for the
AS2-Transport.

19
The configuration steps are as follows:
1. Like the X12 and EDIFACT steps we first create a Protocol Settings
Name.
For Inbound messages we first configure our Validation. This is used to
validate the AS2 message.

20
2. Next comes we configure the HTTP Settings for Messages. These are
specific properties that the Web Server expects when receiving an AS2
message as shown in the figure below.

3. Then we configure the Receiver MDM Settings. These properties are used
to govern MDN generation based AS2 message headers as shown in the
figure below.

4. The next step for Inbound messages is to configure the Receiver Message
Tracking (NRR). This is used to specify whether the inbound messages and
their acknowledgements (MDNs) are stored in the non-repudiation database
21
 as shown in the figure below.

5. For our first Outbound settings we configure the Acknowledgments. This is

used to specify how the party receiving the AS2 message generates an MDN
response and sends it to back as shown in the figure below.

22
6. Next comes the General Local Host Settings. We use this to specify the
content type of the AS2 messages and whether the file name is preserved as
part of the AS2 message header as shown in the figure below.

23
 7. Then we configure the Outbound HTTP Settings for MDMs. We use this
to specify the properties expected by the Web server that receives the
MDNs as shown in the figure below.

24
8. Next we configure the Sender Message Tracking (NRR). Like the
Inbound settings, we use this is used to specify whether the inbound
messages and their acknowledgements (MDNs) are stored in the non-
repudiation database as shown in the figure below.

9. Our last step is to configure Signature Certificates (AS2). These are used
for signing all outgoing messages and MDN that resolve to this agreement
as shown in the figure below.

25
 We can have more than one AS2 Transport Protocol setting defined for a
Business Profile

Trading Partner Agreement

The Trading Partner Agreement (TPA) is a contract or binding between two trading
partners over a specific B2B Protocol. Agreements bind the common bi-directional
message processing properties of specific Business Profiles between both Trading
Partners. It governs the business transactions between them.
The following figure shows an Agreement between the “Shipping” and “Invoice” profiles
of Party1 and Party2 respectively to use the X12 encoding for business messages which
constitute an Encoding Agreement and an AS2 transport for message exchange, which is
a Transport Agreement.

26
All agreements belonging to a business profile for a pair of trading partners constitute a
Partnership between the two trading partners. All agreements between two Business
Profiles are considered to be Bi-directional .

B2B Protocol Settings

Once we have created our business profiles, the next step is to define the message
encoding formats and transports that constitutes the contract for the sending and receiving
of B2B messages. The B2B Protocol Settings define the communications between the
business profiles and how they will be supported.
The B2B Protocol Settings consist of two categories:
 Encoding Protocol Settings
 Transport Protocol Settings
27
Encoding Protocol Settings
These encoding protocols regulate the structure and content of a message. They define
the encoding protocol that is used to send and receive messages. These include X12,
EDIFACT, HL7, etc.
Within the encoding protocol we are able to define various settings. Examples of these
settings are; Batching and Acknowledgments.
Transport Protocol Settings
The Transport Protocol Settings regulate the Transport Channel that will be used for
sending and receiving messages between two trading partners. An example of a transport
would be AS2.
As with the Encoding Protocol Settings we are able to configure several settings.
Examples of these are; MessagEncryption and Message Signing.
Defining the protocol settings as part of a business profile is optional. If you
don’t specify the protocol settings as part of the business profile, you can always
specify those in an agreement.

Trading Partner Agreements (TPA)

A Trading Partner Agreement (TPA) is defined as a contract or binding agreement
between two trading partners over a specific B2B Protocol. They link the common bi-
directional message processing properties over a specific B2B Protocol.

Bi-directional agreements
Each agreement between two Business Profiles is considered B-directional. In simple
terms, it is a collection of two one-way agreements.
For example, a one-way agreement can be considered as a collection of properties that
define how a message transaction happens from Party1 to Party2. The other one-way
agreement can be considered as a collection of properties that define how a message
transaction happens from Party2 to Party1.
When defining a Trading Partner Agreement we need to consider the following points:
 For two business profiles that exchange B2B messages with each other, defining
a message encoding agreement is mandatory. The divisions may choose to have
an AS2 agreement only if they want to use the AS2 protocol to transfer
messages. For example, an AS2 agreement is not required if the business
divisions choose to transfer messages over e-mail

28
 If two business profiles support both X12 and EDIFACT encoding and both
business profiles agree to use both encoding protocols while exchanging
messages, there should be separate agreements for each protocol. There should
be one agreement for X12 protocol and one agreement for EDIFACT protocol.
There cannot be a single agreement that can be used for both protocols.
 The encoding agreement for X12 and EDIFACT messages and transport
agreement (for AS2) cannot be part of one agreement. You must create separate
agreements for both

Now that we know what a Trading Partner Management

Solution is, our next step is put it all together.
The following diagram shows the steps we must take to create a TPM solution.

To summarize our steps:

1. We first create a partner (Party) that represent all the internal and external
organizations that are we do business with.
2. For each organization or business division within our Party we create a
Business Unit Profile. We must also create one for both our internal and
external organizations.
3. Finally, for each Business Unit Profile we define the B2B Protocol Settings
which includes the message encoding and protocol properties.
4. Lastly, we create Trading Partner Agreements (TPA) between the business
profiles that define the encoding and/or messaging protocols the two
business profiles agree to use while exchanging messages.

29
Once these tasks have been completed we are now ready to exchange B2B messages
without Trading Partner.

AS2
One of the most common ways of transferring EDI messages over the Internet is by using
EDIINT-AS2 (EDI over the Internet - Applicability Statement 2). It is commonly
referred to as AS2.
AS2 uses the HTTP POST operation to send EDI, XML, or other business data.

AS2 is not restricted to sending EDI data.

AS2 Transport
EDI transports operate on the transport layer of the EDI model. They provide support for
the AS2 protocol.

AS2 Messages
 AS2 messages are always sent using HTTP protocol
 The basic structure of an AS2 message consists of MIME format inside an HTTP
message with additional AS2-specific headers.
 Optionally the messages can be signed and encrypted.
o Certificate-based message encryption and signing
o Strong traffic encryption (TLS)
o AES
o SHA2

MDM Messages
In response to an AS2 message, a message disposition notification (MDN) is returned
as an acknowledgment.

This is only provided if the sender of the AS2 messages expects an MDN.

According to MSDN, the Message Disposition Notification (MDN) is the

acknowledgment sent in response to an AS2 message. If an MDN is enabled, the AS2
transmission is not complete until the MDN has been received and verified. BizTalk
30
Server will always attempt to return an MDN to indicate the status of message
processing, even if an error occurred in processing the AS2 message.
The MDN provides verification of the following:
 That the original message was successfully received by the receiving party. The
sender of the original message verifies this by comparing the MessageID of the
original sent message with the original-message-id field that the receiver
included in the MDN.
 That the integrity of the data exchanged was verified by the receiving partner.
The sender of the original message verifies this by comparing the MIC that was
calculated from the original sent message, with the MIC that the receiver
calculated on the received message and included in the Received-content-MIC
field of the MDN (if signed).
 That there is a non-repudiation of receipt. The sender does this by verifying the
signed MDN with the receiving partner's public key, and by verifying that the
returned MIC value in the MDN is the same as the MIC for the original message
stored in non-repudiation database.

AS2 Security
BizTalk 2010 enables us to secure AS2 messages by using encryption keys, digital
signatures, and certificates. This is all handled within the administration console. We do
this by setting the appropriate properties for the AS2 pipelines and Parties.
Certificates Required for AS2 Transport
In order for us to secure AS2 data transfer we need to add the correct certificate store and
then associate it with the appropriate BizTalk artifacts. The following table shows the
certificates that are used along with the appropriate artefact.
Certificate Certificate Pipeline User Certificate Store
Usage Type Component Context
Signature Own private AS2 Account Current User\Personal
(outbound) key (.pfx) encoder used by the store of each BizTalk
host Server that hosts an AS2
instance encoder pipeline as each
associated host instance service
with the account
send
handler
Decryption Own private AS2 Account Current User\Personal
(inbound) key (.pfx) decoder used by the store of each BizTalk
host Server that hosts an AS2
instance decoder pipeline as each
31
 associated host instance service
with the account
receive
handler.
Signature Trading AS2 Account Local computer\Other
verification partner's decoder used by the People store of each
(inbound) public key host BizTalk Server that hosts
(.cer) instance an AS2 decoder pipeline
associated as each host instance
with the service account
receive
handler.
Encryption Trading AS2 Account Local computer\Other
(outbound) partner's encoder used by the People store of each
public key host BizTalk Server that hosts
(.cer) instance an AS2 encoder pipeline
associated
with the
send
handler.

Outgoing AS2 messages are signed using a default certificate defined as part of
the BizTalk Group properties.

Status Reporting
BizTalk 2010 provides for comprehensive EDI and AS2 Status Reporting directly within
the Administration Console. These reports provide us with information on Receipt,
Validation, Batching, and Acknowledgment processing of messages.

In order use this functionality, EDI and AS2 Status Reporting must first be
enabled.

Whenever status reporting is enabled, all status will be saved in storage. By

customizing the query expression or status columns, you are defining which
saved data is displayed.

32
Within the Group Hub page of the BizTalk Group node, we have links to:
 EDI Interchange and correlated acknowledgment status
 Batch Status
 AS2 message and correlated MDM status.

The following table shows the these reports:

Report Type Higher-level Report Lower-level Report
EDI EDI Interchange and Interchange Status and
Correlated ACK Status ACK Details
Transaction Set Details
EDI Message Content
Batch Status
Interchange Aggregation
Report
Transaction Set
Aggregation Report
AS2 AS2 Message and AS2 Message Content
Correlated MDN Status

EDI Interchange and Correlated ACK Status Report

When generating this report we have several Interchange/Ack Status values we can select
from as show in the figure below.

33
Batch Status Report
This report allows us to specify the value of the Batch Status as shown in the following
figure.

Error Reporting
We have the option to display enhanced error and warnings. These are displayed in the
Windows Event Viewer.
We can enable these as part of an Agreement or as part of the Fallback Agreement. As
part of an agreement, this reporting is enabled by default.

All System/Processing errors generated by BizTalk are always logged in the

Event Viewer. You can read more about this in Chapter 3 - Monitoring

EDI Acknowledgment Error Codes

 X12 TA1 Acknowledgment - Reports the status of the processing of an
interchange header and trailer by the address receiver. When the ISA and IEA of
the X12-encoded message are valid, a positive TA1 ACK is sent, whatever the
status of the other content is. If not, TA1 ACK with an error code is sent.
 X12 997 Acknowledgment Error Codes – Reports the status of a received
interchange. Includes each error encountered. Supports both 4010 and 5010 X12
Transaction Sets.

34
 EDIFACT CONTRL Acknowledgment - Serves as both technical and
functional acknowledgment for EDIFACT-encoded messages. It indicates receipt
of an interchange.
According to MSDN, BizTalk Server 2010 includes BAM activities that have been
created for EDI and AS2 status reporting. These activities determine the data that is
displayed in the status reports. More information about BAM activities, fields that are
defined in them, along with the enumeration values that are defined for certain fields can
be found on MSDN. http://msdn.microsoft.com/en-us/library/bb743626.aspx

We also have the ability to create a custom status report by creating a new custom BAM
Activity. You can find out more on this topic at http://msdn.microsoft.com/en-
us/library/bb743626.aspx

ESB Exception Framework

The ESB Management Portal provides us with the ability to discover errors that occur
when processing our EDI messages. We talked about this in Chapter 3 – Monitoring.

HL7 Accelerator for BizTalk 2010 (BTAHL7)

We configure and administer HL7 Messaging by using the BTAHL7 Configuration
Explorer. His allows us to configure batch definitions, acknowledgements, and logging
data store settings.
By using the BTAHL7 Configuration Explorer, we can initiative activation, request, and
termination of batch processing at the party level.
Configuration starts off with the Global Settings.

Global Settings
From the Global Settings tab we can configure our Logging Store. We can either use
WMI or BizTalk 2010 SQL Server. Writing to the Event Log is an option.
Messages that pass through the HL7 accelerator, can include a patient’s medical record or
financial transactions. Because of this we need the capability of logging this information.
The Logging Store provides us with the capability.
There are two types of data that is logged:
 Configuration data - Logging configuration data is stored in the Configuration
database (also known as the BizTalk Management database) and includes SQL

35
 auditing information and audit data (Windows NT Event viewer, centralized
database WMI) location.
 Archival data - The EventLog table in the SQL log stores the 'Logging' data

The following figure shows these settings.

Configuration:
Party Alias
These setting are also available in the BizTalk Server 2010 Party Configuration.
The following figure shows the settings available.

36
Batch Definition
There are three types of Batch Definition Scenarios supported:
 Fragmented inbound batch - BTAHL7 receives an HL7 message batch, and
then routes the individual messages to the destination system.
 Batch in/batch out - BTAHL7 receives an HL7 message batch, verifies the
individual messages within the batch, and then routes the message batch to the
destination system.

37
 Create batch or outbound batching - BTAHL7 receives individual messages
and batches them before routing them to the destination system.
The following figure shows the settings available.

Batch Schedule
This allows us to configure the Batch Schedule and the ability to activate, request, or
terminate an outbound batch.
Activating an Outbound Batch is handled in two steps:
38
 1. Time-based or message count
The following figure shows the settings available.

Acknowledgment
We can specify the acknowledgment properties for inbound and generated
acknowledgments.
We can select from five acknowledgement types:
 None
 OriginalMode
 EnhancedMode
39
 DeferredMode
 StaticMode

The following figure shows the settings available.

Validation
We use these settings to validate our messages against the HL7 Standard for Inbound and
Generated Messages.
The following figure shows the settings available.

40
MSH Map
This allows us to override the Messager Header transformation values for Inbound
Messages.
The following figure shows the settings available.

41
Help Desk
We can use the Help Desk to store general information about the Destination or source
Party.
The following figure shows the settings available.

42
MLLP Transport Types
Minimal Lower Layer Protocol adapters are commonly known as MLLP Transport
Types. They are used to process HL7 V2.X MLLP-encoded messages.
The adapter is configured for both the sending and receiving of these messages. The
configuration parameters fall into two types: block characters and network connection
parameters.
More information can be found on MSDN http://msdn.microsoft.com/en-
us/library/ee409463.aspx

Block Characters
These are special characters that must enclose HL7 messages.
43
Delivery Mode
We use this parameter to control how instance files are delivered. They can be in
sequence or out of sequence. Each receive location has its own delivery sequence.

Network Connection Parameters

These settings are used to establish a network connection. The parameters include
connection name, host name, port ID, receive and send timeout, and comments.
 Host – MLLP Receive and Send
 Persistent Connection – MLLP Receive and Send
 Port – MLLP Receive and Send
 Send Timeout – MLLP Send
 Receive Timeout – MLLP Receive
 Solicit Response Enabled – MLLP Send
 Submit Receive Location URI for ACK – MLLP Send

MLLP Receive Adapter Processing

The adapter supports both one-way and two-way response modes.

When the MLLP receive adapter operates in two-way mode, the adapter will not
receive a new message from the connection until the pipeline has generated the
acknowledgment (ACK) for the previous message.

Two-way response mode Acknowledgments

The following types of ACKs can be generated:
 HL7 Enhanced Commit ACK - BTAHL7 sends a Commit ACK on the same
connection. It sends out an Application Accept ACK on a different send port.
 Application Accept ACK - BTAHL7 sends an Application Accept ACK on the
same connection.
 Static ACK - BTAHL7 sends an ACK on the same connection.

The type of ACK generated depends on the BTAHL7 Configuration Explorer

settings for the party sending the message

Error Conditions
44
The following conditions will generate error events:
 Receive Location is disabled.
 Inactivity is detected.
 Incomplete message received.
 Pipeline fails to parse message.
 Message fails due to absence of subscription.

MLLP Send Adapter Processing

Both one-way and two-way transport mode are supported in the following configurations.
 Two-way solicit-response send adapter
 One-way send adapter configured to receive acknowledgments (ACKs)
 One-way send adapter configured for no return messages

Two-way solicit-response send adapter

This scenario is used for a true end-to-end synchronous process. The send adapter will
continuously maintain an open connection against the remote party (URL) until it routes
a return message to the request response receive port.
One-way send adapter configured to receive acknowledgments
(ACKs)
This adapter receives ACKs on the same socket connection that it sends the original
message on, and delivers the ACKs to the receive location. The send adapter
continuously maintains an open connection against the remote party (URL), even if no
messages are waiting for BizTalk Server to send them to it. If several ports are pointing
to the same remote party, the send adapter maintains one connection for each send port.
One-way send adapter configured for no return messages
When a one-way MLLP send adapter configured for ACKs receives one, BizTalk Server
deletes the original message from the MessageBox database, retries it, or suspends it,
depending on the type of the ACK. BTAHL7 parses the ACK in two phases:
1. The first phase is done in the send adapter where BTAHL7 parses the field
MSA1 to determine the type of the ACK.
2. In the second phase, BTAHL7 performs a complete parsing of the ACK,
and then submits the ACK to the MessageBox database.

45
SWIFT
The Microsoft® BizTalk 2010 Accelerator for SWIFT (A4SWIFT) provides support for
Society for Worldwide Interbank Financial Telecommunication (SWIFT) message
formats. More information can be found on Microsoft TechNet
http://technet.microsoft.com/en-us/library/ee350746.aspx

Administrative Operations
The administrative operations that pertain to the Microsoft BizTalk 2010 Accelerator
for SWIFT (A4SWIFT) are as follows:
 The SWIFT Accelerator handles message validation by using the Business
Rules Engine (BRE). The full description can be found in the SWIFT Reference
Guide.
 Customizing Message Repair and New Submission – includes changing Fields
to be Rekeyed, creating a custom handler for Rejected Messages, Defining
custom BAM views, modifying a workflow, and enabling or disabling BAM
Tracking.
 Administering FIN Response Reconciliation by setting the FRR Delay Time-
out
 Backing up the A4SWIFT Database – See Chapter 1 – Backup and Recovery

A complete description of these operations can be found on TechNet

http://technet.microsoft.com/en-us/library/ee350733.aspx

BizTalk Accelerator for SWIFT Message Pack 2010

Provides schema updates for BizTalk Accelerator for SWIFT to comply with SWIFT
worldwide 2010 Standards Release Guide Specification.
http://www.microsoft.com/download/en/details.aspx?id=3637
The message pack 2010 provide the following features:
 The repackaging of all SWIFT FIN FF message types and of all business rules
 Updates to schemas and to business rules to make the schemas and the business
rules fully compliant with the SWIFT 2010 certification requirements
 All the hotfixes that are related to schemas and to business rules but that are not
superseded by the SWIFT 2010 certification requirements BizTalk Accelerator
for SWIFT Message Pack 2010 does not contain any components other than
schemas, business rules, and Microsoft Office InfoPath forms

46
RosettaNet
The Microsoft BizTalk 2010 Accelerator for RosettaNet (BTARN) Management
Console lets you administer all facets of the BTARN configuration from one user
interface. The BTARN configuration includes process configurations, home
organizations, partners, and trading partner agreements.

BTARN Management Console

From the BTARN Management Console, you can also manage certificates, administer
instances of Microsoft SQL Server™, view events, and view performance logs and alerts.
The following figure shows the BTARN Management Console.

If we expand the BizTalk Accelerator for RosettaNet node the following tools are
available.
 Operations
o Assign the BTARN send and receive pipelines for our partner
send ports.
o Enable BAM tracking.
 Process Configurations Settings
o Add, Edit, or Delete a process configuration
o Clone and modify an existing process configuration.
o Display a list of all the Agreements that a process configuration
is associated with.
 Home Organizations
47
 o Add, Edit, or Delete a Home Organization.
 Partners
o Add, Edit, or Delete a Partner.
 Agreements
o Add, Edit, or Delete an Agreement
o Activate an Agreement
o Revert to a complete list of Agreements.

Summary
In this chapter we learned about the essentials of EDI Administration in BizTalk Server
2010.
We learned about the new Trading Partner Management features in BizTalk 2010. We
also learned how to create a Trading Partner Management Agreement and Business
Profiles.
We learned about the AS2 Transport and how it’s used.
We learned about EDI Status and Error Reporting.
We were introduced to the HL7 Accelerator for BizTalk 2010 and the MLLP Adapter.
We were also introduced to the SWIFT and RosettaNet Accelerators.

48