Managing Receive Functions

So, you have been a good developer and made sure that all of your specs and maps are validated and tested, yet every time you drop a document into a folder for a Receive function, you get a validation error. Even worse, you only get a validation error occasionally. Assuming the error message you get resembles that shown earlier in the section, Locating the Errors, pay special attention to the line that reads:

The following channel configuration setting is not valid: "Channel to convert Inbound to Outbound"

Is that really the channel you are testing? No? If the wrong channel is getting the message, don't be surprised if that is telling you that the wrong Receive function is picking up the message. Remember, a Receive function polls for a particular type of file in a particular location, so there are two ways in which Receive functions can overlap. Multiple Receive functions might look in the same folder for different file types.This can be a perfectly good design—consolidating all incoming messages in one place. Multiple Receive functions can also poll for the same file type in different locations. Perhaps all PO*.xml files for Company A are sent to FolderA, and all PO*.xml files for Company B are sent to FolderB.This is also a perfectly viable solution to perhaps the two different POs needing to be processed differently. The trouble occurs when multiple Receive functions are polling for the same type of file and in the same location.

During development time, it is easy create many different Receive functions for many different purposes, and along the way, inadvertently create this problem. Unless you disable the Receive function, each will try to pick up the file type it is looking for, and as a result, send a perfectly good message to a perfectly wrong channel, and the first sign of trouble is a document validation problem. To make matters worse, you will not know which of the competing Receive functions will pick up the file first at any given time.


Two practices will help avoid competing Receive functions. First, take the time to create a unique folder for each file Receive function, and a unique message queue for messaging Receive functions that you create during development. Give them meaningful names, so they provide more clues as to their purpose. Second, disable Receive functions that you are not currently using. These two strategies should help keep Receive functions out of your debugging path.

Up to this point, we have discussed Receive functions that refer to channels, but the same problem can arise when using self-routing documents that depend on organizations and document specifications. Obviously, any set of data that is designed to determine a processing route is subject to duplication, which leads to competing Receive functions. Let's clarify, however, that this is a completely separate topic from duplicating Receive functions across multiple servers to improve performance. Receive functions in that case are meant to grab the same messages and send them to the same destination.

Remember also that Receive functions are always listening, and as soon as they "hear" the type of document they are looking for, they will pick it up. So, what happens if you are sending an asynchronous DOM message to a message queue, or building an XML file by incrementally writing text to the file? The message or file could qualify for the Receive function before it is complete, and thus, the Receive function grabs what it can.The result is a document validation error, of course, and this type of error could send you down a completely inappropriate troubleshooting path.To prevent this problem, write your DOM messages to a queue with Async=False, and don't "build" files where they are to be received. Build them elsewhere, and copy the complete file over to the Receive Function folder.

Now, what if you can't get any Receive function to pick up a file. Go back to BTS Administration and check that the Receive function you had in mind is, in fact, enabled. BizTalk Receive functions have a fairly rare quality in that if they encounter a problem, such as a file location not existing, they will disable themselves, but they will not re-enable themselves. This is very practical when you think about, but since you might not necessarily notice when it disables, you might not think to check on it. If the Receive function continues to disable itself when you re-enable it, it is merely telling you that you have not found the problem parameter yet.

Was this article helpful?

0 0

Post a comment