整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
BM Business Automation Workflow是原IBM BPM+IBMCaseManager+IBMECM組合之后的新產品，屬于業務流程自動化產品。下面是登錄Proce Center之后的界面：
Prcoess Cennter
在上圖中可以打開現有的流程，以及新建流程，也可以歸檔流程。下圖我們打開一個流程可以看到以下界面。左側是松耦合的各個功能，右側可以看到各種設置，包括公開的項，以及可以定制主題（界面），以及指定流程應用程序管理員。
設計界面
在下圖中基于每個模塊點“+”號做相應的操作，下圖是“服務”模塊點“+”之后出現的選擇，可以添加外部服務、服務流、Web Service等。
下圖是添加一個WebService服務之后，在“操作”上面點“+”號出現的界面
下圖是可以繼續添加“策略”
我們可以將設計好的流程、用戶界面、服務、數據等復制或移動到其他項目中，可以節省大量的重復工作。如下圖：
下圖是流程設計界面，標準的BPMN2.0標準，在每個流程節點可以選擇如下圖的功能，包括寫JS腳本、調用軟件機器人等。
在用戶界面中也可以設置流程，以及在流程節點自定義各種服務，實現短流程。也就是說當用戶的流程節點調用了這個用戶界面，流程到達該流程節點的時候會自動觸發相應的短流程實現一些服務的調用。
在用戶界面（表單）可以針對添加的控件使用定制各種功能，使用各種服務。
在UI界面時支持下面各種控件，近80個輕量級的響應式組件（HTML5 / CSS3），不依賴第三方。
服務支持：
REST服務
JavaScript
Web Service
支持EJB、JMS、MQ、HTTP
數據庫集成
Adapters
內置文檔管理
支持AI功能，下圖在審批時會有AI提示。
重要的是，IBM現在將上述產品打包進IBM Cloud Pak For Business Automation了，里面包含了下圖的所有授權，以及企業級中間件、數據庫的授權，并支持基于OpenShift部署，也包含了OpenShift的授權。用戶可以購買48vCPU授權，并靈活配置合適下圖中的功能模塊。
期，ActiveReports產品開發組的小伙伴針對大家比較關注的報表功能、常見問題、經典實現，特意準備了一個Demo代碼集合，涉及WinFormss \ ASP.NET \ MVC 多個技術平臺，包含導出、打印、WebViewer、HTML5Viewer、自定義工具欄、自定義搜索等多個具體功能的實現。
下面介紹一下各Demo的功能。
WinForms 加載四種報表：如何在WinForms框架下，加載ActiveReports的四種不用的報表（RDL報表，頁面報表，區域報表基于XML，區域報表基于代碼）。
WinForms 增加導出和打印按鈕：在WinForms框架下，報表展示的工具欄沒有導出和打印按鈕，這需要我們通過后臺代碼進行按鈕的添加觸發事件的編寫。
WinForms 實現靜默打印：通過點擊打印按鈕，直接調用打印機進行報表的打印。
WinForms 綁定運行時數據源：WinForms框架下，四種不同的報表如何進行綁定運行時數據源。
例：WinForms 下的ActiveReports靜默打印實現
使用HTMLViewer：Asp.net 框架下，使用HTMLViewer加載四種不同的報表（RDL報表，頁面報表，區域報表基于XML，區域報表基于代碼）。
使用FlashViewer：Asp.net 框架下，使用FlashViewer加載四種不同的報表（RDL報表，頁面報表，區域報表基于XML，區域報表基于代碼）。
使用AcrobatReader：Asp.net 框架下，使用HTMLViewer加載四種不同的報表（RDL報表，頁面報表，區域報表基于XML，區域報表基于代碼）。
使用RawHTML： Asp.net 框架下，使用HTMLViewer加載四種不同的報表（RDL報表，頁面報表，區域報表基于XML，區域報表基于代碼）。
HTMLViewer增加打印按鈕：Asp.net 框架下，使用HTMLViewer加載報表，工具欄是沒有打印按鈕的，需要手動添加打印按鈕。
HTMLViewer增加導出按鈕：Asp.net 框架下，使用HTMLViewer加載報表，工具欄是沒有導出按鈕的，需要手動添加打印按鈕。
FlashViewer增加導出按鈕：Asp.net 框架下，使用FlashViewer加載報表，工具欄是沒有導出按鈕的，需要手動添加導出按鈕。
定義HTMLViewer 參數面板隱藏：Asp.net 框架下，使用HTMLViewer加載報表，然后自定義工具欄按鈕的顯示和隱蔽。
在HTML5 Viewer中添加放大和縮小功能：使用Html5Viewer加載報表，通過添加放大和縮小的按鈕，進行報表的縮放功能。
例圖：ASP.NET 平臺下 ActiveReports 利用 WebViewer 加載顯示圖片
HTML5Viewer 桌面模式展示報表：在MVC 框架下，使用Html5Viewer進行PC端報表展示，需要注意的點是:
UiType模式： desktop
HTML5Viewer 移動端模式展示報表:在MVC 框架下，使用Html5Viewer進行移動端報表展示，需要注意的點是:
UiType模式： Mobile
HTML5Viewer 連續模式展示報表:在MVC 框架下，使用Html5Viewer進行報表連續模式的加載，需要注意的點是:
設置： renderMode: 'Galley' （連續模式）
HTML5Viewer 凍結行頭列頭展示: 在MVC 框架下，使用Html5Viewer進行行列頭展示，需要注意的點是:
1、設置： renderMode: 'Galley' （只有在連續模式下，凍結行列頭才有效）；
2、展示的報表需要設置 FrozenColumns和FrozenRows的值，并且只能凍結表頭和列頭。)
HTML5Viewer 自定義Toolbar按鈕：在MVC 框架下，使用Html5Viewer加載報表，進行自定義Toolbar按鈕注意的點是：
UiType模式：Custom。
HTML5Viewer 傳報表參數： 在MVC框架下，使用Html5viewer 。當使用參數報表的時候，有時項目需要進行前端的參數傳遞，需要注意的點是：
前端傳遞的參數命名和報表的參數命名要一致。
HTML5Viewer 傳報表多值參數：在MVC框架下，使用Html5viewer 。當使用參數報表的時候，有時項目需要進行前端的參數傳遞，需要注意的點是：
前端傳遞的參數命名和報表的參數命名要一致。
HTML5Viewer 綁定動態數據源：在MVC框架下，使用Html5viewer 動態綁定數據源，注意點：
1、添加一個WebService的服務。
2、服務繼承的方法：GrapeCity.ActiveReports.Web.ReportService。
使用HTML5Viewer 實現報表自動刷新：在進行報表加載后，有時需要報表定時刷新，來進行數據的動態顯示?？梢酝ㄟ^定時器和refreshReport()函數來實現。
自定義查詢條件：在進行項目開發的時候，有時需要ActiveReports只做一個報表展示的功能，然后數據的篩選和其它功能的實現都是通過自定義來實現。
多數據源綁定：該demo主要介紹了報表是如何在后臺進行多數據源綁定。
通過Object類型數據源綁定對象或者集合對象：該demo主要介紹了報表如何動態綁定object 動態數據源。
通過DataSet類型數據源綁定DataTable：該demo主要介紹了報表如何動態綁定 Dataset 動態數據源。
數據源綁定JSON數據源：該demo主要介紹了報表如何動態綁定JSON數據源，注意點：
1、JSONFilePath 的路徑要正確。
2、source_url 要是一個您可以訪問的服務地址。
例圖：MVC 平臺下ActiveReports 利用HTML5Viewer 加載以及顯示報表
ActiveReports 是一款專注于 .NET 平臺的報表控件，全面滿足 HTML5 / WinForm / ASP.NET / ASP.NET MVC / WPF 等平臺下報表設計和開發工作需求，作為專業的報表工具為全球超過 300,000 開發人員提供了全面的報表開發服務。
使用 ActiveReports 報表設計器，用戶可輕松設計如 Excel 表格、Word 文檔、Dashboard 大屏等常見類型報表，并將數據以豐富靈活的可視化圖表方式呈現給最終用戶。同時，ActiveReports 報表控件在運行時還為最終用戶提供數據篩選、排序、鉆取、表達式跳轉等強大的報表交互分析能力，無需修改代碼即可滿足用戶在不同場景下的報表需求，從而提高開發效率，加速項目交付。
、腳本模板
2、 場景模板
性能測試工具選擇
1. 數據建模工具
DataFactory是一種強大的數據產生器，它允許開發人員和QA很容易產生百萬行有意義的正確的測試數據庫,該工具支持DB2、Oracle
、 Sybase、SQL Server數據庫，支持ODBC連接方式，無法直接使用MySQL
數據庫，可間接支持。
2. 腳本開發工具
（1） 若考慮腳本運行效率，則可考慮底開發語言C或支持異步通信的語言JS,我們可以分別選擇：Loadrunner 或 Node.js
的IDE環境進行開發。
（2） 若考慮腳本開發效率，則可考慮代碼復用性，可以選擇面向對象語言C#或Java，為此我們可以分別選擇：VS2008及以上版本 +對應LR.NET
控件 或者 Eclipse4.0及以上版本 + JDK1.7及以上版本。
3. 壓力模擬工具
（1） 若為Java類接口且單機并發數控制在500內，則可選擇Jmeter或者 Loadrunner。
（2） 若為WebService類接口且單機并發數控制在500內，則可選擇SoapUI或者Loadrunner。
（3） 若單機并發數超過500且控制在5000內，則可選擇Loadrunner。
（4） 若單機并發數超過5000，則建議采用負載集群，即采用“中控（Control Center）+ 多機部署（LoadGenerator）”方案。
4. 性能監控工具
4.1 監控工具
無論Windows或Linux
平臺，一般存在的是一個或一組進程實例，我們可以選擇Loadrunner 或 Nmon 來監控。有時為了獲取被測應用的一些特性指標，可以選擇被測組件自帶的性能工具集或監控系統。常見應用服務器監控工具推薦如下：
4.2 監控平臺
監控機器主要對被測集群服務器的服務或資源使用情況進行監控，比如各種開源的監控工具，MRTG：流量監控；CACTI：流量預警，性能報告Smokeping:IDC 質量監控；綜合監控：Nagios、Zenoss、Ganglia 、Zabbix、Sitescope、Hyperic HQ 等，如下所示：
4.3 第三方監控云服務（APM）
APM提供端到端應用性能管理軟件及應用性能監控軟件解決方案,包含移動,瀏覽器,應用,基礎設施,網絡,數據庫性能管理等，支持Java、.NET、PHP
、Ruby、Python
、Node.js、iOS
、Android
、HTML5
等應用性能監控管理，主流云服務包括聽云、OneAPM等，如下所示：
性能測試結果分析
1. 指標分析
性能測試的指標可分為產品指標和資源指標兩類。對測試人員而言，性能測試的需求來自于用戶、開發、運維的三方面。用戶和開發關注的是與業務需求相關的產品指標，運維人員關注的是與硬件消耗相關的資源指標。
（1） 從用戶角度關注的指標
用戶關注的是單次業務相關的體驗效果，譬如一次操作的響應快慢、一次請求是否成功、一次連接是否失敗等，反映單次業務相關的指標包括：
a.成功率b.失敗率c.響應時間
（2） 從開發角度關注的指標
開發人員更關注的是系統層面的指標。
a.容量：系統能夠承載的最大用戶訪問量是多少?系統最大的業務處理量是多少?
b.穩定性:系統是否支持7*24小時(一周)的業務訪問。
（3） 從運維角度關注的指標
運維人員更關注的是硬件資源的消耗情況。
以上說明了測試人員在選擇指標時需站在用戶角度去思考，另外為了后續能夠更好地分析問題，更需掌握與被測組件特性或運行原理相關的性能指標。
舉例來說，通常接口系統均會直接或間接地訪問數據庫層介質（如Mysql、Oracle、SQLServer等），此時我們需考慮由接口系統產生壓力下存儲介質的性能情況，通常我們會選擇分析指標如下：
（1） 連接數（Connections）
（2） 每秒查詢數/每秒事務數（QPS/TPS）
（3） 每秒磁盤IO數（IOPS）
（4） 緩存命中率（Buffer Hits）
（5） 每秒發生的死鎖數（Dead Locks/sec）
（6） 每秒讀/寫字節數（Read/Write Bytes/sec）
2. 建模分析
2.1 理發店模型
圖中展示的是1個標準的軟件性能模型。在圖中有三條曲線，分別表示資源的利用情況（Utilization，包括硬件資源和軟件資源）、吞吐量（Throughput，這里是指每秒事務數）以及響應時間（Response Time）。圖中坐標軸的橫軸從左到右表現了并發用戶數（Number of Concurrent Users）的不斷增長。
在這張圖中我們可以看到，最開始，隨著并發用戶數的增長，資源占用率和吞吐量會相應地增長，但是響應時間的變化不大；不過當并發用戶數增長到一定程度后，資源占用達到飽和，吞吐量增長明顯放緩甚至停止增長，而響應時間卻進一步延長。如果并發用戶數繼續增長，你會發現軟硬件資源占用繼續維持在飽和狀態，但是吞吐量開始下降，響應時間明顯的超出了用戶可接受的范圍，并且最終導致用戶放棄了這次請求甚至離開。
根據這種性能表現，圖中劃分了三個區域，分別是Light Load（較輕的壓力）、Heavy Load（較重的壓力）和Buckle Zone（用戶無法忍受并放棄請求）。在Light Load和Heavy Load 兩個區域交界處的并發用戶數，我們稱為“最佳并發用戶數（The Optimum Number of Concurrent Users）”，而Heavy Load和Buckle Zone兩個區域交界處的并發用戶數則稱為“最大并發用戶數（The Maximum Number of Concurrent Users）”。
當系統的負載等于最佳并發用戶數時，系統的整體效率最高，沒有資源被浪費，用戶也不需要等待；當系統負載處于最佳并發用戶數和最大并發用戶數之間時，系統可以繼續工作，但是用戶的等待時間延長，滿意度開始降低，并且如果負載一直持續，將最終會導致有些用戶無法忍受而放棄；而當系統負載大于最大并發用戶數時，將注定會導致某些用戶無法忍受超長的響應時間而放棄。所以我們應該保證最佳并發用戶數要大于系統的平均負載。
2.2 壓力變化模型
隨著單位時間流量的不斷增長，被測系統的壓力不斷增大，服務器資源會不斷被消耗，TPS 值會因為這些因素而發生變化，而且符合一定的規律。
圖中：
a 點：性能期望值
b 點：高于期望，系統資源處于臨界點
c 點：高于期望，拐點
d 點：超過負載，系統崩潰
2.3 容量計算模型
以一網站性能測試為案例：
1. 通過分析運營數據，可以知道當前系統每小時處理的PV數
2. 通過負載測試，可以知道系統每小時最大處理的PV數
即整理得
系統每小時PV處理剩余量 = 系統每小時最大處理的PV數 — 系統每小時處理的PV數
假設該網站用戶負載基本呈線性增長，現有系統用戶數為70萬，根據運營推廣計劃，1年內該網站發展用戶將達到1000萬，即增長了14倍。即整理得：
系統每小時PV處理增加量 = 當前系統每小時處理的PV數 * 14 — 當前系統每小時處理的PV數
每天系統負載增加率 = 100% / 365 = 2.74 % （備注：此處將未來系統用戶數達到1000萬的負載定義為 100% ）
系統每天PV處理增加量 = 系統每小時PV處理增加量 * 每天系統負載增加率 * 24
所以，我們可以知道在正常負載條件下：
系統可支持正常運行天數 = 系統每小時PV處理剩余量 * 24 / 系統每天PV處理增加量
假設該網站后續部署升級天數已知，這樣我們可以知道提前升級的天數：
系統可支持正常運行天數 — 部署升級天數。
性能測試通過標準
1. 所有計劃的測試已經完成。
2. 所有計劃收集的性能數據已經獲得。
3. 所有性能瓶頸得到改善并達到設計要求。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
