wiki

Codit Wiki

Loading information... Please wait.

Codit Blog

Posted on Monday, September 11, 2017 3:13 PM

Pim Simons by Pim Simons

With the introduction of BizTalk 2016 it is now possible to use SHA-2 certificates when signing a message. As this is not as straightforward as I expected it to be, I’ve decided to share my experiences with setting up SHA-2 in this blogpost.

For one of our customers we migrated all their interfaces from BizTalk 2006 R2 to BizTalk 2016. During testing of the new BizTalk 2016 environment we found that the signature for the AS2 messages being sent out was not working correctly. While there was no exception in BizTalk, the external party, that was receiving the messages, was unable to verify the signature of the messages. The messages from the old BizTalk 2006 R2 environment were all verified and processed successfully. Obviously we started checking if all of the certificates and party settings were setup correctly in the new BizTalk 2016 environment. We found those to be correct and continued to search for the cause of this issue.

We ended up finding a difference when comparing the signing algorithms. The old BizTalk 2016 R2 environment was using SHA1 while the new BizTalk 2016 machine was using SHA256. Having found this clue, we figured that the fix would be easy: just change the signing algorithm on the AS2 agreement. However, this is where we ran into some problems. It turns out there really isn’t anywhere to configure this on the AS2 agreement. As shown in the picture below, it is possible to specify that the message should be signed, but it is not possible to specify a signing algorithm.

 
The documentation does not specify where to supply the signing algorithm. But after walking through all of the settings of the AS2 agreement again, I noticed that the signing algorithm for the MDN was set to SHA256 and not SHA1. While it is greyed out and, at least according to the screen, only used for MDN’s, we decided to change it anyway and see if this could be the issue.


 
I enabled ‘Request MDN’ and ‘Request signed MDN’ after which I could change the signing algorithm to SHA1. Finally, I disabled ‘Request MDN’ and ‘Request signed MDN’ again since we are not using the MDN.


This finally solved our issue with the signing of the message as now the SHA1 algorithm was used to sign the message!

In conclusion, it is possible to specify the signing algorithm for outgoing messages, but it is not where you would expect it to be. If you interpret the screens of the AS2 party agreement you would think that the signing algorithm can only be specified for MDN’s as it is greyed out by default.

Hopefully the choice of signing algorithm will be easier after a bugfix or in the next release of BizTalk.  

I enabled ‘Request MDN’ and ‘Request signed MDN’ after which I could change the signing algorithm to SHA1. Finally, I disabled ‘Request MDN’ and ‘Request signed MDN’ again since we are not using the MDN.

Categories: BizTalk
written by: Pim Simons

Posted on Wednesday, June 26, 2013 4:08 PM

Glenn Colpaert by Glenn Colpaert

This blogpost will help you resolve following error when configuring EDI/AS2 reporting: "An existing Status Reporting's BAM activity (ResendJournalActivity) is found in the database BAMPrimaryImport".

At one of our customers we had the request to enable EDI/AS2 runtime status reporting on an existing environment.

You can enable this status reporting by running the “BizTalk Configuration Wizard” and enabling it on the “BizTalk EDI/AS2 Runtime” tab.

During this modification of the BizTalk configuration we quickly ran into following issue:

“An existing Status Reporting's BAM activity (ResendJournalActivity) is found in the database BAMPrimaryImport on ‘xxxxx’ . You will need to use bm.exe to remove this activity from the BAM database before proceeding. (Microsoft.BizTalk.Configuration.EDIAS2.EDIAS2Config) “

image

image 

Cause

This issue is caused when EDI Reporting was configured and then unconfigured. When EDI/AS2 reporting is unconfigured, it does not remove the BAM activities that are left in the BAM database. The BAM activities may have data that you need and therefore the unconfiguration wizard does not remove them.

The Solution

There are different steps to get this issue resolved:

  • Remove the BAM activities (ResendJournalActivity and ResendTrackingActivity) from the BAMPrimaryImport database by using bm.exe
    • bm.exe remove-activity –Name:ResendJournalActivity
    • bm.exe remove-activity –Name:ResendTrackingActivity

image

  • Uninstall and Unconfigure following features
    • BAM Tools
    • EDI Runtime (if applicable)
    • AS2 Runtime (if applicable)
  • Reinstall following features
    • BAM Tools
    • EDI Runtime (if applicable)
    • AS2 Runtime (if applicable)

 

It’s important to exactly follow the steps as described above. After you have executed the bm.exe step, it’s possible to continue with the installation of the “EDI/AS2 runtime status reporting” without doing the uninstall/unconfiguration of the BAM Tools and EDI/AS2 runtime.

But eventually you’ll run into issues when opening the “BizTalk Administration Console” and querying for AS2/MDN statuses.

 

Cheers,

Colpaert Glenn

Categories: BizTalk
written by: Glenn Colpaert

Posted on Tuesday, November 10, 2009 10:47 AM

Pieter Vandenheede by Pieter Vandenheede

EDI interchange batching is the process of creating an EDI file or interchange which contains multiple EDI transaction sets. Creating this interchange is called “EDI batching”. This blog post handles a custom way on how to batch EDIFACT messages.

Introduction

EDI Batching can be done out of the box in BizTalk 2009: There is the built-in batching orchestrations within BizTalk 2009 which can be started within the application “BizTalk EDI Application” and managed within the configuration of your party. More information about how this method works, together with a walkthrough, can be found here.

Note that the link will give you a step by step guideline for BizTalk 2006 R2, but should work for BizTalk 2009 as well. The only difference, as far as I can see, seems to be that the batching configuration within BizTalk 2006 R2 is separated between X12 and EDIFACT and for BizTalk 2009, you can configure it within the same dialog box (Parties > EDI Properties).

Screenshot:

Image: EDI Batching settings dialog in BizTalk 2009

Pros & Cons

For most companies the built-in batching solution within the party configuration will be sufficient: You can let the batch subscribe to your messages and your EDI messages will be batched one by one and will be released depending on the release criteria that you have set.

As you can see from the screenshot, these criteria can be scheduled (in a timely manner), based on the number of group segments or transactions sets within the interchange or by an external release trigger.

One important thing that I found while testing this method is that the batching orchestrations will only accept EDI messages which are considered to be “complete”. Otherwise you would get an error from the batching orchestration “71: Transaction Set or Group Control Number Mismatch”.
This is because the orchestration logic tries to assemble your EDI message, but cannot find the UNH and UNT segments within the message instance.
If you have just created the EDI message instance from a map for example, this is not filled in by default. You would first need to execute the EdiSend pipeline on your message to do this.

This built-in batching method should be quite easy to use if your release mechanism requirement is one of the available release criteria. However, I don’t see how you would easily determine the order of your messages in your outgoing interchange.

It also becomes complex when you need to be able to build parallel batches, initialized by different source messages.  

An alternative batching method

And off course, this is where this alternative batching method comes in…
First, I wish to thank my colleague Carl Batisse for providing me a glimpse to this solution: thank you Carl!

This alternative method is using a batch schema that is mainly used for validating instances of interchanges. However, it can also be used to reverse the process and thus create interchanges from the Xml you created.

The EDIFACT batch schema can be found in the BizTalk 2009 folder in the location:
<BizTalk_Installation>\XSD_Schema\EDI\Edifact_BatchSchema.xsd”
For X12, one would use the “X12_BatchSchema.xsd” file.

In my example, I will only use the EDIFACT schema, which looks like this:


Image: Edifact_BatchSchema.xsd

To validate an interchange against this batch schema, add it to your project together with the EDIFACT schemas that it will contain. If you run the “Validate Instance” on the batch schema, each EDI schema included in your project will be tested against your instance.

If you want to generate an instance of the schema, the batch schema will contain 3 transaction sets of all of the EDI schemas in your project, which is handy!

The result of the generated instance clearly shows you how the schema works. In my example I have added the the EDIFACT schemas for DESADV and IFCSUM and the batch schema to my project:

 Image: Edifact_BatchSchema.xsd generated instance for DESADV and IFCSUM

You can clearly see the UNA, UNB and UNZ records and in between those, you can see that there is one “TransactionSetGroup” and “TransactionSet” record for each transaction set in the interchange. The DocType attribute defines the type of EDI message that is contained within the transaction set.

The attribute at root level “DelimiterSetSerializedData” contains the decimal representation of the characters used for delimiting, just as the UNA segment. The UNA segment can also be filled in with the actual characters instead of the decimal representation, but the notations cannot be mixed.

This means that you can simply map to this batch schema (with XSLT for example, which will be handier in this case). If you, for example, need to have multiple IFCSUM transaction sets within your interchange, you can provide a “xsl:for-each” loop containing the transaction set details.

After the mapping, you would simply let loose the EDI assembler on your instance and the EDI would be created… or not?

Now here comes the tricky part about the use of this schema… it will not allow you to continue without presetting the UNB and UNZ (on interchange level) and UNH and UNT (on transaction set level) segments. The EdiSend pipeline for example will not do this for you. Instead, in this case, it would provide you with a nice error message again.

So BizTalk will not handle the interchange control number and transaction set control numbers for you and this is a bit of a downside to this solution. This means that you would need to store the last used interchange and transaction set control numbers somewhere. This could be a database for example.

Specific nodes to fill in (EDIFACT)

At interchange level:

UNA, UNB1 (syntax version), UNB2 (sender identifiers), UNB3 (receiver identifiers), UNB4 (interchange date and time, depending on UNB1 version), UNB5 (interchange control number), UNZ1 (number of messages in the interchange) and UNZ2 (copy of UNB5).

At transaction set level:

UNH1 (transaction set control number), UNH2 (transaction set type and version), UNT1 (transaction set segment counter), UNT2 (copy of UNH1).

The transaction set segment counter can be a little tricky, because you would need to count the segments in your XSLT. The EDI assembler will however correct this value if it happens to be filled in incorrectly. It will however show you a warning in the event log, which can be ignored.

Pieter Vandenheede, CODit