| stheby 2005-02-27, 5:51 pm |
| Hi everyone.
I've got a really simple message assignment shape that contains the
following code:
GapiInCopy=GapiIn;
GapiInCopy(GloviaBTG.GapiType)=GapiIn(BTS.MessageID);
My objective is to retrieve the current MessageID and place it into a
newly "constructed" message.
The "GapiIn" message above enters the orchestration by a prior "receive
shape" and then a new "GapiInCopy" message is created from this "GapiIn"
message in an "assignment shape".
Next, in the same "assignment shape", the promoted "GapiType" element
value within the "GapiInCopy" message is assigned the "MessageID" value
from the original "GapiIn" message [GapiIn(BTS.MessageID)]. Note: the
"GapiType" element has been promoted in a property schema associated
with inbound "GapiMessage" and I assumed that when a message is copied
that has promoted elements, the copy also has the same promoted
elements; is this correct?.
These messages are all defined and there are no errors at build or
deploy time. During runtime, I get the following error:
Uncaught exception terminated service
GloviaGTB.GTBOrch(37ff77f2-64f4-6da7-4225-61a5be39b603),
instance 74cabac8-b2b5-46c5-8009-7b07c3c1062b. There is no value
associated with the property 'BTS.MessageID' in the message.
Can someone suggest the best URL that clarifies this area?
Can someone suggest what I'm doing wrong here? I like BizTalk but it
sure is a gray hole (as opposed to a black hole in which nothing
escapes). My estimates for this project were off 600% (to be fair, we
are not a .NET shop).
Thanks a million!
Stephen
PS:
I've looked at existing BizTalk documentation as well as a number of
blog entries relative to this area but no one has clearly explained what
namespaces and corresponding values are available during the various
steps of orchestration development. Its ok to hide complexity under a
graphic model as long as we can look under it when this becomes necessary.
PLEASE, PLEASE someone @ Microsoft construct a list of all elements
available (global & local by BizTalk process boundary (i.e.,
receive/send port, receive/send pipeline, receive/send shape, etc) and
publish it as soon as possible. Developers need to know what and when
data is available and how to access it. Every namespace and their
contained elements used by BizTalk needs to be clearly documented.
There seems to be mass confusion about this area and I don't think
that BizTalk will accelerate until it is cleared up.
|