EMS 动态queue

在EMS里，动态queueu是由application产生的，而静态queue是由管理界面或修改config文件创建的. 动态queue有很大的灵活性，在某些场合比使用静态queue更适合。有关讨论可以看JMS。

1）EMS的动态queue是以 "*" 作为开头，还有一种特殊的动态queue叫临时queue, "*"开头后紧跟$TMP$
2)如过动态queue没有consumer也没有信息在队列中，ems会择机清除该queue
3)临时queue的名字是由EMS server生成，只有在创建该queue的session才能消费里面的内容。EMS 重起后临时queue会被清除，不管里面有无内容。
4）要允许application创建动态queue，queues.conf 必须使用wildcard进行配置。

Tibco Designer Mapping - Attribute 的默认值

在定义schema时我们可以为元素的attribute定义一个默认值，事实上Tibco有可能不会帮我们自动填充。借用我的另一篇文章的mapping ，这里我们的目的是把红箱的内容mapping到蓝箱去，我们定义了蓝箱schema（目标schema)中BlueCotainer元素的desc属性默认是40ft.

这个mapping是如此简单我们会很自然采用了如下的process, mapping是在end这个Activit 中完成。但结果没有像我们预期的那样当红箱不提供desc的时候蓝箱自动补上40ft这个值。

我们试了一下引入Mapper，mapping在Mapper中完成后copy到end中，如下图：

这下终于可以了。对比了一下两个不同process的XSLT, 关于mapping的部分并没有什么不同，只能归结于BW引擎对待二者的工作机制稍有不同。所以如果想尽可能发挥schema的功能引入mapper是不错的选择，尽管很多时候多此一举。

Tibco Designer Mapping - Empty Node

在BW中除了按照要求进行符合schema的mapping外，更高的要求是不要产生空节点，即如果input数据元素没有的话结果也不应产生。按照下图的map法，即使没有RedContainer，一个空的BlueContianer节点会出现在结果里。好友鸡尾虾提醒说这并不是Tibco的错，原因在于xpath只是帮我们在节点中导航而并作额外判断（虽然mapping的界面看来如此）。

正确的做法是先多RedContianer进行循环，对于schema结构相差较大的mapping必须采用更多的判断来防止这种无意义的空节点。

Tibco Designer Mapping - Looping

设计BW流程我们要经常涉及mutiple节点到mutiple节点的mapping, 往往一不小心就会得出错误结果。例如我们要从origin.xsd的数据mapping到dest.xsd中：

这里的两个schema大同小异，不同部分用红色箭头标出并且我们有如下输入数据：

如果使用下图这样的mapping方法，注意在集装箱这个元素上我们没用任何操作：

得出的结果会是是原来两个红色集装箱的货物都装到一个蓝色集装箱里了。

我们接下来是一下把集装箱的信息也关联起来：

可以得出结论是原来两个红色集装箱的货物都一一搬过两个蓝色集装箱中了。到底采用哪种mapping就要看我们的实际业务需要了，不过不小心还是会得出错误结果。

Acknowledge Mode in Tibco BusinessWork

BW经常要侦听queue，接收到信息后启动process进行处理。有两种mode是BW比较常用并且容易出现问题的: TIBCO EMS Explicit Client Acknowledge 和Client。其中前者是使用Tibco EMS才可以使用的，为方便我们简称为Tibco， 两种方式都需要在随后的Process流程中使用Confirm Activity才能把信息从信息从队列中清除。

使用Tibco这种方式如果由于某种原因没有Confirm, 所有同一session中delive的信息都会重新delive。比如队列中有5条信息并且编号分别为1，2，3，4，5，Tibco会启动5个实例分别来处理这5个信息。假如1首先完成但没有confirm（例如异常没有被捕捉或bug),这时这5条信息会被重新delive并且5个新的实例会被启动，加上原来的4个，就共有9（5+4）个实例在运行了！

如果使用Client这种Acknowledge mode, 要在designer里填入max session（比如输入10）的值，个人觉得这应该是运行时所允许的最大实例数目。同样上述的情况下，只有没有被confirm的信息会被重新delive,也就是说会有5（1+4）个实例在运行。在这种模式下你会发现有10个侦听器会在队列上面。

总而言之无论何种情况，包括发生任何异常porcess都应该能够捕捉并处理，使得confirm能够把信息从队列中清除。更重要的是对于Tibco Acknowledge这种模式你可以在发布应用时指定或不指定最大实例数，垃圾信息驻留在队列中也是bug.

Tibco EMS routing 设置之二

2）authorization=enabled ，注意这仍然是BLADE的设置，这表明这是其他EMS(例如VAMPIRE)作为客户登陆入BLADE需要用户名和密码。要启动该选项，输入命令:

set server autohorization=enabled

改变该设置并不需要重启服务。此时我们可以发现信息都pending在VAMPIRE这台EMS中。我们要在BLADE建立用户帐号如下：

create user VAMPIRE password=12345

这里一定要注意VAMPIRE是帐号，一定要是要登录进来的服务名。最后一步是设置VAMPIRE这台EMS，EMS会用自己的服务名来登录，关键就是设置密码：

set server password=12345

VAMPIRE会用这个密码登入BLADE，我们可以发现信息又可以routing到BLADE。

用Tibco Designer做开发 1

Tibco Designer是一款不错的IDE，可惜一些基本功能，搜索，重构，错误修复比起"传统的"基于source code的IDE来说，还很不足。

图形化开发好处是每天只要点击点击鼠标就把事情搞掂了，坏处是事情变得简单之后就让人不愿意多想，加之需求的变化，设计的变化，在不断的连线画图之后，怪物就此诞生。

这些天吴老板叫我重构，花了很大力气之后，有了以下的感慨。

细化process，我觉得在一个process里要么就全是调用其它子process，要么就只有具体的activity，不包含子process，子process之间的数据传递完全用copy或者copy contents of的方式传递，这是比较完美的。每一个最底层的process（只会被其它process call的）只做确定的一件事情，涉及到两种schema的转换或者是把多个process的output汇总到一个xml node的行为都用单独的process封装起来。
这样的带来的附加好处是方便unittest，每一个小功能都可以直接用tibco test测试了。
另外，一些数据长度判断等数据有效性校验都封装在底层的process中，外面的流程尽量简介易懂，美观第一。


谨慎地定义接口，在定义接口（process的start和end的数据结构）时，全面分析各项impact，应该是什么数据类型，该节点是不是 mandatory的，最宽泛的接口定义是把所有的节点都定义成optional的string类型，这最终会害死人，苛刻的接口定义会把许多错误在开发 阶段暴露出来，并且有个附带的好处，用tibco test做unittest的时候，系统会自动生成mandatory的节点，方便我们填写测试数据，如果没有含混不清的接口定义，填写了 mandatory数据后这个test就能跑了。

如果一个数据结构在超过两个地方出现，在外部Schema文件中定义它，然后将该数据结构导入。
以后要修改该数据结构只要修改schema，refresh project，update修改该数据结构的activity即可。而且在designer的input editor里面是不能定义一个节点的attribute的（我没发现相关的方法），在schema文件里可以，虽然这好像没什么用处。
在schema中可以对数据进行进一步的限定，如最大最小长度，枚举类型等等，结合上面说的接口定义可以做出更严格的接口。

在process的Description里面填写一些说明和测试数据。

进行有意义的命名，填写label，对线条着色都能让项目好看一点。

如果视图超过了一屏，就改考虑要重新规划一下了，把功能相关的调用封装起来，无论从视觉效果还是做debug，unittest，感觉都会好得多。

其实还是老话，封装变化，模块化开发。



W. C. Fields  - "I cook with wine, sometimes I even add it to the food."

关于Blade

刚转Team的时候刀哥休假在外，他的铭牌上写着Blade，当时就想怎么这么巧，原因是我正在用wilson ncode Blade 98 这款网球拍并且非常迷Djokovic

我和刀哥的另一共同点是我们都非常喜欢Blade这部电影，见面后没几天我就忍不住问“你的名字是不是从电影Blade取的“，回答当然是肯定的。不仅如此，他的睡房有海报，ipod里还有对白；
Vampire：Blade, ready to die?
Blade: I am born to be ready you mother fucker!

想不到我提出开通这个Blog的时候会得到刀哥和J...积极响应，刀哥更是连夜弄好并发了处女作，尽管我不喜欢他称我为林总。Anyway，谢谢刀哥，没有你就没有Tibco 1对1。

Tibco EMS routing 设置之一

Tibco Enterprise Message Service (EMS) 是一个兼容JMS标准的实现，是整个Tibco产品中的重要一环。Tibco组件除了可以用它构建整个管理域外，也使用它传递业务数据。通常业务整合的两个或多个party会使用并管理自己的EMS, EMS 支持信息EMS(A) routing 到MES(B)。可是往往由于设置不当造成无法通讯

假设现在有两台EMS服务器，名字分别是BLADE和VAMPIRE。注意这里的服务名字至关重要，登陆入EMS管理界面后运行

show server

这里的服务名是在tibemsd.conf里配置，与机器名无关。

下一步要检查EMS的其他设置，运行命令show config

routing的设置的复杂程度在authoirzation=enabled/disabled的不同情况下有很大区别，无论何种情况一定要修改tibemsd.conf设置为routing=enabled并重启EMS。

1）authoirzation=disabled ，注意这是BLADE的设置，这表明这是其他EMS(例如VAMPIRE)作为客户登陆入BLADE不需要用户名和密码。假设我们希望队列mysample里的信息能从VAMPIRE流向BLADE，首先要在VAMPIRE里建立routing, 命令如下：

create route BLADE url=tcp://hostname:port

这里BLADE是信息流向的EMS的服务名，一定要注意不能弄错，否则无法发送到BLADE，以后引用这个route就用BLADE表示即可。接下来我们在BLADE这个EMS里建立带有global属性的mysample队列，所有可以接受来自其他EMS的队列必须带有global属性。

create queue mysample global

最后一步是在VAMPIRE中建立同样名字的队列，命令和在BLADE中的有所差别：

create queue mysample@BLADE

这里@BLADE表明这个队列的所有者是route BLADE所指向的EMS，所有发送到VAMPIRE 队列mysample的信息都能流向BLADE。

博客介绍—刀哥第一篇

用tibco公司的产品做项目已经一年多了，痛苦感慨都有不少，不像其它技术，平时遇到一些问题时google基本无效，好在Tibco的文档较全，咱Team的林总（Johnny Lin）不干了，说“咱也写个博客吧，把心得记下，也好方便后人”，基于这么一个崇高的目标，我们的 “Tibco 1对1”应运而生了，记录我们与Tibco的点点滴滴。

但是这个博客并不局限与此，也可能会写一些关于其它技术的文章，也可能有无关乎技术的文章，现在的作者是我和Johnny哥，以后可能会有我们Team的其它人进来写，也可能会有更多的热心人参与进来，谁知道呢。

希望我们能做出一点事情，能给他人一些启发。