BizTalk 2010 EDI: Configuring ISA11 as Repetition Separator

Had an interesting EDI issue that occurred recently with how BizTalk 2010 parses the value for ISA11. In older EDI versions, 4010 and below I believe, ISA11 was called the “standards identifier” and was always set to “U”. Newer versions of EDI added a new delimiter called the “repetition separator” and repurposed ISA11 to define what this character would be in an interchange.

In the event we were seeing errors like this:

Error: 1 (Miscellaneous error)
    16: Invalid Control Standard Identifier

Error: 2 (Field level error)
        SegmentID: ISA
    Position in TS: 1
    Data Element ID: ISA11
    Position in Segment: 11
    Data Value: ^
    7: Invalid code value

BizTalk should automatically parse this correctly based on the EDI version defined in the schema but in my case it was defaulting to the old behavior even though the version in the schema was 4060. We even tried to setting the UseIsa11AsRepetitionSeparator property on the EDI pipeline to True but BizTalk was still parsing it like a 4010 transaction.

We fixed this using the following steps:

  1. Open the party properties and ensure the Local BizTalk processes messages received by the party or supports sending messages from this party option is checked.
  2. Open the agreement properties and choose the outbound settings tab.
  3. Select the Envelopes option from the tree view on the left.
  4. Under ISA11 usage select the Repetition separator option.
  5. Go back to the party properties and uncheck the Local BizTalk processes messages received by the party or supports sending messages from this party option.
  6. Restart the host instances used to receive EDI transactions to apply the changes.

This is what my Envelopes configuration looks like:

Envelope settings

I do not understand why changing the outbound settings would have any impact on how BizTalk parses an inbound interchange but it works. At some point I will have to see if this is still an issue in BizTalk 2013.

Be Careful When Using the %SourceFileName% Macro

One of my team members ran into a interesting problem when using the %SourceFileName% macro in a send port. In this scenario the client was receiving EDI data in files and they wanted a copy of the original data sent to an archive folder using the original file name. During testing we would occassionally see the following warning messages in the event log:

"The FILE send adapter cannot open file C:\Work\BizTalk\SourceFileNameTest\Out\EDI_X12_864 - Copy.edi for writing.
Details: The file exists."

What was happening is sometimes a single EDI file (interchange) will contain multiple transactions. By default, BizTalk will split the interchange into individual transactions in the EDI pipeline. Since all the transactions came from the same source file, each transaction will contain the same value in the FILE.ReceivedFileName context property. This is the context property that the macro uses to name an output file. When BizTalk would attempt to write the transactions to the archive folder, the first transaction written would succeed and the remaining transactions would trigger the file exists warning.

To work around this behavior you can do one of the following:

  1. Add some sort of unique identifier to the file name. For example instead of using just %SourceFileName% you could combine it with %MessageID% to generate a unique file name for each transaction.

  2. Configure the file adapter to allow appending to an existing file.

  3. Configure the EDI party agreement to preserve the interchange. This would keep all the transactions in a single message. In this case you would need to build additional functionality into your BizTalk application to manually split the interchange.

Viewing Remote CUPS Printers in Fedora 19

Who Moved My Cheese?

I found out the hard way that a number of things changed between Fedora 17 and Fedora 19. One thing in particular is using CUPS and IPP to automatically access remote printers. Due to my ignorance on some of the changes with systemd and firewalld it took me a lot longer than expected to get this working after upgrading to Fedora 19.

At home I have an old laser printer connected to a small server that is shared via CUPS. In the past getting this working from my laptop has been as simple as enabling mDNS and opening the IPP port in the firewall tool. In Fedora 19 this has changed a little bit. mDNS is now enabled by default so that part is easy. This leaves getting CUPS services properly configured and opening the correct ports with firewalld.

Configuring CUPS

In Fedora 19, CUPS services have been split into a handful of separate services. I had to execute the following commands to get CUPS fully working:

1
2
sudo /usr/bin/systemctl enable cups.service
sudo /usr/bin/systemctl enable cups-browsed.service

These two commands start the relevant CUPS services. The cups-browsed.service is the new service that finds and registers printers on the network.

Configure Firewalld

Now that the CUPS services are up and running we need to open the IPP client port in the firewall:

1
sudo /usr/bin/firewall-cmd --permanent --add-service=ipp-client

Once both of these steps have been completed, you should be able to see your remote CUPS printers.

BizTalk Mapping with Multiple Outputs Gotcha

Default Visual Studio XSLT template

This gotcha was something that caused me a fair bit of wasted
time the other day. I was building a map with two destination schemas.
Since the map had some complex looping and grouping requirements I
decided to build the map using a custom XSLT script. (Nowadays I build
almost all my maps using XSLT but that’s a story for another time.) The
map ran perfectly using the Visual Studio map testing tool but when it
was executing in the orchestration I kept getting the following error,
“Output of the transform does not match the expected number of output
parameters.”
.

After a few hours of hair-pulling frustration and a couple of test
projects I finally figured out the source of the problem. If you use
File -> New -> File -> XSLT File in Visual Studio, by default it sets
the indent attribute on the XSLT output element. For reasons unknown
having the indent turned on causes this strange error to occur. Removing
that attribute caused the error to disappear and the map executes as
expected.

Hopefully this will save somebody else some time and hassle.

All Good Things Must Come to an End

The “Distributed Weekly” post this week marks the four year anniversary
of my link blog covering integration and distributed systems. This will
also mark the last “Distributed Weekly” link post. After four years I
have decided it is time to hang it up. At this point there are better
ways to find interesting links out there. There are plenty of computer
algorithms capable of finding topical content faster than I can research
and curate links and they are getting better all the time. (My current
favorite is Prismatic) I have enjoyed curating links over the past
four years but I am ready to move on and use the time for some personal
projects.

I will continue to blog here and I am hoping that some of my new
projects will result in more long-form posts.

For those who are interested I will still post links to my Twitter
and Google+ accounts on occasion.

Thanks for reading.

Distributed Weekly 208

API

Architecture

Cloud

Distributed Systems

EAI

Integration

Messaging

Workflow

* Courtesy of Alvin Ashcraft’s Morning Dew.

Distributed Weekly 207

API

Architecture

Data Formats

EAI

Events

Messaging

Distributed Weekly 206

API

Architecture

CEP

Cloud

Data Formats

EAI

Messaging

* Courtesy of Alvin Ashcraft’s
Morning Dew
.

Distributed Weekly 205

API

Architecture

Cloud

EAI

Messaging

Security

Semantic Web

* Courtesy of Alvin Ashcraft’s Mornined Dew.

** Courtesy of API Digest.

Distributed Weekly 204

API

Architecture

Cloud

EAI

Messaging

REST

Security

* Courtesy of Alvin Ashcraft’s Morning Dew.