Camstar技术简单介绍

以下内容基于Camstar 6.9版本，在之后的版本中，实现方式有所改变，基本处理逻辑没有变化

Camstar 数据流向图

Camstar Portal：Camstar 的Portal网站，位于Camstar 安装目录下的Camtsar Portal目录，http访问地址为“服务器地址/CamstarPortal”，这是一个C#的网站项目，可以用VS打开。

Camstar WCF Service：位于Camstar安装目录下的Camstar WCF Services目录，是一个C# 的WCF Service 。

InSiteProxyService: 位于Camstar安装目录下的InSite Server目录，是InSiteXMLServer的代理服务。

InSiteXMLServer: Designer服务真正的执行位置,位于Camstar安装目录下的InSite Server目录（猜测：可能利用mdb文件的内容运用类似反射的技术来构建Designer对象，Method的执行过程也可以通过自定义函数进行一定程度的了解）

下面进行数据流向图中执行内容的介绍

Camstar Portal

首先获取页面控件上的数据(如何获取控件上的数据后面再介绍)，然后通过Camstar.WCFClient.dll和Camstar.WCFClientBase.dll访问WCF Service 间接执行InsiteXMLServer（也就是执行designer的内容），接受WCF Service返回的结果信息，显示到Portal页面。

备注：通过了解WCF Service的内容，我们可以知道在哪些情况下，更新designer需要勾选Generate WCF Service

控制台程序通过引用Camstar.WCFClient.dll和Camstar.WCFClientBase.dll以及添加WCF的配置信息可以非常方便调用WCFService，配置文件请根据Camstar Portal目录下的Endpoint.config文件以及WCF Service的IP地址自行修改。

WCF服务可以分为四大类：分别是Designer服务，query服务，Label服务以及Authentication服务。

Designer服务中常用的又分为两类：shopfloor，maintenance；shpfloor是指车间操作的服务，Maintenance是指建模的服务。WCF Service Object与designer的服务中的字段是一一对应的。下面提供调用Designer服务的实例。

执行shopfloor服务

例如执行MoveStd

这是一个简单的示例，上面的代码将执行designer的MoveStd服务。

上图所示是获取MoveStd服务中Container的下拉选择值的代码。

执行服务所需要的数据是与Designer的服务中定义的字段相对应的。

Service实例还有许多其它的方法，例如RollBackTransaction以及与Designer中服务的Method一一对应的方法等等，具体使用方式与效果。

执行Maintenance服务

例如执行MfgOrderMaint

1.2.1新建工单2019041101

1.2.2将工单2019041201的名称改为2019041101

在Camstar.WebPortal.WCFUtilities.dll中提供了更加通用的用法如下图所示，耦合度更低，这些方法在ES_ModelingBModelingBase.cs中有使用。

Query服务

Lable服务

更加详细用法请查看Camstar.WCFClient.dll和Camstar.WCFClientBase.dll。

Camstar WCF Service

WCF Service 将Portal传递的WCF Service Object生成XML，发送到InSiteProxyService,同时负责将InSiteProxyService返回的XML数据解析为WCF Service对象，WCF Service也就有Log功能，默认是关闭，可通过配置文件进行配置。

代码片段：

生成XML

解析XML

InSiteProxyService

InSIteProxyService主要通过控制启动多个InSiteXMLService进程，来响应并发的XML请求，对XML数据不会进行处理，占用2881端口，并不会执行designer服务，也不会处理XML，但会进行XML的转发，主要是进行性能控制，通过一定的规则（规则可通过·InSiteProxyService.exe.config文件进行简单的配置）动态控制InSiteXMLServer进程的启动和销毁。

InSiteXMLService

这个程序实际上执行的是designer的服务，与数据库进行交互，因此我将使用designer内容来介绍这个程序。

Designer中的Configurable data objects（简称CDO）类似面向对象编程中的类，所有CDO间接或直接继承BaseObject，BaseObject中定义所有CDO通用的Field和Method，NamedDataObject（简称NDO）继承自BaseObject；而NamedDataObject又是所有NDO的父类，在BaseObject的基础上新增了所有NDO通用的Field和Method。

在shopfloor service中定义了所有shopfloor服务通用的Method，而在shopfloor下添加的服务都会继承shopfloor的所有field和method。

正因为Designer的CDO具有这些特性，我们完全可以将Designer认为是一个面向对象的MES系统。

根据上面介绍的WCF service的内容，我们可以知道整个MES系统对外开放的类就是Service以及service的子类，而其中Maintenance就是建模NDO和RDO对外提供的接口，每一个NDO或者RDO对象都拥有一个唯一的maint服务，通过这个maint服务我们可以新增修改删除对应的NDO或者RDO；

Shopfloor就是所有车间服务对外提供的接口，例如MoveStd服务，Start服务等等都是shopfloor的子类。

而所有service的执行都是从上往下执行下图所示的Event。

我们完全可以通过查看每个service类（Service CDO）的field和method，来了解每个服务所做的事情。

但designer的信息，可读性很差。先简单介绍下，具体的得慢慢了解。

BaseObject：所有CDO的父类

Constants：声明常用的枚举类型字段，可以在其它CDO中，通过”Constans.字段名称”使用（主要用于shopfloor service），类似C#中的static修饰的字段。

Enumeration下：定义所有的枚举类CDO。

NamedDataObject下：通过名称来区分唯一性的建模对象，一般NDO都会设置对应的数据库，类似C#的实体类，与数据库的表具有映射关系。例如产线MfgLine，工单MfgOrder，工厂Factory等都是属于NDO。

RevisonBase/RevisionObject下：简称RDO,通过名称加版本号来区分唯一性的建模对象，与NDO类似，也属于实体类，与数据库的表有映射关系，因为它具有版本的性质，因此使用RevisionBase定义对象名称，RevisionObject来定义不同版本，这两个类是一定同时存在的。例如产品Product，ERPBOM，工作流workflow等都是具有版本性质的建模对象，因此都继承自RDO中。

NameDataObjectChanges：This CDO holds the changes that are being made to the Object until the user decides to make them permanent。上面这是CDO的描述（我的理解是：防止用户直接修改NDO本身，先在changes中保存需要修改的值，然后再将信息记录到NDO去，或许是出于安全性考虑，或许是减少数据的传输。

RevisionObjectChanges：同上。

Subentity：定义列表字段

SubentityChanges : 同上

Container：抽象的概念，上面所说的NDO，RDO，大多数就是为这个对象服务。它代表实际生产中的某一个产品或者某一个批次，它可以实际存在，也可以是虚拟的。

CurrentStatus：记录container的当前状态，如位于哪个工作流，哪个工序等等，

Service：定义所有的服务，其中Maintenance服务对NDO,RDO对象进行修改，Shopfloor服务对container、Resource等进行操作。

HistoryMainline：历史记录表，记录一些简单历史，哪个用户在什么时候执行哪个服务等等一些简单的信息。

还有一个需要特别指出的是，Designer默认将shopfloor服务的更加详细的历史保存在ServiceHistorySummary下（通过继承ServiceHistorySummary来定义服务对应的历史HistorySummary），当这个历史记录满足不了我们的需求，我们可以扩展HistoryDetails，

HistoryDetails默认是在ServiceHistoryDetails CDO下·。

Event与Method

Designer中任何一个CDO所包含的所有Method，均在CDO本身的Events和当前CDO的Field的Events中；所有method和Event都可以被继承，被重写，暂时没见过重载的用法。

例如：Shopfloor中就定义了大量Method，并且被绑定Event的方法调用，用来做创建历史等等操作。CDO的Field也可以通过Event绑定Method，如图，常用OnGetValue，SelectValueEx

总结：designer设计的是一个面向对象的MES系统，每一个CDO都是一个类，类的字段、方法都可以被继承、重写；NDO、RDO是一些实体类，与数据库直接关联，定义产线、产品、工单、工序、工作流等等类，Container是整个MES系统的核心，是定义实际生产中的一个批次或一个产品（自行理解）等等的一个类，Service（Service以及Service的子类）是整个MES系统对外开放的类，直接或间接继承Service创建一个新的Service，都会生成一个对应的WCF Service，通过访问WCF Service，间接访问Designer中的Service，继而操纵Container、NDO、RDO等CDO的数据。

介绍Designer的界面

CDOs是Designer的核心

在CLFs中创建method的内容，供CDO和CDO的Field使用

Fields中包含所有的字段信息

创建新的CDO，会自动创建Object类型的字段信息，当在CDO使用某种类型的字段时，就是通过选择Fields中的信息实现。

Tables中是所有表的信息

绝大部分与CDO都有对应关系，table中column也与对应CDO中的字段有对应关系。

Functions是理解Designer的设计的MES系统所执行的内容的关键

任何CLF都是由Function组成，Function的功能就是进行逻辑控制、数据处理以及创建CDO对象等，如if，else，foreach，FilterList，CreateCDO等，Function以一种特殊的方式实现，高级编程语言的逻辑控制和处理，如果感兴趣可以看看自定义Function的开发，Function开发原理是com组件开发，网上有资料。

Queries定义所有的查询语句，

这些查询语句有简单的SQL查询，也有需要利用占位符原理处理的SQL查询，还有一些更加特殊的用法，专属于Designer的查询语句，在使用的时候会进行更加特殊的处理，在查询语句中的$MfgOrder.Qty会被替换MfgOrder
CDO对应的Table中Qty字段在对应的column，还有一种用法是@fieldheader:name=”OrderStatus”:label=MfgOrder_OrderStatus，主要用于做查询语句中的别名）。

Labels

键值对，在CDO中可以使用，在portal显示控件时也会用到，portal控件以及service里面的使用实例，例如ErrorLabelName的赋值。