我们真的必须要Composer与PDM的集成么？

tangvw

<font size="3">http：//www.3dmojo.com/cad-reuse/content-creation-or-content-management/2008/05/13/
这是官方博客上的一篇文章，是其开发团队工程师对于集成问题的他们自己的看法。英文好的可以自己去看。没时间翻译的我可以简单介绍一下他的想法，如有不对请英文达人帮忙指出。
这篇文章里，这名工程师以他作为开发者的角度指出了，几乎所有客户在与他们讨论composer时，都把它与solidworks.com.cn/portal.php?mod=list&catid=70" target="_blank" class="relatedlink">PDM/PLM是否能够很好的集成作为一个重要的，甚至是首要的问题。他认为一味关注这个是个倒退的观点。这里他提了两个有趣的比喻，把Composer集成进PDM/PLM比作：把车放在马前面（本末倒置），先有鸡还是先有蛋（谁应该在前面）。答案不言而喻，产品内容的创建一定是在其内容管理之前的，你不可能先用PDM去管理那根本还没创建的内容。（他原文说的是这就好像是在你拥有CAD软件和CAD数据之前你先去实施PDM一样）。
也就是说：
#这一段是我自己的补充解释，Composer的使用是与设计同步的，它创建的内容是在数据管理之前就需要相对独立完成的工作。至于PDM中比较重要的ECR/ECO（产品变更），这个可以由sync独立的大量的方便的完成，完全不需要再走一遍PDM流程（产品文档只由对应产品决定，不可能有别的出入，PDM流程里决定了产品更改的结果，那么产品文档自然也就有了结果），因此3DVIA Composer曾提过它是轻量化桌面环境的软件也正是说这一点，独立的，简便的就可以对产品文档进行创建和维护。不受数据管理系统约束，只要有CAD数据就可以。补充解释结束
接着他说，他们也讨论过单一解决方案集成入大型数据管理系统，举了PTC的Arbortext（文档发布）和Isodraw（技术插图创建）集成进它的PDS系统里。这种把制作，创建，等步骤都分成单一的软件来解决，之后再集成起来形成制作流，未尝不可，但是存在一些问题：集成的好，用起来连接无缝如一个整体这自然好。可是这种步骤分化的方式很容易产生木桶原理效果，就是一个木桶的容积取决于最短的那个木条的长度。这里作者说Isodraw在快速创建及更新方面的薄弱，制约了Arbortext在对于文档管理和发布方面的优势。。与其这样，还是把文档创建的任务交给一个独立的，一体化轻量化的软件来完成不是更好么。这就又回到了Composer。
#提一下，上面的例子的客观内容是事实，但是作者的主观评价有多少各为其主的意味我就不好说了，大家仁者见仁智者见智嘛。但是如果Composer把自己定位在Arbortext+Isodraw这个档次就有点令我费解和失望了。人家PTC还有ProductView（产品可视化及协同设计）你咋不说呢。仅从两者白皮书上看，ProductView与Composer的功能几乎相同，功能前者比后者也只多不少，只强不弱…。不过没有机会实际操作ProductView，其两者有个共同的客户就是美国JohnDeer（这公司看着眼熟不?Composer演示视频有一个就是为它做的，同时ProductView白皮书里也有它。这公司很奇怪，哪家公司的大型合作伙伴里都有它，PTC有，DS有，UGS也有，它得有多少钱啊，上这么多大同小异的玩意。-_-!）另外Isodraw我试用过，主要是用黑白灰线条表示3D技术文档，和Composer的矢量图效果几乎相同。也可以做简单的渲染，这些渲染效果取决于原CAD中设置的效果，而非自己的渲染引擎。它可以实现自己创建功能，也就是一条线，一个圈，一个拉伸等等自己画（累-_-!）。另外也可以导入一些格式的CAD数据，不过大部分是PTC自己的格式，总体数量也没有Composer多，但我相信对于PTC格式的支持它肯定强于其他同类软件。
然后呢,作者说,其实内容管理系统“content management system”（他全篇都说content management，content creation，内容“content”我想和产品文档指同一个东西吧。）提供的功能都是大同小异的。（我揣测他的意思是指针对产品文档，带进PDM的工作流里或是由Sync独立管理，其结果相差不大？）真正重要的是内容的创建“content creation”，（而我们的客户一再告诉我们Composer在这方面就是万王之王。原文：In this context, content creation is king, and our customers keep telling us that 3DVIA Composer is the king of kings. 额滴神啊，这个有点……有点肉麻过分了……-_-!!）一旦他们通过桌面实施（非PDM集成）实现了利益最大化，（也就是省钱了^_^），他们会告诉我们Composer十分优秀而简便的与他们的系统集成在了一起，（与他们的什么系统？操作系统？windows？还是客户高兴了就什么都是好的呢？呵呵开个玩笑。）他们的想法十分明确：通过在桌面（也就是在windows桌面操作环境下，而非PDM环境下）执行一款独立的优秀的软件，让他们摆脱繁复细分的流程操作，最终能够愉快而高效的工作。至于最后生成的数据，是否要集成回服务器，那取决于客户想怎么工作。（客户就非要把这些文档文件扔回数据库和产品数据放一个表里，不然不验收，你说你集成不集成？）
最后他想象了一下：这样一个使用者喜欢的，并且通过其自身具备的一系列专业能力而让客户高兴去用的，完全不需要硬性的去适应各种环境（PDM/PLM）的系统。现在不就相当于同时拥有鸡和

sungh2591

与PDM集成，我想最大的好处是自动更新文档说明书。
Composer的优势之一就是与CAD文件关联，自动更新功能。
通过设置，当SW的文件发生变化之后，点击一下更新文档（当然也可通过流程自动触发），那么文档就自动更新了（所有用到的图片都更新了），原理是通过设置运行参数，在后台调用Composer来执行。
这个功能很酷，在PDM的demo中可以看到。

yifeng-min

不与PDM集成也能更新图片。实际上更新图片的工作不是由Composer完成的，而是有PUBLISHER软件完成的动作。Composer只是完成了制作图片的动作。