mes不是一个部署完就不需要再开发的软件，特别是在精密加工行业，例如半导体。在工艺不断进步的时候，一个可以配合工艺改良，生产效率提升的mes才是一个企业成功的关键。当然，成熟的产品，已经可以提供很多现成的功能，但只适合一些需要快速投入生产，跟着领头羊的快速跟进者（也就是行业所说的fastfollower），要是想要和头部企业进行竞争，那就要走一条不一样的道路，不能只是墨守成规。
mes的开发是一个很有意思的课题，首先第一个要探讨的问题是，把业务逻辑写在客户端还是服务端？
首先差别到底是什么？
把业务逻辑写在服务端的好处是，可以回滚（rollback），例如同时处理20个igbt模组（或25个晶圆）的trackin或edc，如果第x个物料不成功，每一个物料都不会trackin。反之，写在客户端，只能一个一个的trackin，当第x个物料失败时，其他的处理起来就比较麻烦了。这也是一般mes都提供dispatch material和dispatch materials（有s代表多个）的原因。
如果是这样，为什么还有人在客户端写业务逻辑呢？
当年factorywork 2.x至3.x的开发，服务端的代码是用c写的，但客户端则是用vb6写的。当时就有两个派系，欧美日系都是用c来开发的，而亚洲派系则是用vb6把业务逻辑写到客户端中。亚洲工厂往往比欧美工厂更快速的上线，因为vb6做为rad（rapid application development，快速应用程式开发工具，低代码的祖先)是一个最佳的工具，winform到今天依然阴魂不散的在.net世界持续着。但是在实现复杂的逻辑和联动上，客户端的代码是很糟糕的，时常会出现物件的状态在没有做完业务逻辑之前就改变了。
还有一个更现实的原因就是服务端的代码不好除错（debug），要一个不懂unix的人去用xdb，我估计会要他老命。就算是现代不用unix的mes，例如camstar，cm等，要做remote debuging也不是一件容易的事（把visual studio挂到一个process上），很多年轻的工程师是很难去接受的。
近年来，大部分客户端都是用html5 javascript/typescript去实现的，这样其实让客户端的代码更加难写（说实话，网页端真心做不了太复杂的业务逻辑）。
一般上实施mes要有两组人，一组人做客户端（html5），一组人做业务逻辑（jave/python/c#）。
这也是当年factorywork的用户，很多亚洲用户只用vb6的原因，不需要两组人，一组可以了（其实我觉得是被系统整合商带偏的，vb6的开发便宜，可以多赚一些）。
不管如何，mes的开发和eap有很大的关系。eap需要用到mes的不同接口才能代替人为的操作，把手动的事变自动了。
这里要聊一下，什么是好的mes接口？
早期的mes接口都是客制化的，例如factorywork用了著名的mbx（或是dmbx），部分用了tibcorv。通常客户一定要使用厂商提供的dll，才能和mes进行沟通。一直到webservice开始流行的时候，大家才能够直接送xml格式的资料去和mes进行沟通。但实际上，直接用webapi去和mes沟通的其实是很少的，没有人会花时间去建一个50个元素的json（json恶梦，其中80%的元素是null），依然需要厂商提供库（.js,.dll等）。
以下是一些典型的mes接口的应用（例如loadmaterial和createrecipe).
loadmaterial：
复杂的接口
简单的接口
createrecipe：
复杂的接口
简单的接口
大家可以注意到好用的mes接口，一行就完成了，但是不好的mes接口需要客户写一堆的代码。在如今这个‘’家家都有低代码平台‘’的年代，这更是一个很重要的选型考量指标。别意外，依然有厂商提供很难用的接口和使用方式。
我们一直在思考，如何要让开发人员的效率提高，让开发人员更不容易犯错，不断的优化接口是努力的方向之一。
