本文主要谈的是K2与SAP的整合的概览，它的定位是参考和指引，没有深入讨论具体的技术细节。如果大家有兴趣的话，请参与到相关话题的讨论中。
应用系统整合，是企业BPM平台的重要组成部分之一，就是：“流程自动化只是BPM的一部分，BPM还包括应用系统整合、报表等”。
就技术面而言，我们需要了解K2与SAP系统整合的方式、原理和每种方式的优缺点：
l 整合方式1：用中间数据库的方式，把需要交互的数据保存在中间数据库，双方按协定定时取和写就好。
Ø 优缺点：不用多说，反正就是写代码，最原始的方式。
l 整合方式2：通过Web Service。
WebService是业界的标准，微软、IBM、Oracle、SAP都支持，包括如XML、SOAP、Web Service - * （WS-Policy, WS-Inspection, WS-Notification, WS-I, WS-Federation, WS-BusinessActivity…），并且SAP也提供了SAP Netweaver（SAP 最新的集成应用平台），本身就是一个支持WebService的整合开发平台。
注：这也往往成为竞争对手与我们PK的一点“大家都可以通过web service整合SAP，为什么选择K2？”。就技术面来说，答案包括：K2还有整合方式3、4等多种选择，并且在集成的性能、可用性、功能及成功案例上更具优势。
Ø 优点：简单，相应诸位都用过Web Service。
Ø 缺点：简单（同一个词可以有N种不同的解释，中国文字的强大和灵活性可可见一斑，[突然想到，K2也很强大灵活J]）。随着Web Service规范的不断发展和成熟（WS-*），web service在安全、加密、事务等都得到了增强，应用也越来越广泛，但Web Service存在的效率等先天性的劣势：如只能用XML的序列化方式等。（关于这个话题，请大家参考WCF相关资料，WCF值得我们花时间了解，[自由地通过配置的方式选择协议、编码方式等]）
l 整合方式3：通过中间件与SAP整合，就微软平台而言我们推荐使用BizTalk，当然也可以选择如TIBCO等类似的产品。
Ø 优点：
K2直接提供了BizTalk的Adapter（适配器），我们能与BizTalk做native（原生）的整合，而BizTalk产品内置提供了与SAP的整合（整个BizTalk 2006提供了200个免费的Adapter，可以与业界主流产品整合，如PeopleSoft等）。请注意：Native（原生）这个词很重要，几乎所有的产品都可以宣称能与第3方系统（SAP, LOBs）整合，其实很多是通过写代码的方式完成的；而Native意味着，在产品中已经提供了相关的整合模块，并且该整合的模块已经经过市场验证（如性能、容错性等方面），是成熟的，往往这一点是上了SAP系统的大企业最看重的。
BizTalk的定位为企业EAI工具，BizTalk会详细记录K2与SAP交互的信息（数据交换的时间、结果、数据包、数据的映射、安全管控机制...）。通过它，我们能对全部整合过程中发生的所有细节做到：有据可查、实时可查、有实为证、。
当然，通过BizTalk也使得我们的BPM平台能与ESB（Enterprise Service Bus）相互配合，使K2能与更多的系统整合（这点不在本文的讨论范围内）。
Ø 缺点：
购买BizTalk需要钱（虽然从顾问的角度来说，长远这钱是值得投资的）。
你需要精通BizTalk的人。
l 整合方式4：K2 Connector。
K2 Connector Beta2已经推出，大家已经在虚拟机中通过VPN连接到公司的SAP测试环境动手做实验，相关的video已经上传到GCSPS。
Ø 优点：K2 Connector对开发者而言依然是SmartObject的技术，我们不需要引入第3方工具就可以与SAP集成，减少了系统的复杂度。
Ø 限制：
SmartObject是实时的（非异步），这意味着，我在通过SmartObject对SAP进行操作的时候，必须等待SAP的返回结果，这对于应用会有一些的限制；而BizTalk是异步的；如果在应用中我们有Long Term Transcation的需求，也许需要考虑BizTalk，或者通过代码自己实现你的长时间事务支持。
使用K2 Connector，BizTalk提供的一些特－性详细记录K2与SAP交互的信息（数据交换的时间、结果、数据包、数据的映射、安全管控机制...）－必须自己实现。
更深入的讨论：
l 与SAP的整合一定需要SAP顾问公司的参与，这其实是所有整合的动作发生的时候大家都需要注意的。参与的相关公司都必须要有一个明确的分工和界线划分，之前通过公用的接口（可能是中间数据库，可能是BizTalk...）定义自己的职责。
l 与SAP的整合经常会用到SAP .net connector（台湾TPV就是没用BizTalk直接用它了），就本质而言它提供了一套在.net环境下的访问SAP的API，通过它我们可以访问SAP中的BAPI等对象，K2 Connector就底层而言也是如此（公司收购了一家做SAP .net connector的公司）。
如同各位可能已經知道的，k2 blackpearl並沒有正式提供一個功能用以刪除已經運行完成的流程實例(process instances)。你只能刪除正在"運行中"的流程實例。 這背後的原因是由於為了要確保企業符合財務審查與會計原則 (例如沙賓法案)， 流程的歷史審查是非常重要且不應該輕易可以刪除的 。
然而在一些特殊的狀況當中，我們還是有可能需要從資料庫中移除一個確定未來不會繼續需要的流程(主要是刪除該棄置流程的流程實例)。這樣也可以幫助降低資料庫的大小，為了實現這樣的功能，我撰寫了一個簡單的預儲程序(stored procedure )可以允許開發人員從K2 Log資料庫中，移除所有已經結案的流程實例。這預儲程序的開發是基於K2 即有的刪除正在運行流程的功能。
這個預儲程序做了底下幾件事情：
- 依照流程的完整名稱，移除已經完成的流程實例。例如： "Finance\Purchase Request"
- 檢查是否還有任何正在運行中的流程實例。如同我先前提過的，這個功能是用來刪除"廢棄不用"的流程所遺留下來的流程實例，所以該流程不應該會有任何運行中的流程實例。
在這篇貼文的最後附上了兩個版本的預儲程序，一個是給 K2.net 2003 ，一個是針對 K2 [blackpearl]。同時這兩個預儲程序也已經針對 K2.net 2003 SP2a和K2 [blackpearl] SP1進行測試。這兩個預儲程序應該可以正常的運作在更新的K2版本當中，只要lProcInstRemove沒有任何的修改。(lProcInstRemove是一個K2內建的預儲程序，你可以K2 Log 資料庫中找到)
儘管我已經在我的環境當中進行了完整測試與驗證，但請依舊在對正式環境執行這預儲程序前，先針對資料庫進行適當的備份。
注意: 這些預儲程序並不被K2或我本人正式支援，若不正確的使用或導致任何對系統的危害，我個人與K2均無法提供任何形式的補償。這些預儲程序的使用前提是假設您對SQL 具有相當程度的專業知識，因此倘若發生了任何問題或任何不測，請不要為已經無法挽救的局面後悔難過 :)
同時我也建議，在執行預儲程序前先將K2伺服器離線，特別是當您的K2Log (K2.net 2003) 或K2ServerLog (K2 [blackpearl])資料庫中有非常多的記錄時，更需要如此。因為在伺服器運行的階段執行這個預儲程序，特別是在具有大量流程實例記錄的伺服器上時，可能會導致deadlock 或是 timeout。
你可能也會需要在執行上述預儲程序後，接著執行DBCC SHRINKDATABASE 命令以取回先前被刪除的無效流程實例所佔用的磁碟未使用空間。
我期待你發現這個域除程序的好用之處。Cheers。
這篇文章中介紹一個簡單的小技巧，來提升伺服器端的效能。
在底下幾個位於C:\Program Files\K2 blackpearl\Host Server\Bin資料夾中的 config files裡面，您可以進行一些手動微調，以提升伺服器的效能：
- DependancyService.config
- SourceCode.Categories.Runtime.config
- SourceCode.EventBus.ClientRecorder.dll.config
- SourceCode.Workflow.Runtime.Management.config
- SourceCode.Workspace.Runtime.config
在這些config files當中，請搜尋 ConnectionString 關鍵字. 這是用來存放(設定) 針對資料庫的SQL Server連線字串位置. 請將連線字串中，關於pooling 的部分，從False改為True.
如果你不明白上述動作所造成的改變或影響是什麼，我想你先在進行修改前，把這些config 檔案進行備份會是一個比較好的主意。:)
接著，重開Host Server 即可讓這些修改發揮影響。
效用很快發生! 你應該會在重啟動之後，發現伺服器變得比較快了。請注意，這些校調應該已經在即將釋出的0803版本的blackpearl當中被修正了(意即，在0803版本當中您不需要進行這些調整，同時0803版本中還增加了其他的修正與效能增進).
背景
Colin Murphy、Gabriel Malherbe和我在3月份举办过一场关于SmartObject的研讨会，对我们而言，这是一次十分而有趣和必要的讨论，因为在此之前我们3人已就相关问题有过多次的电话交流，我们希望能更好地理解SmartObject及它在企业架构中的定位。我之前写过一篇blog文章（没有发布），认为SmartObject可以被认为是SOA的一种实现，这种看法引起了一些争议和不同意见。之后经过我与一些同事的继续研究，现在我的观点有所改变：
-
SmartObject不完全等同于SOA，虽然它实现了很多SOA的理念－自我管理、安全、日志、可被发现、可维护、异常处理、扩展性、可行性、事务支持、互操作性（计算机之间的沟通能力）、可测试等。
-
也许我们可以认为SmartObject达到了SOA实现成熟度的第2级（总共有5级）；
-
我同时对“SmartObject对当今的企业和组织而言已经足够好”这个观点有所保留，它的发展空间还很大；
-
与此同时带来的挑战是：企业可能会投资实现更高成熟度的SOA，而不仅仅是SmartObject。
什么是SmartObject，以下是我们对SmartObject的一些见解：
SmartObject面世前后的差异
在K2.net 2003中，当我们要同外系统交互数据，我们必须在event生成并修改代码。在Blackpearl中，实现这个功能，我们不需要生成代码了，我们实现的方式是“声明”－告诉工具我们要通过SmartObject与外部系统交互。
在K2 Blackpearl中，我们只需要简单的以拖拉的方式就可以通过SmartObject与外部系统交互，不需要代码。
K2 [blackpearl]关于SmartObject的解决方案
K2 SmartObject在企业架构中的定位
下图引自于我在2007年11月某次研讨会上用到的材料，当时为了理解SmartObject我做了一些深入研究，这张架构图目前还经常在其它地方被引用。
SmartObject在K2 blackpearl扮演着流程数据提供者这个非常关键角色，整个K2 blackpearl平台中SmartObject无处不在。关于SmartObject和ServiceObject，有2点你是必须清楚的：
SmartObject Service：
SmartObject：
-
一个类的定义：它的成员（或称为数据）映射到SmartObject Service提供的方法
-
SmartObject能以可视化的方法在K2流程定义中使用，与外部系统交互
-
SmartObject提供了API，能被企业架构中的其它层面方便地使用
最后，SmartObject是数据访问层（Data Access Layer）的一种实现，SmartObject允许你定义和使用自定义的数据提供程式并通过SmartObject的统一界面向外提供功能。
K2 [blackpearl]产品中提供的SmartObject Service
K2已经提供了如下开箱即用（out of box，OOB）的SmartObject Service，包括：
Blackmarket上的SmartObject service
Blackmarket是SourceCode公司以类似于微软CodePlex模式运作的项目（open source，源代码管理、wiki、讨论组、项目分类、支持RSS订阅…），它给开发人员提供了分享代码的公用空间－http://k2underground.com/k2/ProjectLanding.aspx。目前已经有如下的项目：
-
Dynamic SQL Stored Procedure Service－它封装了SQL Server中存贮过程，我计划在今后的项目中大量使用它，因为我想通过使用存贮过程而不是直接使用数据库中的表和列，以达到更好的灵活性和扩展性
-
Dynamic SQL Services
-
SharePoint Users in Groups ServiceObject
-
Office Communication Server Service－整合了OCS，通过它可以发送即时消息
-
Dynamic WebService Service－动态调用web service
-
-
Dynamic SmartObject Service－通过schema组合现有的SmartObject Service生成新的SmartObject Service，效果类似于面向对象中的继承和组合
随着越来越多的人在blackmarket中贡献，将会有越来越多的SmartObject Service。
结论
以下是我在长期研究和讨论SmartObject后的结论：
-
SmartObject使你能更快地提供和实现K2的解决方案。比如，通过它我可以立即使用到AD、SQL Server等不同外部系统中的数据，实施时间大大缩短。从前我们实施项目的时间可以是以星期为单位的（因为需要大量时间构建数据存取层，这意味着大量的代码生时间），现在我们的实施时间以天为单位就可以了。我可以用拖拉的方式在line rule、succeeding rule、preceding rule、email、destination rule、任何可配置的event向导中使用SmartObject，我甚至不需要代码就可以在流程中与外部系统整合。当然我也可以通过C#代码去使用SmartObject，SmartObject API非常清晰简明易懂，基本与使用.net标准的System.Data命名空间类似。
-
SmartObject的另一伟大之外在于，它使得业务人员在定义流程的时候也可以通过它与各种外部系统交互，而业务人员无需也不需要知道后面的细节（数据来自于哪个外部系统、交互数据的方式…）
-
目前在定义业务规则中使用SmartObject需要留意一个问题：SmartObject的方法可能返回非期望的值（无效的值），原因可能是业务人员在提供SmartObject方法的参数中包括了错误的值。
-
在项目的初期或POC中，把数据存贮在SmartBox中是OK的，但长远来说，我们可能不希望把数据存贮在SmartBox中。原因可能是：我们希望对数据的schema有更多的控制权（SmartBox是自动生成的，无法手工控制）；我们（或客户）可能不希望所有流程中的数据都存贮在同一个SQL Server数据库中。
-
不要认为有了SmartObject就可以代替数据仓库（Data Warehouse）。没错，SmartObject提供了CRUD的操作，并且操作对象可以来源于不同的系统（SQL Server, Oracle，AD…）。但出于性能的考虑，如果我们在SmartObject中直接对两个数据量非常大的数据源进行了连接（join）匹配操作，我们失去指定join时所使用的Index的机会，这对性能可能会有极大的影响。所以在特定的场景下针对特定的需求（尤其是性能上的需求），让
SmartObject从数据仓库中取得数据是更好的做法。
- SmartObject与VS2008中的LINQ技术会在功能上存在一定的重复，作为微软提出的对象实体和数据服务标准的LINQ会与SmartObject形成某种竞争的关系。很多开发人员会在server event、中间层和UI层直接大量使用LINQ。我个人并没有大量使用LINQ，但我知道它是一种很棒的对象查询语言（Object Query Language）和对象数据映射（OR Mapping）技术。但SmartObject有一点是做得非常出色的：它提供了集中管理和发布的功能，这对于企业架构非常重要。
這一回要準備一個真實上線的系統，做一個報銷流程。要在最短的時間內完成。一開始，我在自己的電腦上設計InfoPath表單，建立Schema是花了些時間，大概就十來分鐘。再來是拉表單的畫面，這就多花了些時間，以公司的報銷表單為基礎進行設計，東拖西放的也花了快半個小時。表單設計完畢，就要準備資料來源了。在最初的構想中，只打算上流程，基礎的資料就寫寫Web Service去銜接就行了。但是轉念一想，決定用SmartObject。
於是重新換了VPC(原本是用自己的工作站設計InfoPath，再上到一個中文的MOSS VPC上，沒有K2在裡面。換了VPC(BP101)後，我在自己的工作站上用K2 Studio for Visual Studio，很快的設計了幾個SmartObject(總共有六個)，包含員工資料、貨幣參照資料、作業中心參照資料、費用類別…。這個構思和設計的時間大概花上半小時左右。接著再花上十來分鐘建立各個SO的維護頁面，放入基礎的資料。這些頁面都不是為了應付 POC，所以在格式上、排序上都做了安排。到目前為止大約經過快兩個小時，只能說有維護的畫面和InfoPath表單，但還沒有接在一起，看不出最後的效益。
接下來有趣了，按照過去的設計，我要針對既有的六個Table分別撰寫Web service，提供所有必要的Web Method。如果前面我在設計維護頁面時，有將資料存取的功能包裝成類別，那這些Web service