Adapter Framework Configuration Schema Decoration Tags

by community-syndication | Feb 27, 2008 | BizTalk Community Blogs via Syndication

This msdn article is tempting, but the following page does not explain how to use the decoration tags. I have created a sample that uses a resx file, but also show how to use decoration tags (there are three groups BAM, Polling, and Server, coupled with a password entry)

<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns:baf="BiztalkAdapterFramework.xsd" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" xmlns="http://tempuri.org/XMLSchema.xsd" elementFormDefault="qualified" targetNamespace="http://tempuri.org/XMLSchema.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:import namespace="BiztalkAdapterFramework.xsd" />
  <xs:element name="Config">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="BAMServer" type="xs:string">
          <xs:annotation>
            <xs:appinfo>
              <baf:designer xmlns:baf="BiztalkAdapterFramework.xsd">
                <baf:displayname _locID="BAMServerName">Edit this field in the resource file</baf:displayname>
                <baf:description _locID="BAMServerDesc">Edit this field in the resource file</baf:description>
                <baf:category _locID="BAMGroup">Edit this field in the resource file</baf:category> <!-- Here is the Group Identifier -->
              </baf:designer>
            </xs:appinfo>
          </xs:annotation>
        </xs:element>
        <xs:element name="BAMDatabase" type="xs:string">
          <xs:annotation>
            <xs:appinfo>
              <baf:designer xmlns:baf="BiztalkAdapterFramework.xsd">
                <baf:displayname _locID="BAMDatabaseName">Edit this field in the resource file</baf:displayname>
                <baf:description _locID="BAMDatabaseDesc">Edit this field in the resource file</baf:description>
                <baf:category _locID="BAMGroup">Edit this field in the resource file</baf:category> <!-- Here is the same Group Identifier -->
              </baf:designer>
            </xs:appinfo>
          </xs:annotation>
        </xs:element>
        <xs:element minOccurs="1" default="10" name="pollingInterval" type="xs:int">
          <xs:annotation>
            <xs:appinfo>
              <baf:designer xmlns:baf="BiztalkAdapterFramework.xsd">
                <baf:displayname _locID="pollingIntervalName">Polling Interval</baf:displayname>
                <baf:description _locID="pollingIntervalDesc">The elapsed time between transactions against the database.</baf:description>
                <baf:category _locID="categoryGroup">Edit this field in the resource file</baf:category> <!-- Here is the second Group Identifier -->
              </baf:designer>
            </xs:appinfo>
          </xs:annotation>
        </xs:element>
        <xs:element minOccurs="1" default="minutes" name="pollingIntervalUnit">
          <xs:annotation>
            <xs:appinfo>
              <baf:designer xmlns:baf="BiztalkAdapterFramework.xsd">
                <baf:displayname _locID="pollingIntervalUnitName">Polling Interval Unit</baf:displayname>
                <baf:description _locID="pollingIntervalUnitDesc">The unit of time measure for the Polling Interval.</baf:description>
                <baf:category _locID="categoryGroup">Edit this field in the resource file</baf:category> <!-- Here is the second Group Identifier -->
              </baf:designer>
            </xs:appinfo>
          </xs:annotation>
          <xs:simpleType>
            <xs:restriction base="xs:string"> <!--  Here is a drop down list of the available options for pollingIntervalUnit -->
              <xs:enumeration value="milliseconds">
                <xs:annotation>
                  <xs:appinfo>
                    <baf:designer xmlns:baf="BiztalkAdapterFramework.xsd">
                      <baf:displayname _locID="">Milliseconds</baf:displayname>
                    </baf:designer>
                  </xs:appinfo>
                </xs:annotation>
              </xs:enumeration>
              <xs:enumeration value="seconds">
                <xs:annotation>
                  <xs:appinfo>
                    <baf:designer xmlns:baf="BiztalkAdapterFramework.xsd">
                      <baf:displayname _locID="">Seconds</baf:displayname>
                    </baf:designer>
                  </xs:appinfo>
                </xs:annotation>
              </xs:enumeration>
              <xs:enumeration value="minutes">
                <xs:annotation>
                  <xs:appinfo>
                    <baf:designer xmlns:baf="BiztalkAdapterFramework.xsd">
                      <baf:displayname _locID="">Minutes</baf:displayname>
                    </baf:designer>
                  </xs:appinfo>
                </xs:annotation>
              </xs:enumeration>
            </xs:restriction>
          </xs:simpleType>
        </xs:element>
        <xs:element name="Server" type="xs:string">
          <xs:annotation>
            <xs:appinfo>
              <baf:designer xmlns:baf="BiztalkAdapterFramework.xsd">
                <baf:displayname _locID="ServerName">Edit this field in the resource file</baf:displayname>
                <baf:description _locID="ServerDesc">Edit this field in the resource file</baf:description>
                <baf:category _locID="ftpGroup">Edit this field in the resource file</baf:category>
              </baf:designer>
            </xs:appinfo>
          </xs:annotation>
        </xs:element>
        <xs:element name="UserName" type="xs:string">
          <xs:annotation>
            <xs:appinfo>
              <baf:designer xmlns:baf="BiztalkAdapterFramework.xsd">
                <baf:displayname _locID="UserNameName">Edit this field in the resource file</baf:displayname>
                <baf:description _locID="UserNameDesc">Edit this field in the resource file</baf:description>
                <baf:category _locID="ftpGroup">Edit this field in the resource file</baf:category>
              </baf:designer>
            </xs:appinfo>
          </xs:annotation>
        </xs:element>
        <xs:element name="Password" type="xs:string">
          <xs:annotation>
            <xs:appinfo>
              <baf:designer xmlns:baf="BiztalkAdapterFramework.xsd">
                <baf:displayname _locID="PasswordName">Edit this field in the resource file</baf:displayname>
                <baf:description _locID="PasswordDesc">Edit this field in the resource file</baf:description>
                <baf:category _locID="ftpGroup">Edit this field in the resource file</baf:category>
                 <!-- Here is the start of the code to mask the passowrd -->
                <baf:editor assembly="%BTSROOT%\\Developer Tools\\Microsoft.BizTalk.Adapter.Framework.dll">Microsoft.BizTalk.Adapter.Framework.ComponentModel.PasswordUITypeEditor</baf:editor>
                <baf:converter assembly="%BTSROOT%\\Developer Tools\\Microsoft.BizTalk.Adapter.Framework.dll">Microsoft.BizTalk.Adapter.Framework.ComponentModel.PasswordTypeConverter</baf:converter>
              </baf:designer>
            </xs:appinfo>
          </xs:annotation>
        </xs:element>
        <xs:element name="Folder" type="xs:string">
          <xs:annotation>
            <xs:appinfo>
              <baf:designer xmlns:baf="BiztalkAdapterFramework.xsd">
                <baf:displayname _locID="FolderName">Edit this field in the resource file</baf:displayname>
                <baf:description _locID="FolderDesc">Edit this field in the resource file</baf:description>
                <baf:category _locID="ftpGroup">Edit this field in the resource file</baf:category>
              </baf:designer>
            </xs:appinfo>
          </xs:annotation>
        </xs:element>
        <xs:element name="Mask" type="xs:string">
          <xs:annotation>
            <xs:appinfo>
              <baf:designer xmlns:baf="BiztalkAdapterFramework.xsd">
                <baf:displayname _locID="MaskName">Edit this field in the resource file</baf:displayname>
                <baf:description _locID="MaskDesc">Edit this field in the resource file</baf:description>
                <baf:category _locID="ftpGroup">Edit this field in the resource file</baf:category>
              </baf:designer>
            </xs:appinfo>
          </xs:annotation>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

SOA and BPM Conference 2007 Recordings on TechNet Spotlight

by community-syndication | Feb 26, 2008 | BizTalk Community Blogs via Syndication

A set of video recordings of sessions from the SOA & BP conference are posted on the Spotlight! sight. This is a fantastic channel for IT Pros to get access to key content from MS events worldwide. Please see the list of sessions below including the event keynote.

Subversion & BizTalk: Setting Committer Auto-Properties

by community-syndication | Feb 26, 2008 | BizTalk Community Blogs via Syndication

In my last post, I discussed how to configure the version control system, Subversion, to correctly handle BizTalk files. Although I did talk about how to set the correct file-type properties and how to mass update files already in the repository, I neglected to detail how to set those properties when files are first added […]

Announcing CharlesJobz – My new free recruitment agency!

by community-syndication | Feb 26, 2008 | BizTalk Community Blogs via Syndication

Jurgen Willis, who is Group Program manager of Microsoft’s Connected Framework Team over in Seattle, has been in touch, and I offered to forward his request on via this blog site. Microsoft is currently looking for people to work in their rules area (WF Rules, etc). They are specifically looking for a Program Manager and a Development Lead

• Community PM
• Activities PM
• Runtime PM

Understanding the BizTalk Mapper: Part 12 – Performance and Maintainability

by community-syndication | Feb 26, 2008 | BizTalk Community Blogs via Syndication

In this section:
Performance

   Summary of Tests

   Testing performance in isolation
(non-BizTalk)

   Performance Test Results

   Measuring Memory Usage in BizTalk

   BizTalk Memory Test Results

   Byte Arrays

   Analysing the performance results

Maintainability

   External XSLT

   Serializable Classes

   Why is it so difficult
to edit code in the Script functoid?

   Documentation



Any large BizTalk project will likely have had the inevitable conversations about
performance and maintainability: will it be fast/sustainable enough, and will the
tech support team (or whoever looks after the code once the developers have finished)
be able to maintain it?

In this post I want to look at the performance of the Mapper, and also look at how
maintainable maps are generally.

In order to do this, I want look at the different options you have for executing XSLT
with the Mapper, and compare this to the most common non-Mapper mechanism for performing
transformation: using serializable classes.

In BizTalk, your options for transformations using the Mapper are:

• Built-in functoids
• Inline XSLT script
• Inline C# / VB.NET / JScript.NET
• Classes/methods in external assemblies
• Custom functoids
• External XSLT file

Normally you’d use a combination of these in a complex BizTalk solution.

So how do you decide which to use?
Which gives you the best performance?
Which option(s) are the easiest to maintain?

The answer is: it depends!

In this section I’m going to try and give you some hard data you can use to try and
answer these questions. In the next post, I’ll try and answer the questions.

Performance

Performance is a very subjective subject. You could spend weeks getting your maps
to execute in under 10ms, but if your performance requirement is "anything less
than 100ms" then why bother?

What’s more important is that performance is "good enough" and is sustainable.

Sustainable performance is the key – its one thing to be able to perform a single
transformation in less than 10ms, but what about performing 40 simultaneous transformations
continuously for over an hour?
And what about the memory footprint?

When we talk about performance, we also need to look at memory/resource usage: If
you have a very fast system that for each transformation uses 1MB memory, then at
a certain point under sustained load your memory usage will start to affect performance
as memory is paged out to disk (assuming that garbage collection can’t keep up with
the number of transformations you’re performing).

In order to find out the performance and memory footprints of the various options,
I put together some tests.

I ran two suites of tests:

• Using a stand-alone test harness with the XslTransform class
  to perform transformation in isolation (this gives the comparative performance)
• Using a BizTalk application to measure memory usage (this gives the comparative memory
  usage)

Summary of Tests

I simplified the six options above into four separate XSLT tests, and then added two
tests involving serializable classes for comparison:

1. Standard Map
   
   A map using default built-in functoids, with a mix of functoids that emit XSLT and
   functoids that emit C#
2. Map using external XSLT
   
   A map which used an external XSLT file consisting of pure XSLT i.e. no external assemblies
   or inline script
3. Map using inline C#
   
   A map using inline C# code in a Script functoid
4. Map using external assembly
   
   A map using an external assembly via a Script functoid
5. Transformation using Classes
   
   De-serializing the input message into a class, transforming to a new class, and serializing
   the class back into the output message
6. Transformation using classes and serializers
   
   Same as 5. above but using the sgen.exe tool
   to pre-generate a Serialization class

My test scenario was: Transforming a message containing 20 employee records into a
new message which contained separate Manager and Staff records:
i.e. this:


becomes this:

Each of the maps performed the transformation in the same way, as much as was possible.

Testing performance in isolation (non-BizTalk)

For the XSLT tests, I tested using both the XslTransform class
(used by BizTalk) and the newer XslCompiledTransform class
(for comparison).

For both of these class tests I used static and non-static instances of the classes:

• In the static test a transform class was created once and then re-used for each iteration
• In the non-static test a new transform class was created for each iteration

I ran each test twice: once with 20 iterations, and once with 500 iterations.

I also measured the amount of memory in use before and after each test – from this
I calculated a rough "memory used" for each test (this is before garbage
collection kicked in).

For each test I show:

1. Total
   
   This is the total time (in ms) that the test took to run
2. Average
   
   This is the average time for each iteration
3. Average without first
   
   This is the average time without the first iteration
4. Average setup
   
   This is the average time it took to create the transform object in each iteration
   (will be 0 for the static tests as creation of transform is performed once and not
   included in the timings)
5. Average transform
   
   This is the average time it took to perform the transformation
6. Memory Used
   
   This is the amount of memory used to perform the entire test

Performance Test Results

The results of the 500 iteration tests are:

(the lowest result on each row is highlighted in green)

And for comparison, the results from the 20 iteration tests:

(the lowest result on each row is highlighted in green)

Measuring Memory Usage in BizTalk

Although the Memory Used amount from the performance tests was useful, I wanted
to know exactly how much memory BizTalk used for performing transformations – and
what objects were in memory.
In order to measure this I used SciTech Software’s .NET
Memory Profiler.
This tool attaches to the BizTalk service (BTSNTSvc.exe) and can create a snapshot
of all the object instances currently in use, including how many there are and how
much memory they’re using.

I created a BizTalk application which contained a separate map for each of the tests
above, and created orchestrations to execute the maps (and to call the C# code to
perform the transform using the classes).

I performed a memory snapshot before and after running the orchestrations, and restarted
the BizTalk service between each test.

I ran each test twice: once with a single message, and once with 50 messages.

For each test I show:

1. Byte[] Instances
   
   This is the count of Byte arrays in use (the relevance of Byte arrays is explained
   below)
2. Byte[] Instances Size (MB)
   
   The is the total size of all Byte arrays (i.e. the size of all the data they contain)
3. Total Instances
   
   The is the count of all .NET objects in use
4. Total Instances Size(MB)
   
   This is the total size of all .NET objects in use

Note that any sizes measured are after garbage collection has occurred i.e.
these are objects which are still classed as being in-use.

BizTalk Memory Test Results

The results I measured were:
Single Message:

(the lowest result in each column is highlighted in green)

50 Messages:

(the lowest result in each column is highlighted in green)

Byte Arrays

I can let Microsoft explain this in their own words (this is taken from a knowledge
base article here):

The System.Policy.Security.Evidence object is often used
in transforms and can consume a lot of memory. Whenever a map contains a scripting
functoid that uses inline C# (or any other inline language), the assembly is created
in memory. The System.Policy.Security.Evidence object uses the object of the actual
calling assembly. This situation creates a rooted object that is not deleted until
the BizTalk service is restarted.

 

Most of the default BizTalk functoids are implemented
as inline script. These items can cause System.Byte[] objects to collect in memory.
To minimize memory consumption, we recommend that you put any map that uses these
functoids into a small assembly. Then, reference that assembly. Use the chart below
to determine which functoids use inline script and which functoids do not use inline
script.

In the second column, “Yes” means that this functoid is
implemented as inline script, and that it will cause System.Byte[] objects to collect
in memory. “No” means that this functoid is not implemented as inline script, and
that it will not cause System.Byte[] objects to collect in memory.

Assemblies created by compiling inline script in an XSLT are temporary assemblies
and are loaded into the appropriate AppDomain – they will remain in memory until the
AppDomain is unloaded i.e. the BizTalk Host Instance is restarted.

So if you keep all your maps, orchestrations, schemas, etc in one big assembly, then
that assembly will stay loaded in memory until the BizTalk Host Instance that loaded
it is restarted.
Solution? Keep your maps (especially maps using inline C#) in a separate project/assembly
– and try and keep that assembly as small as possible!

Analysing the performance results

The results shouldn’t really come as any surprise.
What they say in a nutshell is: pure XSLT is much faster than XSLT which uses inline
script or referenced assemblies. How much faster? Well, my tests show an average 5500%
speed increase over using the default functoids (i.e. 55 times faster)!
Additionally, using pure XSLT uses 1/8 the memory.
Of course, your mileage will vary.

What’s interesting though is how fast using serializable classes is i.e. de-serializing
a message into a class, performing operations to create a new class, and then serializing
the new class into a message.
When used with a pre-generated serialization assembly, this mechanism chases closely
behind using pure XSLT (and actually beat it in one of the tests).

Maintainability

One of BizTalk’s trump cards is the BizTalk Mapper: you can create maps which can
be easily maintained – what’s more, because the Mapper is a visual tool you can see
at a glance how the mapping works.
At least, that’s the theory.
If you have a relatively simple map which uses no script functoids, and has less then,
say, 50 connections then Yes, I’d say this was true: it’s easy to see what the map
does, and probably easy to maintain it.

But if you have a map with 1000 connections, or with a whole smattering of Script
functoids (or a bird’s nest of Logical functoids) then No, I don’t think it’s easy
to see what the map does or to maintain it.

At what point do you have to admit defeat with a Map and say that it’s got as bit
too complex? or that the next developer to come along will have problems maintaining
it?
In that case, would you be better off using external XSLT or serializable classes?

External XSLT

One of the main complaints I hear about using external XSLT with the Mapper is that
it’s difficult to maintain. This can be true – if your editing tool is notepad! But
there are great tools around for maintaining XSLT – have a look at Altova’s
MapForce for an example of one.
The other complaint is that XSLT is difficult, or hard to learn. Well, so is C# if
you’ve never used it before.
Go buy a book on it, or do a course!

Truth be told, if you work for a company which uses XSLT for other projects, then
you’re more likely to find support for using it as external XSLT in BizTalk.
Some companies have teams in IT which do nothing but create XSLT.

My point here is that although there’s a myth that external XSLT is hard to maintain,
it’s a lot easier to maintain than a complicated map. And if you use the right tool,
you can get a graphical view of what it does as well.

Serializable Classes

In my experience, it’s very very common for developers to create a whole slew of transform
and utility classes for handling transformations.
Sometimes this is because it’s the best way to do it.
Other times it’s because they simply didn’t know how to achieve something in the Mapper.
One of the best features of BizTalk (the ability to call out to C# classes/methods
from an orchestration or map) can also be its worst: Just because you *can* create
C# code, doesn’t mean that you *should*.

Maintaining poorly written C# code is a nightmare.
So if you’re using serializable classes to perform transformations make sure they’re
well written and well documented – but most importantly: understand *why* you’re using
them over XSLT.

Why is it so difficult to edit code
in the Script functoid?

Ever wondered why you can’t resize the Script functoid code window? Or do a Ctrl-A
to select all the code in it? It turns out there is actually a reason for it…

Scott Woodgate (former Product Manager for BizTalk) had
this to say…
The article is correct when it points out we discourage the use of .NET objects
directly inside the map. While this is possible, we encourage good developer design
which is encapsulating code in external assemblies. This turns out to be much better
because you have a single assembly with code shared across multiple maps that can
be versioned once and managed more easily

Unfortunately, this restriction also means that it’s difficult to use inline XSLT,
which is a shame.

Documentation

You can’t get away from the fact that code that is easy to maintain is either self-documenting,
or is accompanied by excellent documentation.
Regardless if you use maps, external XSLT, or serializable classes you should really
document your transforms: explain what they do, how they do it, why they do it – and
most importantly, give some context: explain why you chose to do it that particular
way.
A developer who has to maintain your code in 2 years time might not have your background
of development and political issues to understand why you made your choices.

The next post is going to look at the performance/maintainability of the different
transformation options and attempt to help you to decide when to use which option.

Switching a Published WCF Service between WSHttp and BasicHttp

by community-syndication | Feb 26, 2008 | BizTalk Community Blogs via Syndication

When using the BizTalk WCF Service Publishing Wizard to create WCF services a number of files and directories are created in the stipulated virtual directory folder.  The directory structure created is shown below, with a brief statement as to what is in each directory:

• Root Directory: contains the .svc files for each service that has been published, and the web.config file. 




• The App_Data directory contains the schemas for those services that have been published.




• The Temp sub-directory contains the binding file for the services and the WcfServiceDescription.xml file, which contains the various properties entered into the WCF Publishing Wizard.

At a customer recently there was a requirement to take these published services and change them from using the WCF-WSHttp adapter to using the WCF-BasicHttp adapter.  One option was to republish the WCF services, but this was quickly discarded as there were a large number of services.  As BizTalk does not include a command line version of the WCF Publishing Wizard in the installation the customer was in the process of developing their own WCF publishing service, using the WcfServiceDescription.xml file located in the Temp directory.  After pointing out to them the availability of an existing command line utility, as docmented at http://technet.microsoft.com/en-us/library/bb245933.aspx, they decided to use this instead.  Using the command line tool, and by setting the “AdapterName” argument to “WCF-BasicHttp”, they were able to very quickly then republish their endpoints and change all their receive locations to use the WCF-BasicHttp adapter.

There are a few things to be aware of when using this command-line utility, however:

1. The first argument for the utility is “PathName”, which is required to be the “Path and file name of the BizTalk assembly (*.dll) or the WCF service description (*.xml) file”.  If you are using the utility to publish an orchestration then the path to the BizTalk assembly can be used, but if you are publishing schemas using the path to the BizTalk assembly will result in the utility completing successfully, but there will be no .svc files in the root of the directory, and there will be no schema files in the App_Data directory.  When publishing a schema as a WCF end-point you will need to use the path to the WCF service description file, which is the WcfServiceDescription.xml file found in the Temp directory of a published WCF end-point.


2. As the utility overwrites the contents of the virtual directory, when the -Overwrite argument is used, any changes you made to the web.config file will be lost.  So, don’t forget to add the <trust level=”Full” /> text just before the </system.web> text in the web.config file after the utility has completed its execution.

This tool is available for download from: http://go.microsoft.com/fwlink/?LinkId=92955, and the documentation for it is located at: http://technet.microsoft.com/en-us/library/bb245933.aspx.

CopyUtil.aspx: a little SharePoint Gem

by community-syndication | Feb 26, 2008 | BizTalk Community Blogs via Syndication

Did you ever had the need to navigate to a SharePoint list item or document, when you only got the ID’s of the item, the item’s container (list or document library) and the item’s web? I sure did! For example when you query SharePoint data by making use of the SPSiteDataQuery class; the resulting data table includes all those ID’s (and additional properties if you want), but it doesn’t include a link back to the item. You could make use of the Object Model to build the link in code, but that is both resource intensive and pretty complex. In that case you have to check out the CopyUtil.aspx page, which is also used by the Content Query Web Part by the way. The CopyUtil.aspx page is an application page to which you can provide a bunch of ID’s, as a result the page will redirect you to the corresponding item or document.

You just have to build a URL like this (replace the X’s with the actual ID’s of course):

http://yoursite/_layouts/CopyUtil.aspx?Use=id&Action=dispform&ItemId=X&ListId=X&WebId=X&SiteId=X

And the CopyUtil.aspx page will do the rest!

I couldn’t find any documentation for this page, but with a little Reflect-ering, I found out that the Action parameter can be either dispform or editform (redirecting either to the view item URL or edit item URL).

Don’t forget – BizTalk User Group meeting Feb 27th – Wed Night at Microsoft

by community-syndication | Feb 26, 2008 | BizTalk Community Blogs via Syndication

See you there folks – let’s kick off 2008 in style!!!

What’s
new in the .NET 3.5 Framework from a BizTalk perspective

Complete Schema Listing for R2 – Part 4: EANCOM Schemas (D93A, D96A, D01B Syntax Version 3 & 4)

by community-syndication | Feb 25, 2008 | BizTalk Community Blogs via Syndication

We have had a number of requests for the specific documents supported by standard, by version in addition to just the number of schemas per standard, per version. Thanks to Keith Bauer, one of our field PMs for compiling the lists. I’m splitting them up into several posts because each is rather big and most people care about a particular standard so this will make it easier to search.

EANCOM – Versions and Releases

Complete Schema Listing for R2 – Part 3c: EDIFACT Schemas (D03A – D05B)

by community-syndication | Feb 25, 2008 | BizTalk Community Blogs via Syndication

We have had a number of requests for the specific documents supported by standard, by version in addition to just the number of schemas per standard, per version. Thanks to Keith Bauer, one of our field PMs for compiling the lists. I’m splitting them up into several posts because each is rather big and most people care about a particular standard so this will make it easier to search.

EDIFACT – Versions and Releases