2

在 BizTalk 表达式形状中，我看到了一个空白文本编辑器，上面有一些粗略的“示例”，嘲笑我。“这太容易了”他们高呼。尽我所能，我只是没有建立联系。也许我想多了。我是 BizTalk 新手。来自多年沉重的 .NET 和软件工程经验，我的想法似乎并没有脑...

具有丰富 BizTalk 经验的人会在这个问题上启发我：在表达式形状内的范围内和可用的内容是什么？随后，MessageAssignment 形状也是如此？

范围，我的意思是像在真正的编程中一样：变量名、命名空间等。

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

它假设我知道“MyMessage”是在哪里创建、实例化和访问的。我不知道在哪里初始化它，用什么形状标识符来命名，等等。

我的设计看起来很简单：当错误发生时，捕获它，凭空创建一个 ErrorMessage，将字符串值分配给一个可区分的字段“原因”，然后发送到一个发送端口。除了表达正确，我什么都可以。

非常感谢任何专家的见解。

4

2 回答 2

4

您只能在Construct Message形状内创建消息，然后在其中 创建Map或Assignment形状。您不能在表达式形状中构造消息。

地图选项

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

注意：如果范围涵盖除初始接收之外的所有内容，则此初始接收消息是您确定在编排中唯一的消息。我只在涉及格式错误的 MIME 消息的边缘案例中遇到过一次，该消息导致编排启动但没有此初始消息。

非地图选项

在没有地图的情况下仅使用分配形状创建它

  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. 手动创建消息，例如下面通过在消息分配形状中创建新消息

例子

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

创建消息变量

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

在此处输入图像描述

表情形状的其他限制

有关表达式形状的其他限制，请参阅表达式的要求和限制

于 2016-06-21T20:49:59.080 回答
3

@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;
}

通常，这是一个坏主意。您通常应该使用常规构造消息形状 - 为什么？因为当您一年后（或其他人）查看您的编排时，您在哪里构建消息将立即显而易见。决策形状也是如此——在某些情况下，决策形状可能有点矫枉过正，但对于未来的开发人员来说，决策逻辑将立即显而易见（而不是if在表达式中寻找语句）。表情形状应该：

  1. 始终正确命名/标记。不要让自己试图弄清楚Expression_2实际在做什么，将其命名为有用的名称，例如“增量循环计数器”
  2. 避免冗长的表达。编辑器不是很友好（智能感知非常有限，没有高亮，没有自动格式化）。我不止一次因为点击Esc而不是点击而丢失了表达式形状的代码，OK并且没有立即意识到我做了什么。对于 XLANG/s 特定的事情（比如使用xpath函数，或访问可区分的字段，或做简单的事情）非常有用。如果您要处理更复杂的逻辑，请让您的代码调用编排项目引用的 C# 帮助程序库。
于 2016-06-22T12:54:57.823 回答