Windchill一些keynote.doc

1、 container和context的关系 Windchill 环境由一组容器组成，其中包括所有的管理区域 ( 称为域)、规则以及组成Windchill 用户工作上下文的数据。虽然基础代码引用的是容器，但在整个用户界面中使用术语“上下文”(Context) 来标识特定规则、域和数据在框架中所处的位置。由于“上下文”(Context) 是在界面中显示的标签，因此本指南使用上下文一词 ( 而不是容器)，以便您与用户界面建立关联。除非正在使用代码，否则就可以假定上下文和容器指代的意义相同。2、 共享团队 站点管理员在分析需要访问数据的用户后，将确定是否还需要其它组织上下文。组织上下文可以只允许组织成员访问数据。例如，如果 Windchill 解决方案将由多个公司使用，而每个公司有一组不同的数据和规则要在解决方案中使用，则最好为每个公司设置一个组织上下文。但如果只有一家公司积极使用解决方案，而其它公司只提供由初始组织管理的数据，那么有一个组织上下文就足够了。站点管理员或组织管理员在确定所需的组织结构后，将确定是否有一组或多组用户需要访问在一个组织上下文中创建的多个应用程序上下文中的数据。如果有多组用户要访问一个组织中的多个应用程序上下文，则可以在组织上下文级别中创建共享团队。共享团队 标识将在多个应用程序上下文中2-6 Windchill 业务管理员指南一起工作，因此可将他们作为组织上下文中的一个单位一起分配，而不是分别添加到每个应用程序上下文中的一组用户。3、 Windchill的一些业务对象 Windchill 安装过程会建立一组业务对象类型，它们可以在站点上下文中使用，然后可由组织上下文继承，之后可由应用程序上下文继承。使用对象类型允许您通过为每种类型提供一组属性和用户界面功能来将对象分类。例如，归类为文档 ( 使用类型 wt.doc.WTDocument) 的对象拥有的一组属性以及用户界面中可用的操作不同于归类为部件 ( 使用 wt.part.WTPart) 的那些对象。对象类型 显示名称 说明wt.doc.WTDocument 文档 常规文档，例如文本文件或Microsoft Word 文档。wt.change2.WTAnalysisActivity 分析活动 变更数据，用于将分析任务分配给用户。wt.change2.WTChangeActivity2 变更任务 变更数据，用于将产品开发工作分配给用户。wt.change2.WTChangeInvestigation 变更调查 变更数据，用于收集关于产品问题根本原因的信息。wt.change2.WTChangeIssue 问题报告 变更数据，用于报告潜在的产品问题。wt.change2.WTChangeOrder2 变更通告 变更数据，用于收集执行产品变更所需的所有任务。wt.change2.WTChangeProposal 变更提议 变更数据，用于对产品问题提出解决案。wt.change2.WTChangeRequest2 变更请求 变更数据，用于收集做出决定所需的所有变更影响数据。wt.epm.EPMDocument EPM 文档 此类型是下列业务对象可变类型的父类型：workgroup manager CAD 文档( 类型：.DefaultEPMDocument) 动态文档 (类型：.DynamicDocument) 拆分配置文件 (类型：.BurstConfiguration) 注解 ( 类型：.Note)有关可变类型的格式的详细信息，请参见创建可变类型。wt.part.WTPart 部件 数据库对象，代表产品结构中组件的元件。wt.maturity.PromotionNotice 升级 请求通过选择审阅进程请求将一个或多个对象的状态变更为新生命周期状态。wt.part.WTProductInstance2 部件实例 产品的序列化副本，根据特定配置构建。wt.change2.WTVariance 超差 授权偏离按设计配置指定单位数量或指定时间期限。超差由偏差和特许组成。偏差是在构建该部件之前相对于按设计配置计划好的偏离。特许是不符合性的书面同意。com.ptc.wpcfg.doc.VariantSpec 变型规范 在准备创建变量期间为特定可配置部件结构指定的选项集合。变量规范实质上是定义要 通过可配置部件结构创建的变量的特征。注意：并不是所有 Windchill 解决方案都使用全部业务对象类型，Windchill解决方案还用许多其它对象类型来帮助管理管理性进程，例如更新用户首选项、生命周期和工作流。关于使用特定对象类型的其它信息在本指南通篇都可以找到。4、 Windchill数据进程 Windchill 提供下列类型的 Windchill 数据进程，它们可与存储在Windchill 中的业务对象共同使用：4.1、生命周期进程定义一组阶段和关口，用于在对象从概念产生到淘汰衰亡这一发展过程中对其生命进行管理。4.2、工作流进程定义允许工作流参与者查看和传递信息、任务和文档的规则。4.3、变更进程决定如何将变更应用到部件和许多其它数据类型，包括文档、文档可变类型和产品实例。这三个进程协同工作，帮助您管理数据。工作流通常用于驱动生命周期。即，工作流进程用于从一种生命周期状态过渡到另一种生命周期状态。在大多数情况下，工作流进程从生命周期开始。无论如何，由生命周期管理的对象都会在创建时获得一个生命周期。在获得生命周期的过程中，也可以为对象创建工作流进程实例。变更对象是由生命周期管理的对象。每个变更对象在获得生命周期时都会启动一个变更进程。5、 有关xconfigmanager的那些事 xconfmanager 是命令行实用程序，用于在 Windchill 属性文件中添加、删除和修改属性。应使用 xconfmanager ( 或“系统配置器”) 操纵属性；而不应手动编辑属性文件。有一些属性文件不应该使用 xconfmanager 修改。下列注册表文件由 Windchill信息建模器管理，也不应手动或使用 xconfmanager 进行编辑：associationRpertiesclassRpertiesdescendentRpertiesmodelRpertiesmoduleRpertiesmoduleDpertiesxconfmanager 实用程序将变更保存在 site.xconf 文件中，并且提供一个选项以使用那些所做变更生成更新的属性文件。site.xconf 文件包含对 Windchill属性文件所做的变更，这些变更从安装开始并在每次使用 xconfmanager 实用程序或“系统配置器”时产生。xconfmanager 实用程序位于 /bin目录。对 Windchill 安装目录下的 XCONF 文件和属性文件具有写权限的任何用户都可成功运行 xconfmanager 实用程序。xconfmanager 通过 windchill 外壳程序内的命令行执行。有关 Windchill 外壳程序的详细信息，请参见关于windchill 命令一节。xconfmanager 命令仅带常用参数的语法如下：xconfmanager -h -r -s -t -add -remove -reset -undefine -d -p在修改 Windchill 属性时，主要使用 -s、-t 和 -p 参数，使用方法如下：5.1、 使用 -s (-set) 参数标识相关属性并指定新属性值。有关格式化property_pair 值的信息，请参见下面的格式化属性值的原则。5.2、使用 -t (-targetfile) 参数指定属性文件的目录位置。如果文件名或路径包含空格，则必须用双引号 ( ) 将 值括起。最好使用全限定文件名以确保能够准确地参考该文件。5.3、使用 -p (-propagate) 参数将对 XCONF 文件所做的变更传播到要修改的属性文件，以确保 XCONF 和属性文件彼此保持同步。5.4、 使用 -h (-help) 参数查看 xconfmanager 帮助。此帮助说明了所有xconfmanager 参数。此外，还可以使用下列参数从声明为多值属性的属性中添加和删除属性值：5.4.1、使用 -add 参数在已在属性中定义的有序属性值集末尾添加指定的属性值。5.4.2、使用 -remove 参数从已在属性中定义的有序属性值集中删除指定的属性值。窍门：如果不确定某个属性是否为多值属性，可以使用 -d 参数显示当前属 性值集。如果该属性是多值属性，则此参数的输出会列出多值分隔符。以下是一些使用 xconfmanager 实用程序的示例：5.5、xconfmanager 通过 windchill 外壳程序运行。要打开 windchill 外壳程序界面，可在命令提示符下执行以下命令：windchill shellA、要显示 xconfmanager 帮助，可从 windchill 外壳程序中执行以下命令：xconfmanager -hB、 要显示某个属性的当前设置，可从 windchill 外壳程序中执行以下命令：xconfmanager -d 是一个以逗号分隔的属性名称列表。这意味着可以通过执行一个命令来显示多个属性的当前设置。C、要更改属性值，从 windchill 外壳程序执行以下命令：xconfmanager -s = -t -p窍门：请使用属性文件的全限定名以确保能够准确地参考该文件。如果确定 xconfmanager 已知的属性文件中只有一个含有该属性，则可以省略-t 参数。当为某个属性文件以外的新属性设置值时，必须包含 -t 参数，以命名欲将属性添加到其中的属性文件。要为在 wt.java.classpath 属性中指定的 Windchill 类路径添加新类路径条目，请从 windchill 外壳程序执行以下命令：xconfmanager -add wt.java.classpath=d:MyLibariessomelibrary.jar -p值 d:MyLibariessomelibrary.jar 将被添加到有序集的末尾。您不必指定分隔符 $(path.sep)，因为 xconfmanager 会自动将分隔符添加到属性值。窍门：先前的示例命令并未在 -t 参数中包含目标文件，这是因为已知该属性仅存在于 perties 中。5.6、格式化属性值的原则下列指导原则将有助于确保使用 xconfmanager 时在命令行中正确设置属性：5.6.1、如果要指定一个属性，其值含有可能被外壳程序解释的字符 ( 如空格和特殊字符)，可使用当前外壳程序的适当技巧进行转义。在 Windows 系统中，可以通过使用带双引号的自变量在值中包含空格，或者也可以使用 将空格字符转义。例如，可使用以下两种方法之一：-s wt.inf.container.SiteO=ACME Corporation-s wt.inf.container.SiteO=ACME Corporation在 UNIX 系统中，可以使用双引号，或者也可以使用 将空格字符转义。例如，可使用以下两种方法之一：-s wt.inf.container.SiteO=ACME Corporation-s wt.inf.container.SiteO=ACME Corporation5.6.2、 在许多 UNIX 外壳程序中，可以使用反斜杆 () 将下列字符转义为文字。大多数情况下，在文件路径中使用正斜杆 (/) 是一种很简单的方法，可以在不需知道复杂的外壳程序命令行转义规则的前提下指定路径。5.6.3、在 UNIX 上，外壳程序通常将美元符号解释为变量前缀。要设置含有美元符号的属性值，请将自变量用单引号括起，以使外壳程序不会解释它，或者也可以使用反斜杠将美元符号转义。例如，可使用以下两种方法之一：-s wt.homepage.jsp=$(wt.server.codebase)/wtcore/jsp/wt/portal/index.jsp或-s wt.homepage.jsp=$(wt.server.codebase)/wtcore/jsp/wt/portal/index.jsp除了需要转义某些自变量以使命令行外壳程序不误译它们之外，您不必转义其它值以与 XML 或属性文件的语法兼容。xconfmanager 会根据需要自动转义属性名和属性值。6、 相关产品6.1.1、WTPartReferenceLink链接WTPartReferenceLink - 使用此类型的链接，可始终将部件链接到主文档。无论用户选择哪种版本的文档，在使用此种链接类型时，始终将部件链接到主文档。即使系统配置为允许用户选择链接类型和文档类型，也是如此6.1.2、WTPartDescribeLink链接WTPartDescribeLink - 使用此类型的链接，可将部件链接到文档的最新小版本，反之亦然。6.1.3、WTPartUsageLink链接用户进行该关联时，将创建 WTPartUsageLink，在部件和部件主数据之间构成“使用部件”关系。6.1.4、WTDocumentDependencyLink链接 在文档信息页面上，通过“相关对象”(Related Objects) “文档”(Documents)，可使某文档参考另一文档。此关系创建了类型为WTDocumentDependencyLink 的链接。6.1.5、WTDocumentUsageLink链接 在文档信息页面上，通过“结构”(Structure) “文档结构”(Document Structure)，可将某文档用作第二个子文档的父文档。此关系创建了类型为 WTDocumentUsageLink 的链接。7、 产品与储存管理员 产品和存储库管理员 ( 也称为产品和存储库经理) 负责管理产品和存储库上下文。产品和存储库管理员的功能几乎相同。产品和存储库管理员控制产品和存储库配置，以及特定产品或存储库应用程序容器范围内产品和存储库团队中的成员资格。他们控制着对产品和存储库信息的访问权限。他们定义具体的生命周期、模板和进程，并监视和管理产品及存储库活动。产品应用程序上下文用于定义新产品模型或实例，并搜集与该产品相关的所有信息。由创建产品时所在父组织授权的产品创建者定义产品上下文。产品将从其父组织上下文中继承模板、角色、用户定义的组以及策略。另外，管理员还可定义产品特定的模板、角色和策略。存储库应用程序上下文用于管理在组织中跨产品和项目使用的标准部件和文档。由创建存储库时所在父组织中已授权的存储库创建者定义和管理存储库上下文。存储库将从其父组织上下文中继承模板、角色、用户定义的组以及策略。另外，管理员还可定义存储库特定的模板、用户定义组、角色和策略。如果在您的环境中已安装 Arbortext 产品，则可以使用产品和存储库上下文来管理动态文档以及通过动态文档创建的已发布文档。8、 包的作用 包是一套有序的对象集合，它们作为一个连贯的整体被开发、审查、交付、更新或管理。一个包中的对象组成一个或多个集合，用以参照能够跨越上下文的特定版本的产品信息。包主要用于交换信息。例如，您可能给制造商发送一个包以获取报价，或者给客户发送一个包请他们审查原型。包还可以进行脱机查看，使无法访问Windchill 的人员也可以查看包信息。包有利于推动与很多供应商和合作伙伴之间的信息交换，使您可以跟踪一些信息，诸如谁在何时发送了哪一个版本的产品信息，何时需要回复。要能够在产品或存储库中使用包功能，必须先为该上下文启用包9、 团队 要管理团队，需要了解 Windchill 中使用团队的不同方式。创建业务对象 ( 例如：部件和文档) 时，将创建唯一的团队作为其自己的对象，并将该团队与业务对象相关联。此团队包括了团队、生命周期和工作流模板中的所有角色。角色被映射到最终用户；在生命周期和工作流模板中可为参与者定义专用访问权限。9.1、在上下文级别中，管理员可创建特定于特殊项目、存储库、项目群或产品的上下文团队。每个上下文团队标识特定项目、存储库、项目群或产品的成员并将这些成员分配给上下文中已建立的角色。每个上下文团队都可由本地团队、共享团队或本地团队与共享团队组合构成9.2、 承担者 是指单个的用户、组或组织。9.3、角色是可由某个承担者完成的功能。角色映射到参与者。定义团队时，可使用预定义角色的列表。9.4、 操作者是指在特定业务对象上下文中执行特定操作的用户。目前，“创建者”是定义的唯一操作者。9.5、参与者是一个承担者或操作者，已经将其映射到团队中的特定角色10、上下文团队可包括以下内容之一：10.1 、本地团队。这是一个在创建应用程序上下文时建立的团队，在上下文中进行管理。10.2、 共享团队。此团队在组织上下文中维护，然后在创建应用程序上下文时选定。不能将共享团队添加到现有应用程序上下文中。上下文团队中只能有一个共享团队，而且该共享团队不能从应用程序上下文中修改。对共享团队的修改会影响使用该共享团队的所有上下文团队，而且修改是在组织上下文中完成的。11、本地团队和共享团队。要使用某个共享团队，该共享团队必须在创建应用程序上下文之前可用。如果在创建上下文时选择一个共享团队，则该共享团队的属性将决定您是否可以将本地团队成员添加到该团队：11.1、如果选择的共享团队可被扩展为允许本地团队成员，则在创建应用程序上下文时，您可以选择允许以本地方式添加角色和成员。11.2、 如果选择的共享团队不可扩展，则您不能选择允许以本地方式添加角色和成员。如果上下文团队仅包含一个本地团队，或者是一个具有本地团队和共享团队的团队，则您可在应用程序上下文提供的“团队”(Team) 页面中，通过添加和删除角色、用户和用户定义组来修改本地团队。可使用为您的组织或上下文预定义的任何角色定义本地团队，或定义上下文所特定的新定制角色。然后，您可以邀请成员参加本地团队中的一个或多个角色。本地团队中的用户在他们所参与的每个上下文中可能具有不同的角色。在一个上下文中用户可能是管理者，而在另一个上下文中则可能是一个成员。共享团队中的用户在所有上下文中角色均相同。如果为特定应用程序上下文建立的团队是不可在本地扩展的共享团队，则整个上下文团队只能在组织上下文中修改。作为将现有应用程序上下文另存为一个新应用程序上下文或上下文模板这一操作的一部分，您可以在另一个应用程序上下文中重新创建一个已建立的上下文团队 ( 如适用，该团队可以包含本地团队和共享团队)。使用一个在其中命名了共享团队的上下文模板时，该共享团队必须在此模板可用于创建新上下文之前在组织上下文中可用共享团队共享团队包括一组角色以及添加到这些角色的成员。共享团队是在组织上下文中通过“团队”(Teams) 页面创建的，它可作为上下文团队用于从组织上下文创建的多个应用程序上下文。例如，假定在“自行车公司”组织上下文中，已创建了一个名为“产品演示团队”的共享团队。在“自行车公司”组织上下文中工作时，如果用户创建应用程序上下文 ( 如产品和项目)，则可以选择此共享团队。如果创建应用程序上下文的用户是其它组织上下文的成员，则“产品演示团队”不可用。注意：如果创建应用程序上下文时未启用任何共享团队，则应用程序上下文的创建者将看不到“共享团队” (Shared Team) 字段，而且所创建的团队为本地团队。共享团队不可在创建应用程序上下文之后添加。12、出厂设置约束条件 出厂设置属性约束条件可在属性上设置约束条件以确定它们是否可编辑、可见，以及限制其值和基数。可对“创建”和“更新”操作应用“不可变” (Immutable) 和“隐藏”(Hidden) 约束条件。EPM 文档还可应用于“EPM 上载”操作。例如，如果某个属性上的这些约束条件之一应用于“更新”操作，则该属性将仅在编辑类型的实例时适用。如果某个属性上的这些约束条件之一应用于“创建”操作，则该属性将仅在创建类型的新实例时适用。将“EPM 上载”应用于“EPM 文档”时，不能通过 Pro/ENGINEER 应用程序下载 CAD 文档 (EPM 文档)，除非设置了以下属性：wt.services/svc/default/wt.epm.attributes.EPMAttributeDelegate/PROE/wt.iba.value.IBAHolder/0=wt.epm.attributes.EPMAttributeDelegateWithWarnings/singleton通过使用 xconfmanager 工具设置 perties 文件，该参数将被忽略，上载也将成功。事件控制台将显示错误消息。下表提供了有关出厂设置属性约束条件的信息：13、生命周期Windchill 支持以下两种类型的生命周期：基本和高级。基本和高级生命周期之间存在着显著的用户可视差别。主要的不同之处在于对象的团队定义设置、用于受管理对象的工作流进程以及在创建和修订对象时的系统性能。使用基本生命周期可为核心创建和修订操作提供改善的性能。可指定生命周期是否包括生命周期定义的某些方面。这对于团队定义以及在Windchill 中使用工作流进程尤其有用。创建基本生命周期时，只定义生命周期模板、状态和转变。创建高级生命周期时，可以定义附加功能，其中包括：阶段信息、团队、工作流进程和升级条件。13.1、基本生命周期创建基本生命周期时，需要定义以下内容：生命周期属性，包括名称、位置、可选说明和生命周期应用的对象类以及是否启用生命周期。13.1.1 用于定义生命周期的阶段和关口。13.1.2 转变，通过从当前 ( 所选) 状态到生命周期模板内的任何已定义状态来定义。基本生命周期设计为使用在任何应用程序上下文中定义的上下文团队。基本生命周期不包括工作流进程定义并依赖于具有变更管理、路由或升级进程的工作流进程定义。此类型的生命周期适用于大多数 Windchill 对象，因为基本生命周期在创建和修订对象的过程中性能得到了改善。创建对象 ( 如部件或文档) 及选择团队模板和基本生命周期时，所做的团队选择不起作用。基本生命周期不会利用团队或工作流13.2高级生命周期创建高级生命周期时，需要定义以下内容：13.2.1、生命周期属性，包括名称、位置、可选说明和生命周期应用的对象类以及是否启用生命周期。13.2.2、 用于定义生命周期的阶段和关口。13.2.3、 每个生命周期阶段的角色，如“审阅者”或“工作流负责人”。可将这些角色直接映射到用户或用户定义的组，但最常见的情况是映射到团队角色或操作者。13.2.4、 与每个生命周期阶段相关联的角色充当者的访问权限。13.2.5、 要与每个阶段和关口相关联的工作流进程。13.2.6、 在每个关口应该满足的升级条件。13.2.7、 转变，通过从当前 ( 所选) 状态到生命周期模板内的任何已定义状态来定义。注意：在“生命周期管理器”(Life