BizTalk Expression形状范围内的内容是什么？

Question

在BizTalk Expression形状中，我提供了一个空白文本编辑器，其中包含一些粗略的＆＃34;示例＆＃34;嘲笑我。 ＆＃34;它很容易＆＃34;他们呗。尽我所能，我只是没有建立联系。也许我在思考它。我是BizTalk的新手。来自多年繁重的.NET和软件工程经验，我的想法似乎并不像大脑......

具有出色BizTalk经验的人会在这个问题上给我启发：什么是范围并且可以在Expression形状中使用？接下来，MessageAssignment形状也是如此？

根据范围，我的意思是在实际编程中：变量名，命名空间等。

我在BizTalk上看到的每个例子都假设您了解这些事情的来源。例如，请参阅此MSDN页面：Using Distinguished Fields and Property Fields

它假设我知道＆＃34; MyMessage＆＃34;已创建，实例化和可访问。我不知道在哪里初始化它，给出名称的形状标识符等等。

我的设计看似简单：发生错误时，抓住它，凭空创建一个ErrorMessage，将字符串值分配给一个可分辨的字段＆＃34; Reason＆＃34;，并发送到一个发送端口。除了正确的表达，我能得到一切。

非常感谢任何专家见解。

Answer 1

您只能在构造消息形状内创建消息，然后才能创建消息 地图或分配形状。您不能以表达式形式构造消息。

地图选项

对于Exception块中的映射，您可以映射的唯一消息是在Exception块所在的作用域之前创建的消息。因此，对于整个Orchestration的异常块，我从接收到的消息中映射。初始激活接收（应该在范围之前）以及错误消息模式。然后，您可以在地图后的构造形状中进行消息分配。

注意：如果范围涵盖除初始接收之外的所有消息，则此初始接收消息是您在业务流程中唯一确定的消息。我只有一次涉及格式错误的MIME消息，导致Orchestration启动但没有初始消息。

非地图选项

仅使用分配形状

创建没有地图的地图

1. 需要调用外部类，例如ESB故障处理eSBFault = Microsoft.Practices.ESB.ExceptionHandling.ExceptionMgmt.CreateFaultMessage();，其中eSBFault定义为消息类型Microsoft.Practices.ESB.ExceptionHandling.Schemas.Faults.FaultMessage

2. 从其他现有消息中分配，例如xTempDoc= wcfFault.fault;在此示例中，wcFault是Catch Exception中设置的异常对象名称，xTempDoc是System.Xml.XmlDocument类型的变量，然后分配给消息变量。

3. 从creating a new message in the Message Assign shape

手动创建下面的消息

实施例

xmlDocMessage = new System.Xml.XmlDocument();
xmlDocMessage.LoadXml("<Out><ErrorCode>4711</ErrorCode></Out>");

创建消息变量

对于上述所有内容，您需要进入Orchestration视图并创建该消息名称的Message变量，并将其设置为要构造的消息的Message Type。它需要位于构建它的范围或封闭范围内。注意：它仅在您定义它的范围内或在定义它的范围的子范围内可用。



表情形状的其他限制

有关表达形状的其他限制，请参阅Requirements and Limitations for Expressions

Answer 2

@ Dijkgraaf的回答非常好，但从技术上讲，表达式编辑器可以让您访问XLANG/s language。 AFAIK你仍然必须如他所说明的那样声明变量（使用编排工具箱窗口）。然而，语言本身有点类似于C＃和.NET，你可以在技术上做任何表达形状的任何东西，否则你可以使用适当的关键字做其他形状。

例如，可以construct表达形式的消息construct OutboundMessage { XmlDocument.LoadXml( @"<?xml version='1.0' standalone='yes' ?> <Root id='012345' xmlns='http://schemas.sample.org/BizTalk/2010/input' /> "); OutboundMessage = XmlDocument; } （取自此blog）：

if

通常，这是一个坏主意。您通常应该使用常规构造消息形状 - 为什么？因为当你一年后（或其他人那样）看你的编排时，你将立即明白构建消息的位置。同样可以用于决策形状 - 在某些情况下，决策形状可能有点过分，但对于未来的开发人员来说，显然会有明显的决策逻辑（而不是在表达式中查找Expression_2语句）。表达形状应该：

1. 始终正确命名/标记。不要试着弄清楚Esc实际在做什么，把它命名为有用的东西，比如＆＃34;增量循环计数器＆＃34;
2. 避免冗长的表达。编辑器不是很友好（非常有限的intellisense，没有突出显示，没有自动格式化）。我不止一次通过点击OK而不是点击xpath并且没有意识到我立刻做了什么而丢失了表达形式的代码。它对XLANG / s特定的东西非常有用（比如使用{{1}}函数，访问区分字段或做简单的事情）。如果您正在进入更复杂的逻辑，请让您的代码调用业务流程项目引用的C＃帮助程序库。