在Node-RED中，我们可以创建自定义节点。这些执行特定的工作，这些工作不是由开箱即用的预先提供的节点提供的。有许多社区提供的这些实例。自定义节点可能希望处理某种新形式的输入事件。让我们想象一下，我们有一种名为2TinCans的新网络技术（2个锡罐由一根字符串连接）。如果我们希望使用它来处理请求/响应，我们可能会创建两个新的Node-RED节点...一个用于处理输入（请求），另一个用于处理输出（响应）。当请求到达时，在Node-RED中运行的2TinCans服务器已经在侦听传入的请求。收到请求后，节点会向下发送新消息。最终，这将到达2TinCans响应节点，该节点负责将响应发送回相应的原始请求。
问题出现在哪里......我们如何维护此对话的“状态”，以便响应节点知道将响应发送给正确的合作伙伴？
答案 0 :(得分：1)
我们需要维护源于最终响应节点可以使用的原始传入请求节点的状态和信息。
在Node-RED环境中，我们有许多上下文对象，包括每个节点的上下文，每个流的上下文和全局上下文。但是，架构不允许将这些用于我们的目的。本地节点上下文对我们没有用，因为它将保留传入请求节点的上下文，但是响应节点不能寻址。流动和全球背景都是＆＃34;单身＆＃34; ...这意味着我们保存的任何数据都会被下次调用覆盖。原则上，由于可能会有许多并发流程被执行，我们可以想象两个并行请求同时被处理，并且它们会相互踩踏响应。
将正确的状态信息传递给下游响应节点的正确方法是将该信息添加到流向线路的消息（msg）中。这可以是属性的形式，该属性是响应节点可以调用以完成对话的回调JavaScript对象。