To fix it, you need to promote the Filename property.

Assuming, you are using XML One-Way Bridge

Edit Enrich stage by clicking on “Property Definitions - “Collections”

Promote the property to “Filename”. Here I am simply promoting RequestId.

Then on the connector go to “Route Action – Collection” and add the Filename property to the Ftp destination.

Now once you deploy the solution and test the message again, the message should be successfully routed to the FTP destination.

The tracked data (storage and SQL) is not archived by default. Manual intervention is required to clean up the data.

If you are unable to get the tracking records on the Tracking portal, but the runtime environment is working fine, then most likely the tracking data has reached to a limit where it is causing the query performance issues.

The best way is to begin with purging the data as explained in the previous blog section - How to Manage Tracked Records

Even after cleaning the reasonable data, if you still continue to get error on the portal, check if you are able to query the SQL database directly.

You can use SSMS to connect to SQL Azure. To get details of the SQL Azure being used, you will need to go to Azure portal/click BizTalk Services. On the dashboard tab, you will see the SQL Azure Database being used for tracking. If you click the database name, it will take you to the database page. Click Dashboard. On the left you will see ‘Show connection string’. Click this and it will show you the database name and the user ID for the database.

Once connected, try running a simple query like Select * from TrackRecordProperties2. If this query is taking long time or not completing, it indicates you need to clean some more data.

For some of the customers’ the retention policy may add burden to the Tracking database or because of business volume even small number of days may contain a large amount of data. If data sizing guideline don’t go well with retention period, other option is to backup data to some other SQL server before purging from the tracking store till Tracking query performance is optimized.

Other option is to upgrade the SQL Azure server to higher edition / performance level which will provide more processing power to handle large tracking environments. The article below helps you understand move the database from Web/Business edition to New Service tiers.

https://azure.microsoft.com/en-us/documentation/articles/sql-database-upgrade-new-service-tiers/

Run the following query on the master database to retrieve the average DTU consumption for a database:

SELECT start_time, end_time
,(SELECT Max(v)
     FROM (VALUES (avg_cpu_percent)
                , (avg_physical_data_read_percent)
                , (avg_log_write_percent)
       ) AS value(v)) AS [avg_DTU_percent]
FROM sys.resource_stats
WHERE database_name = '<your db name>'
ORDER BY end_time DESC;

Here is a table that provides a mapping of the Web/Business resource consumption percentage to equivalent new tier performance levels:

Difference between Tracking and Tracing

It’s important to understand the difference between tracing and tracking and what data is collected in each one of them. For most cases unless you are tracing from custom code, tracking should be sufficient.

Insight to Tracking Tables

Tracked records are stored in the SQL database.

The tracking database exposes a GetTrackRecords stored procedure that can be used for retrieving the track records as well as automation of failure notification. The main tables in the database are:

Table	Comments
EndpointAddressMap	Contains mapping of Bridge Endpoint Name to Endpoint Id which is used in the PipelineTrackRecords table.
PipelineTrackRecords	Contains the track records with names of stages, activities and the status of each.
TrackRecordRecordProperties	Contains detailed status for events with Parent Id corresponding to Id of PipelineTrackRecords record.
TrackRecordMessageProperties	Contains user defined and default promoted properties like X_PIPELINE_REQUESTMESSAGETYPE and X_PIPELINE_MESSAGETYPE

What Gets Tracked?

There is a very good blog from the BizTalk Services Product team that covers the details of tracking. I have copied the same content below.

https://blogs.msdn.com/b/biztalk_server_team_blog/archive/2013/06/28/debugging-eai-bridges-with-tracking-and-tracing-i.aspx

· Operational Events are tracked. (Example: The different stages that are executed)

· It tracks the errors that happened.

· Message Properties

· EDI Message body(this is stored in blob storage)

Pipeline and Source Track Records

Track Records can be emitted by the Pipelines as well as FTP and SFTP Sources. Pipelines can emit below information and error events based on the configuration:

1. Pipeline started

2. Pipeline completed

3. Stage started – emitted for all the Enabled Stages like xmlvalidator, requestMessageExtractor, requestMessageTransform, transformedResponseEnrich, route, sendReply and others.

4. Stage completed

5. Artifact Retrieved - for artifacts like schemas and transforms

6. Custom – emitted from custom code inspectors when they are set.

7. Route – show the route status for the message ie faulted or success.

8. Faulted – when any error is thrown like lookup failed, validate failed

With "Track All Message Processing Events" option set to true all the above events get saved in the tracking database, but the BizTalk Portal Tracking section will only show last four events. For EAI scenarios, FTP and SFTP Sources emit below events to the tracking database.

1. TrackSubmitted – emitted when the message is submitted to the pipeline

2. TrackProcessed – emitted when the message is deleted from the source. Faulted when delete fails as in case of read only user.

3. TrackStatus – emitted on source start and stopped. Faulted when service cannot connect to the FTP server.

4. TrackRetrieved – error event is emitted when the file cannot be retrieved from the server in cases like it being a subfolder inside the FTP folder. Error looks like ‘The remote server returned an error: (550) File unavailable (e.g., file not found, no access)’.

5. Poll Error – emitted when one of the above errors happen. The poll interval in increased to 1.5 times on each poll error in order to give time to rectify the issue.

6. Listing error – emitted when the listing of the files fails eg when the configured FTP folder is deleted

The Tracking portal will only show error events for the sources.

EDI Message Body Tracking

The EDI message body tracking when turned on is tracked in the blob storage. A blob container gets created every day and it contains the message body. You can use the Azure Storage Explorer.

How to enable tracking

Tracking can be enabled and disabled as needed. You can enable tracking at 2 places:

Pipeline. In VS, select your bridge. In Tracking Properties you can enable the tracking for the pipeline.

The 2^nd way to enable tracking is for B2B. Go to BizTalk Services Portal. Click respective EDI / AS2 bridge and check the tracking options. You will need to Deploy the bridge after making the changes.

How to View the tracked Records

There are 3 ways to view the tracked records. The tracked records go to the SQL database.

1. The easiest way to view the tracked records is from BizTalk Services Portal. Click tracking on the left and you should be able to view the tracked records. To open and view each record in details, click the record and click details at the bottom.

2. You can also view the tracked records from the BizTalk Services Explorer

3. The 3rd way is directly from SQL Azure Server. You can use SSMS to connect to SQL Azure. To get details of the SQL Azure being used, you will need to go to Azure portal/click BizTalk Services. On the dashboard tab, you will see the SQL Azure Database being used for tracking. If you click the database name, it will take you to the database page. Click Dashboard. On the left you will see ‘Show connection string’. Click this and it will show you the database name and the user ID for the database. Looking at the tracked records directly from SQL may not be very useful.

How to Manage Tracked Records

We have seen how to enable and view the tracking records. The tracking database needs to be managed (delete older records) by the customers. Currently you can delete the tracking records in 2 ways
1.    Using the PowerShell cmdlet Clear-AzureBizTalkTrackingStore
https://msdn.microsoft.com/en-us/library/windowsazure/dn232411.aspx

•    Run the following command to register the BizTalk PS cmdlet
import-module "C:\Program Files\Windows Azure BizTalk Services Tools\Microsoft.BizTalk.Services.Powershell.dll"

•    You may need to Gac  the storageclient.dll manually - gacutil /i Microsoft.WindowsAzure.StorageClient.dll

•    The following command clears the SQL Tracking data until the date/time specified. Before you run this command make sure that you have updated the sqlString.txt and AzureStore.txt files with your SQL Azure and Storage details.

Sample AzureStore.txt DefaultEndpointsProtocol=https;AccountName=mystorageaccount;AccountKey=accountkey

Sample SQLString.txt

Server=tcp:mydb.database.windows.net,1433;Database=mydb;User ID=user@mydb;Password=password;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;

Clear-AzureBiztalkTrackingStore -Sql (Get-Content sqlString.txt) -AzureStore (Get-    Content AzureStore.txt) -Ndays 2 true -NoPrompt

2.    Using the truncate stored proc to clear SQL Tracking data only. You can run the following stored procedures to delete the tracking records older than the specified date
       PurgeBridgeTrackRecords '2013-09-12'
       PurgeB2BTrackRecords '2013-09-11'

Tracing

Tracing is enabled by default. This feature cannot be turned off. Tracing information is stored in Azure Table and Blob Storage. You can use any storage tool to view this information.
A free tool that I like is Azure Storage Explorer. This can be downloaded from https://azurestorageexplorer.codeplex.com/

Tracing captures perfmon logs, ETL files and tracing information emitted by custom pipeline code. The ETL information is not much use to end customers because it needs formatting which in turn needs Manifest which is not available publicly.  The ETL files are more for internal use by the support team.
However the custom code tracing information emitted by custom pipeline is most useful to customers. This is stored in the WADLogsTable. You can use the following code to configure tracing from custom code. context.Tracer.TraceEvent(TraceEventType.Warning, "Value: {0}", propertyValue). This is stored in WADLogsTable.
The tracing information is automatically deleted after 60 days. Hence the most information you will have is worth of 60 days.  You can manually delete some of the tracing information if you do not want to logs too large. You can delete the etl files from the container named similar to your BizTalk Services name.

In BizTalk Admin Console, create a new Receive Port “RPForMABSRelayTest”.

Add a new receive location “RL_HTTPTestRx” with type WCF-BasicHttpRelay

Click on “Configure” and provide the Service Bus Namespace URI + logical name with which this relay will be identified. Here I gave name “HTTPInbound”.

Click on Security tab and provide “Access control service” information. Note that this ACS information is for Service Bus and not the MABS connection information. You need to capture this information from Azure Management Portal by selecting Service Bus namespace of your interest. Complete the configuration of the port by clicking on OKs.

Enable the receive location. now if you go to the Relays section under the Service Bus Namespace on the Azure Management Portal, you will see a listener with the name HTTPInbound.

Create and sample send port to send the messages to a file location. Add the Filter to get messages from the receive port created above. Start the Send Port.

Now create a BizTalk Service project in VS.
In the MessageFlowItinerary update the BizTalk Service URL property to use your BizTalk Service name.
From “Bridges”, drag and drop Pass-Through Bridge on the itinerary designer. Name it as MABSRelayTest
From “Destinations”, drag and drop One-Way Relay Endpoint on the itinerary designer.
Double click on the One-Way Relay Endpoint to open the config file. Modify the address to use the URI that was used in the BizTalk Server Receive Location.

<endpoint
        name="OneWayRelayServiceReference1"
        address=https://sbnamespace.servicebus.windows.net/HTTPInbound
        binding="basicHttpRelayBinding"
        bindingConfiguration="basicHttpRelayBinding1"
        behaviorConfiguration="serviceBusCredentialsBehavior"
        contract="System.ServiceModel.Routing.ISimplexDatagramRouter"/>

Modify the behaviour “serviceBusCredentialsBehavior" to update Service bus namespace connection information (same way you configured “Access control service” for BizTalk Receive Location.

<behavior name="serviceBusCredentialsBehavior">
    <!-- TODO: Uncomment the transportClientEndpointBehavior block below if RelayAccessToken -->
    <!-- security will be used. Also update the issuerName and issuerSecret values -->
    <transportClientEndpointBehavior>
        <tokenProvider>
            <sharedSecret issuerName="owner" issuerSecret="issuerSecretissuerSecretissuerSecretissuerS=" />
        </tokenProvider>
    </transportClientEndpointBehavior>
</behavior>

And lastly for basicHttpRelayBinding make sure the security mode is set to Transport.

<security mode="Transport" relayClientAuthenticationType="RelayAccessToken" />

Save the config file and close it.

From “Bridges” use the connector to connect “MABSRelayTest” and “OneWayRelayServiceReference1”
For the connector “One Way Route Connection” properties , set the Filter to “Match All”.
Deploy the solution. (The steps are similar for the WCF-NetTcpRelay adapter.)

Go to Server Explorer and open “Windows Azure BizTalk Services”. Expand your BizTalk service and send test message to the bridge “MABSRelayTest”
You may refer to Test the Bridges - Post messages – 3 easy tools for the developers

And I get the error message “FAILED. 500 Internal Server Error” : The one-way operation returned a non-null message with Action=''.

If I go to the BizTalk Service Portal and check the Tracking, it shows that the Routing was successful and Route Activity Showing the same error.

If you are using WCF-NetTcpRelay, then error looks like

"The channel received an unexpected input message with Action '' while closing.  You should only close your channel when you are not expecting any more input messages."

Now, when I go and check the Send Port’s destination folder, I see that the message is delivered successfully and no error on the BizTalk side..

So why this error is coming in MABS? This is an issue with the BizTalk Server on premise – and its by design – WCF Adapter cannot handle one-way contracts so gracefully out of the box.
To get around this error, you can send back a null message as explained in Using One-Way Operations with the WCF Adapter in BizTalk by using the sample binding provided by Mustansir .
NOTE mentioned in his blog: In order to use any of the workarounds above you need to use the WCF-Custom adapter, since that is the only adapter which allows you to add behaviors or configure the customBinding binding with user-specified binding elements.

You may face errors while doing the tutorials that require Relays / Service Bus - where you are supposed to Create LOB Relay and Target for the Operations.

Message: 'Error occurred while trying to bring up the relay service. Error Message: 'The remote name could not be resolved: 'mysbname-sb.accesscontrol.windows.net'

The issue is because any Service Bus namespace created via portal after August 2014, will not have an accompanying ACS namespace and MABS relies on ACS for the authentication. We are working on SAS support within BizTalk Services. Till then, please use PowerShell command New-AzureSBNamespace to create the Service Bus namespace which allows to create ACS namespace. For more details, have a look at Service Bus namespace creation on portal no longer has ACS connection string

Trying to use newly created Service Bus Queue on the receive side. While deploying the VS project, getting an error.

Error 1 QueueSource1 deployment failed at 'https://mymabs.biztalk.windows.net/default/passSB/sources/QueueSource1'. Failed to connect to the Service Bus using specified configuration.

This issue is due to the service using an older version of Microsoft.ServiceBus.dll which does not support Partitioning entities. Partitioning entities is available in 2.2  onwards versions of Microsoft.ServiceBus.dll.

Check the blog for further details: Enabling BizTalk Services to work with Service Bus 2.2 SDK

The resolution mentioned is

1.  You can use a queue created from Service Bus Explorer. As of writing this blog, Queues created this way, do not have entity partitioning enabled by default.

2. Use custom create option while creating queues\topics. In the second page, user should DISABLE partitioning – UNCHECK THE CHECKBOX

Data received from partner organizations is often categorized as business-to-business (B2B) data transfer. One of the standard and most commonly used protocols for B2B and EDI is X12. Microsoft Azure BizTalk Services provides a BizTalk Services Portal that enables you to manage your trading partners and B2B messaging. The Microsoft Azure BizTalk Services Portal enables service providers to add trading partners and configure agreements that can be deployed to Microsoft Azure. The trading partners can then be send X12 messages using HTTP, AS2, FTP/S, and SFTP as transports. Once the message is received, it will be processed by the B2B pipeline deployed on Microsoft Azure and is routed to the destination configured as part of the agreement.

The general flow is like

• Create the Partners and Profiles
• Create Agreements
• Create bridges

Create Partners and Profiles

The Partners page displays the list of partners with their name, email, phone, and description. Using this page, you can add or delete partners and their profiles.

It is important to understand the concept of a Service Provider and a Partner. The Service Provider is you or your company. A Partner is whomever you receive or send EDI files, which can include another company, another department within your company, and so on. Pipelines are deployed for the Hosted Partner when the agreement is deployed. Receive and Send settings are oriented to the context of the Hosted Partner. For example, the receive settings in an agreement determine how the Hosted Partner receives messages sent from a Guest Partner. Likewise, the send settings on the agreement indicate how the Hosted Partner sends messages to the Guest Partner.

Create Agreements

An agreement is defined as a contract between two trading partners for transacting messages over B2B Protocols. An agreement contains the technical details of configuration between two partners for exchanging EDI transactions. The TPA defines the settings for both sending and receiving messages. A TPA involves defining the agreement settings including transport settings and the pipeline definitions (transform and route settings) between the partners.

Since AUG-2014 release, Agreements and Bridges are decoupled. In a few tutorial you may still find old way of configuring agreements where you have to provide information which now is available in the bridge configuration. (e.g. Transport, Route etc.) Those tutorial will get updated. That specific information now will be available in EDI / AS2 bridges – so use bridges while configuring that information.

You can created X12, EDIFACT, AS2 agreements.

Create Bridges

You can create bridges to process EDI / AS2 messages directly from the BizTalk Services Portal. Bridge configuration includes information such as which messaging transport to use, transforms (if required), and where the messages must be routed to. The bridges associate with the EDI / ASW2 agreements at runtime and use the EDI / AS2 protocol-related settings that are defined as part of the agreement. For more information, see How do bridges resolve to agreements at runtime?

Source is from where you want to receive the message (equivalent to Receive Port in BizTalk on premise)

Destination is where you want to send the message (equivalent to Send Port in BizTalk on premise)

Bridge connects Source and Destination and provides various stages to modify, transform, enrich the message (equivalent to Pipeline in the BizTalk on premise)

Sources-Bridges-Destinations

Following type of sources, bridges and destinations are available. Sources and Destinations have typical properties to be set as part of their configuration.
Note that currently only XML type bridge can be used for two way operations.

Configuring Bridges

When you double click on the bridge in design mode, it shows the following respective configuration screen. You can configure those various stages to manipulate the message / properties as per your requirements.

Message Types

A single BizTalk Service project can have multiple bridges and multiple schemas. For ease of use and to save on processing time, you can associate schemas with bridges. In other words, you can require that a specific bridge can only process messages that conform to a specific schema or a set of schemas.

Decode

This stage applies to XML One-Way Bridge only. It does not apply to XML Request-Reply Bridges.

The Decode stage decodes an incoming text message to an XML message and passes it on the Validate stage in the XML One-Way Bridge bridge. Unlike other stages in the bridge, the Decode stage does not have an IsEnabled property. The IsEnabled property for a stage defines whether the stage processes the message passing through the bridge. The Decode stage does not include this property because whether the message is decoded or not depends on the content type of the incoming message. If a bridge receives a message of ‘text/plain’ content type, the decode stage decodes the message and converts it to an XML message. Rest of the processing at each stage within the bridge happens on the XML message and not the flat file message. However, if a message with the any of the other content types is received by the bridge, the decode stage is not activated and the message is simply passed over to the next stage.

Validate

As part of the Validate stage, you can specify whether the stage does any schema validation on the incoming request message and whether the validation warnings can be propagated back to the client as exceptions.

Enrich

As the name suggests, the Enrich stage enables message enrichment by defining properties, the values for which can be derived from the message header (standard or custom), through default properties promoted by BizTalk Services, from an external data source (only Microsoft Azure SQL Database tables supported in this release), or from an element within the message body. These properties can then be used to either route the message to a destination endpoint or for further processing by the message receiving entity.

Transform

As part of the Transform stage, you can specify the transforms to be used by the bridge. You can also specify whether you want to enable or disable the stage.

Encode

This stage applies to XML One-Way Bridge only. It does not apply to XML Request-Reply Bridges.

As part of the Encode stage, you can specify the flat-file schema to use for converting an XML message into a flat-file message. By the time a message reaches the Encode stage, it is already in the XML format. Depending on how the Encode stage is configured, the message is either encoded to a flat-file format or sent out as an XML message.

Reply Action

This stage applies to XML Request-Reply Bridge only. It does not apply to XML One-Way Bridges.

While Reply Action is technically not a ‘stage’ in an XML Request-Reply Bridge, it plays a key role in ensuring that any protocol mismatches between the message sender and message receiver are bridged right before the response message is finally sent back to the message sender. See Reply Action.

Using Custom Code in Bridges

While the fixed pattern of bridges (Validate, Enrich, Transform, and Enrich) provided with BizTalk Services serves the requirements of many integration scenarios, sometimes you need to include custom processing as part of your bridge configuration. For example, you might want to convert a message from a flat-file or an XML format to other popular formats, such as XLS or PDF before sending the message out. Similarly, at each stage of message processing, you might want to archive the message to a central data store. In such cases, the fixed pattern of the out-of-box bridges becomes insufficient. To enable such scenarios, bridges include the option of executing custom code at some key stages of the bridge.

Enterprise Application Integration (EAI)

All XML / Pass-through bridges – which can be used to connect two different types of systems – so it can be message transport protocols, structures, formats. With integration of WCF LOB adapter, you can connect to supported LOB systems on premise. 
Visual Studio is used to develop and deploy such applications.

B2B (EDI / AS2)

Integrating commerce transactions between businesses over industry or vertical-specific standards, such as X12, etc.
BizTalk Services Portal helps you to manage your EDI / AS2 message transactions with trading partners. If you need Transforms or other supporting artefacts, you may use Visual Studio to create a project of type “BizTalk Service Artifact” and deploy it. Then use the relevant references while configuring agreements / bridges.

Read more at About Azure BizTalk Services

Comparing with BizTalk Server on premise

With name “BizTalk” in MABS, it is inevitable that we start comparing MABS and BizTalk Server on premise. Quite obvious – nothing wrong. But when we do that, lets keep in mind that MABS is in its infancy stage - yet to complete 1 year since it went live (GA) - and BizTalk Server on premise is a veteran - 14+ years. MABS also has a different form factor and scale factor. However the biggest advantage for MABS is that all the learning experience of BizTalk Server on premise product creation comes to an aid while developing MABS. So the ramp up for MABS will be very fast. The product group is diligently working  on the new releases with some awesome features. Stay tuned for the announcements.

A very commonly asked question – BizTalk on premise server has no future? Is it dying? Presented this question in front of the product team.
Here is what PMs from the product team are saying - The future of BizTalk looks like an integration solution branded under a single product name which includes seamless integration of BizTalk Server on premise, IAAS (BizTalk Server on Azure VM) and PAAS (MABS) – that's the vision product group is looking forward to– offering a “solution” to the end user’s requirement who does not have to worry about the underlying platform or the implementation details.
So if you have queries like – This is how it is done in BTS why not in MABS? – This is not the same in MABS? – Can we have same feature from MABS to BTS? – etc. - keep them on hold at least for a while.

Not so bad - ah? At least in terms of features? Some apprehension? Oh yes, do I need to mention that - the detailed functionality to make the life more easier will evolve over the time, definitely

BizTalk on premise is recognized for its features like guaranteed message delivery, no message loss and no duplicates for transactional adapters  once BizTalk has received the message and more importantly the pub / sub model.
With the architecture of MABS, there is no Message Box like store (and logic) available. So when you configure bridges, the destination needs to be known beforehand.
Also, you can route the message only to a single destination. (Though you can connect multiple destinations to a single bridge and make on the fly choice of the destination based on the message properties / connector precedence.)
As MABS does not store the received messages, if the message delivery fails (for what-so-ever issues at the destination end point or issues in between stages), an error is returned back to the source client  as well as tracked in Tracking database and WADLogsTable. If the source was a store like FTP then the message will sit in that store only. In such cases, manual intervention may be required - like to stop the bridge, to troubleshoot and resolve the issue (assuming it is not just end point down situation). If the source was some external service / application, then the posting client has to handle this error and put a retry logic or alert mechanism as appropriate. The client may have to inform to the MABS owner / administrator if issue continues to happen. It is better to implement some kind of alerting mechanism (which is not present today out of the box) based on the error coming up in the tracking database / store.

I hope that the product team implements the much needed crucial functionality and we see more matured product down the line – at the earliest. Till then, you may overcome some of the shortcomings by taking care while designing your MABS solution – e.g. whenever you receive a message, first send it to blob store as the first destination and then chain it forward for real processing. This was just an example –there are architects who have devised very nice and practical business solutions (which are in production) with bright and innovative ideas. A new branch for MABS solution architecture patterns is developing.

So, if you have already used the BizTalk Server on premise, then I suppose you got a fair idea about what MABS can / cannot do. For readers, who have never used the BizTalk on premise, hope that the following blogs - EAI and B2B (EDI / AS2) - will help you to get some better picture.
[I will update the links once I publish the detailed blogs for those]

This is easy to use yet very powerful tool (VS Server Explorer Plug-in) especially for the developers. If you don't have it installed yet, right now download it from here or follow this TechNet Wiki "Azure BizTalk Service Explorer" to add it from Visual Studio Gallery within VS.

Though this tool has lot of other useful features (which we will explore in other respective topics) here we are looking at how to post the message.
For that, from this TechNet Wiki "Azure BizTalk Service Explorer", see the section “Test and Debug bridges”

2. Message Sender

This tool came as a part of Windows Azure BizTalk Services SDK Samples - Windows Azure BizTalk Services EAI Sample Tools - Message Sender.
This is stand-alone executable – after downloading the sample you can compile the project and use the following command line syntax to push messages.

MessageSender.exe <ACSNamespace> <IssuerName> <Issuerkey> <RuntimeAddress> <MessageFilepath> <ContentType>

Note that there are no “-“ for the parameters. The exe recognizes parameters based on the position. For MessageFilePath, if sample message is in the same folder as the exe, then you can simply provide the file name – otherwise provide the entire file path. If file path contains spaces, put quotes around it.

The first three parameters you can get from the Azure Management Portal by selecting your BizTalk Service and then clicking on “Connection Information”.
All the parameters are explained on the tool’s download page.

You can extend this tool and develop your own applications as per the business requirements to work with the MABS.

3. Using on premise BizTalk Server

I agree, this is not the “most common” tool, but still there are a lot of users who work simultaneously on the BizTalk Server. Following information will help to test as well as integrate the on premise BizTalk Server with MABS.

Open BizTalk Admin Console and under the “Send Ports” section create a new WCF-WebHttp Send Port.

Click on Configure. On General tab, provide the bridge URI.

On the Security tab, check the check box “Use ACS service identity” and click on Edit and then provide ACS information.

Click on “OK”s to complete the send port configuration. Now either use content based routing or orchestration to send the message using this send port.

Note:

If you get error like
System.IdentityModel.Tokens.SecurityTokenException: The token provider was unable to provide a security token while accessing 'https://servicename3900-bts.accesscontrol.windows.net/WRAPv0.9/'. Token provider returned message: 'Error:Code:401:SubCode:T0:Detail:ACS50009: SWT token is invalid.:TraceID:b6a7b26c-b490-46a4-91c9-0764f98dd860:TimeStamp:2014-10-17 05:24:12Z'. ---> System.Net.WebException: The remote server returned an error: (401) Unauthorized. at System.Net.HttpWebRequest.GetResponse() at Microsoft.BizTalk.Adapter.Wcf.Config.SharedSecretTokenHelper.GetAccessTokenCore(Uri requestUri, String appliesTo, String requestToken, String simpleAuthAssertionFormat, TimeSpan timeout) --- End of inner exception stack trace ---

and you are sure that the ACS credentials are correct, then try using Symmetric Key instead of the password in the “Issuer Key” Field.
For this, go to the main Azure Management Portal and go to the ACTIVE DIRECTORY – ACCESS CONTROL NAMESPACES and then select respective ACS Namespace.- click on Manage.
On the left side select Service Settings – Service identities. Then select the identity – owner – Symmetric Key

Considerations for the EDI / AS2 Bridges

You may use above methods to send messages to EDI / AS2 bridges as well. However, post Aug 2014 release, Agreements and bridges are decoupled. If you have not redeployed the agreement after the Aug 2014 release, then still old EDI / AS2 bridges will work as they were working before. With the new agreements (or if you have redeployed the agreement), when sending the message to EDI / AS2 bridge, the agreement resolution happens based on Agreement ID / Combination of agreement name and partners / The identities in the agreement / AS2-To and AS2-From values. For more information see the article How do bridges resolve to agreements at runtime?

For Message Sender

You can modify the below code to add appropriate HTTP headers as per your requirements.

private static string SendMessageToBridge(string address, byte[] messageBytes, string token, string contentType)
       {
           string response;
           WebClient webClient = new WebClient();
           webClient.Headers[HttpRequestHeader.Authorization] = "WRAP access_token=\"" + HttpUtility.UrlDecode(token) + "\"";
           webClient.Headers["Content-Type"] = contentType;
           byte[] uploadData = webClient.UploadData(address, "POST", messageBytes);
           LogTrackingId(webClient.ResponseHeaders);
           response = Encoding.UTF8.GetString(uploadData);
           return response;
       }

For on premise BizTalk Server Send Port

For the previous send port, click on configure and go the Message Tab. Here add appropriate HTTP headers as per your requirements.

Note:

The “colon” + “space” is the separator for “Header Name” and “Header Value”. If you need multiple headers, make sure to have carriage return after at the end of the previous header value – as shown here.

EDI Receive and Send bridge

The names Receive and Send are w.r.t. MABS. So when you want to post the message on EDI Receive Bridge, make sure that you are posting EDI message – that is text message. The EDI Receive Bridge will disassemble it to XML message and send it to the destination.
Similarly, when you are posting the message on EDI Send Bridge, make sure you are posting XML message. The EDI Send Bridge will assemble it to EDI message and send it to the destination.

Make sure to put proper Content Type

If proper content type is not provided, the messages delivery can fail. Here are a few forum posts that will help to make a choice of the correct Content Type based on the method that you use to post the message.

• text/plain in Pass-Through Bridge using SB Source
• Filter condition on message content type
• PassthroughBridge does not pass any messages through