第一章 King
¶ 低代碼風潮
¶ 前言
如果您是非資訊技術人員，可以略過關於技術說明的相關章節，建議您先看第一、二、五、六這幾章的說明即可。當然，我們也盡量用淺顯易懂的文字，簡要的說明技術相關背景，有興趣的話也歡迎瞧瞧。
¶ 低代碼開發平台是什麼?
簡單來說，低代碼開發平台是提供一套開發環境，它能夠通過介面設定(而非手寫電腦程式)，來生成應用程式。它是一種軟體開發的方式，實際上，市面上已經有相關的產品出現，包括 outSystems，大陸也有宜搭、微搭等對應的產品。
這個新平台最大的願景，是在產品快速更新的數位化時代，提供一個能夠可以迅速開發、快速驗證、並上線新應用的有效方式，而不用極大程度地依靠強大的技術團隊，通過長時間的反覆運算才能夠完成，最終達到一個降本增效的結果。
¶ 舊瓶裝新酒
關於最近低代碼所引起的一些風潮，基本上這是一個標準的舊瓶裝新酒的觀念。
包括之前搞了非常久的所謂程式生器或是 Wizard 都是屬於 Low-Code 這個平台的一個前身。
簡單的說，是因為當前開發軟體資訊系統所用的方式，實在太過於原始、太過於粗獷，簡單的說就是
需要依賴開發人員有極強大的開發能力，才能寫出還可以用的系統。
所以不同的程式設計師所設計出來的系統，不管是他的功能、效能、美工等各方面，都差異非常大。
所以很多人都把程式設計師當成是一種類似於藝術的範疇。
¶ 偷懶是人類進步的原動力
為什麼會一直會有這種所謂的產生器的概念? 主要是因為基本上在某些特定範圍內，有一些系統跟功能
的確是需要非常高等級的研發能力才能搞定，比如 AI 的核心演算法，這聽起來就不是一般人類能搞定的事情。
但是在另一方面，某些通用的後台管理資訊系統、行事曆管理或是客戶關係管理，這類的資料庫系統程式，
基本上它的功能是大同小異的。在這個一定範疇內的資訊系統，經過一定時間的累積經驗後，是可以用工具來
協助加速系統開發、並讓程式的品質及穩定度，這是絕對可行的。
¶ 眾裡尋他千百度
百度的這個平台也就應運而生。它的底層是用 Facebook 的 React 的前端框架開發，amis 是純粹的前端框架，
也就是說，基本上他主要是處理使用者操作系統時所看到的畫面。和其他框架不同的是，她最大的亮點，
就是不用你寫程式，而是透過特殊的設定，用 JSON (簡單的說是一種特定格式的文字檔) 的定義，
來描述畫面要長怎樣。
¶ 提高生產力是最高目標
很早以前我們就希望能透過類似的方法，就是透過定義去設計、設定畫面，然後在裡面，留一些接口，
可以跟後端資料庫連接，來達到一些基本的操作。當然，一旦使用這樣的架構，基本上就沒有辦法隨心所欲，
因為一旦使用框架，就一定會被框架限制，這是沒有辦法的事情。
可是如果撇開這個問題，如果考慮到它能提高的生產力，那麼除非系統必須要強調非常個性化的設計，
否則這個平台就非常適合。
¶ 後端的 [以資料庫為開發核心]
聊完了前端的部分，那後端商業邏輯該如何解決?
所謂的後端，更多指的是商業邏輯、分析報表等。這個部分從來就不是產生器能解決的，但是他卻是系統的靈魂。
我們之前花了很多的時間去整理、去思考、反省，也參考了很多的 ORM 等框架，也在超過20年的實際開發領域，
下了很大的功夫，累積資料庫相關的開發經驗。最終提出了 [以資料庫為開發核心]，這個開發理念。
基本上，這個概念就可以跟百度的這個前端框架，完美的整合。用這樣的方式打通的前後端，而且真正達到
所謂的低代碼，只用最少的技術(但還是要有很深的功底)，就可以完成功能相當完整的資訊系統。在稍後的章節會有更詳細的說明。
¶ 聯絡我們
如果看完相關的介紹後，想更進一步的了解我們的系統或報價，歡迎與我們聯絡
- eMail: michael@gex.com.tw
¶ 框架核心概念
- 整個應用程式的框架，基本上可以分為三個部分
- 第一個部分：是百度的 amis 前端平台
- 第二個部分：是整合 node.js 所開發的通用API平台。再加上由核心的 orm_api 及為數眾多的資料庫預存程序，所組合而成的一連串商業邏輯。這個部分同時也包括了完整的權限整合機制(Role-Permissions) 的主選單的管理系統。
- 第三個部分：Wizard 程式產生精靈。這個部分是讓整個系統的開發效率大幅提升的關鍵。透過Template 樣版程式並配合前後端已經整合好的框架，就能快速又高效的產生程式。
¶ 拿來即用的完整範例
- 老王賣瓜，大家都說我們家的瓜甜，麒麟平台用實例說話。我們的應用程式開發團隊，使用 Kylin 平台，開發包含 [專案管理]、[資訊中心]、[共用資訊]、[客戶關係] 等多個實際模組，開箱即用，一方面可以當作開發的範本參考，也可以直接拿來使用。我們也希望企業實際的使用後，確認符合需求，我們也希望企業實際的使用、評估，確認符合需求後，再討論後續的合作事宜，這才是雙贏之道。
¶ Kylin 功能架構圖
¶ 麒麟低代碼平台簡介
快速指引
¶ 如何做? 從創建 Table 到產生程式並執行
- 匯入規格設定內容
- 智慧型基礎規格設定
- 設定欄位名稱及使用元件
- 產生程式並立即執行
¶ 能做什麼? 基本功能畫面介紹
- 列表預覽及查詢
- 列表直接編輯
- 列表欄位可自定義顯示否
- 支援多樣的顯示元(物)件
- 常用的開窗查詢
- 圖片顯示及檔案下載
¶ 沒有最好, 只有最適合
- 企業規模不同，作業流程複雜度不同，需要的系統也不同。
面對目前市面上的各低代碼開發平台、或是類似的工具，可以說各有各的優點，那企業該如何選擇呢?
¶ 我們的建議是企業可以依照下面的原則判斷：
- 產生程式的過程，是否容易使用? 操作是不是很直覺、簡單?
- 經由工具產生出來的程式，是否容易調整、修改?
- 最後產生的程式，功能是否完善? 操作介面是否友好?
- 程式發布的過程是否簡單?
- 學習工具的成本有多高? 是否需要非常多的相關專業知識?
透過上面幾個原則的判斷，企業就可以依照自己的需求，選擇合適的系統，
挑選系統和交女朋友並沒有太大的區別，
有些人一定要顏值高、身材好、家境優渥，但是可能要忍受她可能會有的公主病。
有些人認為娶妻娶賢，外貌並非優先。
每個人的標準都不一樣，慎思明辨，選擇最適合自己的才是最重要的。
基本概念和架構說明
¶ 前後端分離開發架構
開發資訊系統從來都不是一件簡單的事，所牽扯到的相關知識非常複雜。千萬不要被廠商的宣傳語誤導，這絕對是專業才能搞定的事。
如果您之前沒有太直觀的完整概念，建議您可以自行在網上搜尋相關的文章，也可以參考下文，此處就不在贅述。
¶ 以資料庫為開發核心
¶ 前後端基本概念
¶ 前後端分離架構說明
¶ Wizard 架構三部曲
¶ 前言
一直以來，只要是有相關開發經驗的程式設計師，在經過多次反覆的、類似的程式開發之後，都會試圖開始根據所累積的經驗，然後想辦法把重複性的工作，整理成一些，不管是工具、還是輔助的設計程式、或是用最簡單的複製貼上法，來加快開發的效能、並提高開發的品質。
¶ 方法論
最早，我們們所採用的方式，基本上是程式產生器的概念，這個概念非常多人實作過，每個人的方式也有所不同。經過幾次反覆的辯證修改，最後我個人所採用的方式，我稱之為樣板程式產生法。這個方式基本上是經過下面幾個開發的步驟：
- 首先，會請團隊中程式開發能力最強的開發人員，依照產品經理、架構師所提出的框架樣式，或是參考相關的競爭產品的現有程式，根據日後所要開發的系統所需的功能、包括操作介面其他的設計範本，開發出一些標準範例的程式，我稱之為樣版程式或是範本程式。這幾支範本程式，通常會包含日後計畫要開發的程式中，大部分通用功能及操作介面。在這個過程中，也會開始不斷的整合出開發所需要的框架，包括主要使用的開發平台及工具，例如是 NET 平台或是 Java 平台。主要支持的資料庫、和第三方的開發元件，例如報表工具或元件。
- 開發好上面的範本程式後，接下來就會根據這些範本程式開始進行抽離的動作。這個過程，基本上是將程式有可能變動的部分，例如不同功能對資料庫存取不同的欄位，進行一個整理的動作。我的做法，我稱之為 [變數替代法]，我會將變動的部分設計換成一些特殊的變數代號，在稍後開發程式產生器時，我會把設定好的這些變數，替換成不同資料來源的欄位內容。
當然，我理解這樣的說明有一點難以理解，如果您沒有思考和開發過類似的程式，那這邊就請您就先有個概念，就是範本程式是程式產生器要實際產生程式時的主要依據，先有這樣的概念就可以。 - 就下來就是程式產生器的開發，之前我就聽說一些高手高高手，都形容程式產生器是【一塊很難啃的骨頭】。我完全同意這個看法，要寫出一個好用的程式產生器，真的是一件相當困難的事情，不過如果真的能夠開發出一套好用的工具，對程式開發的效能以及品質，都會有非常大的幫助。所以是不是要開發程式產生器，應該要依照各個公司本身的需求，因為開發的成本不低，且對開發人員的程度有較高的要求。
市面上也有一些已經開發好並在市場銷售的產品，例如訊光科技，這真的是一家台灣之光。當然，大陸那邊也有非常多的廠商，有相當優秀的產品。近年來，因為所謂低代碼開發平台的興起，又開展了另外一股風潮，不過基本上，所謂的低代碼開發平台，事實上也就是延續自早期程式產生器的概念。當然，因為技術的日新月異，所以目前的低代碼開發平台，功能以及效能都比先前有大幅的進步，這絕對是事實，只不過我還是在強調，一個技術並不會憑空而出，而程式產生器就應該算是低代碼開發平台的前世。
¶ Wizard 三部曲
聊完了以上的概念，在我們麒麟(Kylin) 的開發平台上，我們是採用 Wizard 架構三部曲的概念來開發，簡單的說， 所謂的三部曲，就是 Project(專案)、Function(功能) 及 Field (欄位定義)。
- 第一部曲，Project - 專案或模組：主要是定義整個預計要開發的系統，會被區分為幾個模組來開發、要分成多個模組來看待。比如說，企業資源規劃 ERP 系統中，我們會有財務模組、進銷存模組、採購訂單模組、CRM、HR人力資源管理系統等等不同的模組。所以基本上，專案或是說模組，主要是定義我們所要開發的完整系統會被區分成幾個模組，方便開發跟工作分配。
- 第二部分，Function- 功能：經過前一個步驟的分工之後，接下來就是定義每一個專案模組，會有哪些功能。這個部分會根據專案本身預計要開發的範圍而有所不同，在功能定義中，基本上主要是定義一些重要的高階內容，例如功能名稱、所屬範本、主要資料表、關鍵見職等。還不是定義到實際功能的細節。
- 第三部分，欄位定義：延續上一步驟的功能定義，例如說我們要開發一支訂單管理系統的程式，上一個步驟定義了它是屬於 [單據類] 範本程式，也定義了他主要的資料表來源，一般而言應該是一個 Master-Detail 主明細表的架構。在欄位定義這個功能，就會開始詳細的定義這個功能所用到的所有的欄位，每一個欄位都會詳細的定義包括他的欄位名稱、長度、使用元件、新增預設值、是否唯讀，在畫面上呈現的位置等等。經過這些細節的設定後，程式產生器就可以根據這些詳細的定義，最終產生實際可以執行的程式。這就是最簡單的一個程式開發的完整過程。
¶ 程式產生三部曲
前面我們談完了 Wizard 架構的三部曲，基本上這是一個標準開發框架的實作。早期，有很多類似的系統，都有資料庫字典(Data Dictornary) 這樣的概念，我們也是基於類似的概念實作而成。
- 如果你有足夠久的開發經驗，就會發現，因為作業平台或是開發工具的迭代，常會造成先前累積的所有努力，一旦改朝換代，就一切付諸流水。
我們這一個架構，是希望能夠最大程度的將規格相關的設定能夠盡可能地重複使用，只要抽換不同的底層程式產生器的部分，就能支援日新月異、層出不窮的新平台。 - 傳統的開發方式，通常會先要求 user requirement、系統分析文檔、系統設計文檔，然後才是交付程式設計師開始開發，這個過程絕大部分都是書面的文件工作，
講得更直白一點就是一大堆的Word文檔。程式設計師必須先啃完厚厚的、複雜的系統分析文檔後，然後從零開始開發程式。聽到這裡您應該可以了解我們想表達的理念，
如同精實管理、還是 Toyota Production System(TPS)、或是任何近代的管理思維，都不斷的強調【杜絕所有的浪費】。
從我們剛才提到的傳統的開發模式，您應該會發現，由系統分析師寫完文檔，不管是 SA 或 SD，和程式設計師之間存在一個巨大的鴻溝。
這些文件對於程式開發當然非常重要，但是， 為什麼不能直接把這些文件轉換成第一個版本的原始程式碼呢? 這不僅僅是我們的疑惑，也是非常多業界先進的不解，
所以不斷的有程式產生器或是低代碼平台等等，類似的工具不斷的湧現，他的目的就是要填補剛剛我們提到的巨大的鴻溝。 - 說了這麼多，能不能來點實際，沒問題，接下來我們就透過麒麟應用程式平台，透過實際的三步驟，我們稱作為三部曲，展示開發程式可以多麼的高效。
¶ 首部曲
- 首先，請先建立一個維護的資料表， 程式設計畢竟是相當專業的工作，低代碼平台在怎麼簡易，必要的程式開發基礎還是必須的。 請您先就希望開發的功能，例如會員資料、供應商基本資料等，在資料庫中建立相關的資料表及欄位。
¶ 二部曲
- 第二步，將這個資料表透過我們提供的工具，匯入到我們 Wizard工具中。匯入以後，就到我們的 Function 維護表單去設定，包括欄位顯示名稱，使用的元件，預設值等等資料組一設定。
¶ 三部曲
- 第三步，相關的細項設定完成之後， 就可以 generator 產生程式碼(或 json設定)，然後就可以直接執行。當然這還是在測試環境，經過測試無誤以後，我們就可以把它掛到我們的功能表中，設定權限之後就可以正式執行。
¶ 結語
- 經過上面的幾個步驟，就可以快速的產生出一支具備完整新增、刪除、修改、查詢的程式，這個過程根據我們的經驗，有可能需要反覆的進行多次，因為使用者通常必須看到實際畫面，才能得出實際的建議。這個過程中，不需要程式設計師修改任何程式，所以可以反覆地和使用者溝通。但是，如果不是採用這種方式，你就必須承受程式設計師的怒火，他會覺得使用者不斷的在找碴。
- 稍後的章節，我們會分成幾個標準的範本，分別的詳細說明，目前的平台所支援的開發範本，您可以就實際開發的範例來決定是否適合公司內部的系統開發作業標準。
¶ 可無限擴充、但無須編譯、隨時上版
¶ 大部分的開發平台，或多或少都有以下的問題
- 每次修改程式後，都必須編譯後上版
- 隨著時間的增加，程式安裝包越來越大
¶ 麒麟(Kylin) 的代碼開發平台，有幾個相對於其他平台比較突出的特點
- 一個是因為採用百度的 AMIS 前端平台，所以前端並沒有常見的 JavaScript 程式碼，取而代之的是 JSON 格式的設定內容。這是我們開發團隊非常欣賞的一個特點，讓我們可以更專注在商業邏輯的解決，而不是被 UI/UX 的操作所綁架。
- 至於後端的部分，我們的開發團隊，基於多年的實戰開發經驗，提出了 [以資料庫為開發核心] 的後台通用解決方案，簡單的說，就是把所有的商業邏輯全部都寫在資料庫的預存程序中。然後再透過通用的 API 提供所有的資料存取服務，就可以達到 [預存程序即 API]，這也大幅簡化了API 的開發效能。
- 透過上面的說明，您會發現，我們的開發團隊，很技巧的把前端程式、後端程式，都納入到一個無需編碼的開發框架。而且可以達到，開發後即可上線的境界。當然，要達到這個幾乎不用再修改程式碼的境界，必須依賴我們的 Wizard 提供更完善的解決方案，這也是我們持續在努力的。但是針對一般的資料庫後台維護需求，絕大部分的需求我們都可以滿足。
Server 端基礎設計
¶ Node.js + 通用 api 存取架構說明
¶ store procedure 即 API
¶ 用實際範例說明吧
我先寫了一支 test_getUserData 的 store procedure，程式內容如下
create proc test_getUserData
(
@userid varchar(100)
)
as
begin
select * from sys_users where userid = @userid
end
- 將程式寫入資料庫中
- 然後開啟 PostMan，輸入如下的參數內容，就得到該 user 的相關資料
- 一般而言，用 select * from xxx 是個不好的習慣，所以讓我們改一下 Store Procedure，只取 4個欄位，更新程式後，再執行一次 API，您會發現，Response 的資料內容已經不一樣了
alter proc test_getUserData
(
@userid varchar(100)
)
as
begin
select userid,username,email,token from sys_users where userid = @userid
end
-
在這個過程中，我們完全沒有更改任何一行 server 端的程式。
這只是一個非常簡單的範例，可是這樣的解決方案，可以讓您或是貴公司，很輕易的透過撰寫 Store Procedure 就完成數十隻甚至成百上千支的 API，這在很大的程度上大幅提升後端的開發效率。當然，如果你所在的組織已經有寫了一堆的 store procedure，那恭喜您，接下來要考慮的只是要開放哪些 API 而已。
Store Procedure 是一個已經存在超過 20 年以上的技術，我從早期在 MS-SQL 2005 上寫的程式，到目前的最新版本都能執行。即使是在 Opensource 赫赫有名，使用者滿坑滿谷的 MySQL，也從 5.0 版以後完整支援 Store Procedure。更令人欣賞的是 SQL 語法自從 ANSI 92 後就有一個國際標準，讓我們在跨不同資料庫時，雖不能直接 Copy 使用，但是總是有跡可循，是可以修改部分語法後移植到其他資料庫。
本文主要的目的是在展示，透過一支通用的 Server 端程式，配合使用 Store Procedure 就能提供一個快速開發 API 的有效方法。您也許會有疑問，這個所謂的通用 Server 端程式，只能用在 Node.js 嗎? Of Course Not! 事實上我的通用 Server 端的第一個版本，是用 ASP.NET 寫成的，所以如果您想用 PHP、RoR、Python 等等現有的 Server 程式語言，都沒有問題，只要該工具能連接資料庫即可。
如果您不熟悉 Postman 的操作，可以上網 Google 一下就有很多的教學文，或是參考下文
http://kainors.github.io/2017/03/19/api-testing-with-postman/ -
實際上在使用 API 時，雖然可以使用 GET 或 POST，不過除非有特殊的原因，一般都是建議使用 POST 方法。
-
如果要提供 API 讓前端呼叫，一般而言我們會先提供一份 API 的使用說明文檔，主要的內容應該會有下列部分
- Request
- Response-ok
- Response-error
- 以上就後端開發 API 提供一個不同的做法，這個方法的形成也是因為專業分工的思維下的產物。或是換個角度想，您認為 API 應該由誰來撰寫最合適? 誰最了解系統? 我的看法是系統分析師(System Analysis) 應該是最熟悉的。甚至在寫規格書時，如果有適當的工具，規格書的內容會有很大的改變。傳統用 Word 撰寫數以千頁的規格文檔，在實務上是非常沒有效率的，對工程師也是最沒有幫助的，因為就算工程師啃完厚厚的規格書，然後呢? 然後就要一行一行寫程式。如果改為 SA 是交付已經完成的雛型程式，加上已經寫好的相關 API 程式，在這個基礎上，您認為開發的效率還會一樣嗎?
¶ 核心的 orm_api
¶ 簡化版的 ORM 框架
- orm_api 是一支通用型的 store procedure, 可以不必寫任何一行程式，只要傳入適當的參數，就能直接提供基本的新增、刪除、修改、查詢(分頁查詢、單筆查詢) 等資料庫存取功能。
下面是 orm_api 的註解說明，請參考
¶ 利用 Postman 測試 API 範例如下
呼叫範例： url/orm_api/2/
| POST 參數 | 參數說明 |
|---|---|
| para01 | TableName，如 zen_department |
| para02 | Primary Key，如 did (如果是複合主鍵，用逗號區隔即可) |
| para03 | C 代表新增、U 代表修改、D 代表刪除、P 代表分頁查詢、R 代表單筆資料查詢 |
| para04 | args，api 所需的實際參數，主要分為2大類，CUD 為一類，內容為 json，是將欄位的內容組成 json，另外是分頁查詢，最多有6個參數，利用 ^ 為字串的分隔符號。 |
下面是前端使用 Vue.js 呼叫的片段程式碼，請參考
- 經由上面的程式範例，您應該能體會 orm_api 的優勢，如果配合適當的 Wizard 或是 Code Generator Tools，前端的程式可以善用這樣的機制被快速的產生接近商用版本的雛型程式。我們的目的是想要建構一個好用的、能快速上手的開發框架，而且必須架構在穩定的核心開發工具。
表單基礎設計
¶ Wizard 基礎說明
在第三章中，有簡單說明 Wizard 三部曲的內容，接下來就延續前面的主題，再更詳細的說明。
基本上所謂的三部曲，只是將開發一套完整的系統，由上而下的細分，以方便管理(三層架構)
¶ 三層架構
- Project: 定義有哪些模組
- Function: 定義每一個模組包含哪些功能
- Fields: 定義功能內的每一個欄位的細項設定
- Function: 定義每一個模組包含哪些功能
¶ Kylin EIS 專案
以我們開發的 Kylin EIS(Enterprise Information System) 為例，大致的架構如下(簡化版本)
- bas 共用基本資料
- basm51 產品資料維護
- productid 產品編號 input-text
- scancode 條碼編號 input-text
- prodcname 產品品名 input-text
- prodcateid 產品類別 picker
- basm52 產品類別維護
- basm53 倉庫資料維護
- crm 客戶關係管理
- eip 資訊中心
- eipm01 行事曆維護
- eipm12 會議類別
- eipm13 會議通知及記錄維護
- pms 專案管理
- pmsm01 專案資料維護
- pmsm02 Sprint 設定
- pmsm11 Product Backlog Item
¶ Project
主要是將整個完整的系統，分成幾個較小的模組，方便管理。並可以指定 API 主機及資料庫名稱。可以盡量多的整合不同的資源。
點選 >> 後，可以進入 Function 的設定。我們在此以 bas 為例
¶ Function
這裡會列出指定專案下的所有功能列表，除了一般的名稱設定外，他有幾個重要的欄位設定，以及重要的核心功能
- 重要的欄位設定
- 功能別
- SingleEntry
- SingleEntry-noView
- SingleGrid
- SingleTabs
- SingleTabs-noView
- SinglePanels
- SinglePanels-noView
- MasterDetailTabs
- MasterDetailPanels
- MasterDetail-Log
- MasterDetail-LogEdit
- Report 類
- queryReport
- queryGroup
- queryChart
- 主 Table
- Primary Key
- PK 為自增值
- 左類別設定
- 右關聯欄位
- 以上此2欄位，主要功能是設定左方是否有 aside 的 Tree 選項功能，這在進階功能中會特別加以說明。除了再次設定，還必須配合相關的預存程式要擴充部分設定。
- 功能別
- 重要的核心功能
-
設定最佳化
- 這是一個快速設定欄位相關內容的智慧小幫手，如果欄位數較多，一一設定事實上有點繁瑣，透過這支程式，可以根據經驗值快速給定參考預設值，雖然沒辦法達到100% 的正確率，但的確可以大幅提高設定的效率。
他能根據目前專案的設定內容，給定欄位的中文名稱，並給定建議的 UI 顯示位置的建議值，讓開發人員可以根據預設內容，再快速修改為最終版本。
- 這是一個快速設定欄位相關內容的智慧小幫手，如果欄位數較多，一一設定事實上有點繁瑣，透過這支程式，可以根據經驗值快速給定參考預設值，雖然沒辦法達到100% 的正確率，但的確可以大幅提高設定的效率。
-
設定區塊抬頭
- 當表單的欄位數超過 30個以上時，用 Tabs 或 Panel 來排列 UI 是常用的技巧，此時就可以利用此功能，設定區塊的名稱，在稍後的範例中，員工資料維護就有使用相關的 Layout 及區塊名稱的設定。
-
產生程式
- 這是 Wizard 的核心程式，當相關的設定都設定完成後，執行本功能就會產生最終的程式碼。這個程式碼是結合了百度 AMIS 的 JSON 設定以及配合的 API Server 端程式，並存入資料庫中，配合相關的系統程式即可呼叫並執行。
-
查看 JSON 內容
- 可以查看並修改 JSON 的程式內容。
-
¶ Field
-
設定欄位名稱及使用元件
- 直覺式的設定相關的內容，如欄位名稱、預設值等。
- 重要的是要選擇適當的元件，目前支援的元件如下
- Select
- Options
- Checkboxes
- Input-Date
- Input-Number
- Formula
- Input-Password
- Picker
- Radios
- Switch
- Static
- Input-Text
- TextArea
- Input-Image
- Input-File
- Transfer
- 表單上顯示的位置，透過下面參數設定(九宮格法)
- Block: 如果欄位數較多，可以設定多個區塊，配合 Tabs 或 Panel 的設定讓 UI 安排更合理。
- X座標: 利用 (x,y) 的設定來定義元件顯示的位置。
- Y座標: 同上
- 顯示如下的 UI
¶ 基本的單檔維護
- 這是整個系統最常見的表單功能，主要是針對單一個主檔，例如員工基本資料維護、客戶(會員)資料維護等，執行新增、刪除、修改、查詢等作業。
- 查詢(左方的 aside 非必要規格，依實際需求設定即可)
- 新增
- 修改
- 刪除
¶ 優缺點
單檔作業顧名思義，指的是針對單一主檔，提供維護作業，在麒麟低代碼的平台中，我們的做法是提供了多種不同的常用程式樣板(通常是依照欄位數的多寡來區分)，快速的產生類似的程式。
- 優點
- 這樣的優點是效率高、程式功能一致、較高的品質。
- 缺點
- 就是客製化較少(但仍可透過手動調整)，且需求必須和範本功能類似，才能發揮最大的效益。
¶ 目前支援的單檔範本
- SingleEntry : 適合欄位數 10-50 左右的表單(直接展開的方式)
- SingleTabs : 適合欄位數超過 50 的表單
- SinglePanels: 適合欄位數超過 50 的表單
- SingleGrid : 適合欄位數少於 10 的表單
其中 SingleTab 和 SinglePanels 的設定完全相同，差別是利用 Tab 或是 Panel 來安排畫面的顯示，請參考下圖
- SinglePanels
- SingleTabs
而 SingleEntry 等於是 Block=0 的 SinglePanels，所有的欄位由上而下展開
- SingleEntry
所以到說明到此，您應該已經了解，前3種範本都是類似的操作，只不過是針對欄位的多寡，提供不同的布局顯示方式。
基本的操作是相同的。
至於 SingleGrid 通常是針對欄位較少的表單(通常低於10個欄位)，我們會提供直接編輯的功能，方便快速維護資料，這會在下一個章節說明。
¶ Transfer 元件的特別說明
-
Transfer 是一個非常方便且好用的元件(請參見上圖 - 部門選擇)，可以應用的範圍很廣，凡是需要多選的場景，都可以使用本元件，舉凡
- 勾選會議的與會人員
- 某功能有哪些腳色 (Role) 有權限使用
- 部門有哪些所屬員工等
-
使用本元件時，有下列的注意事項
-
因為是多選的功能，所以一般而言，我們都會設計一個 [1-多] 的關聯資料表來存放資料，如
- sys_role(角色檔) - sys_userroles(角色-用戶關聯檔) - sys_users(用戶檔)
-
但是 Transfer 元件必須對應到主檔的某一個欄位，所以我們會在 Role(主檔) 新增一個 Owned(max) 的欄位配合。這個欄位只是一個中繼欄位，實際並不會使用。
-
為了配合這個機制，所以我們在 orm_api 中加入一個機制，在存檔時，會去讀取 sys_transaction 這個系統表的設定，如果 Table 名稱存在，會去執行對應的預存程式
-
所以要使用這個元件，必須手工撰寫相關的 [預存程式]，可以參考目前系統已撰寫的 sys_transfer_owned2userroles、sys_transfer_owned2rolemenusecurity
-
¶ 列表式的編輯功能
- 這也是系統常見的表單功能，針對單一主檔(但較少欄位)，提供快速編輯的類 Excel 操作介面，一樣可執行新增、刪除、修改、查詢等作業。
¶ 設定方式
- 在 Function 的 [功能別] 中選擇 SingleGrid 即可
- 適合欄位數少於 10 的表單，可以快速編輯，並支援多筆資料修改後存檔。
¶ 單據類表單設計
¶ 查詢設計
¶ 實例說明，以訂單日報表的查詢為範例
- 上面是查詢條件，請對照下方的預存程式的 [參數]
- 預存程序
- 查詢條件和 [預存程式] 的參數配合
¶ Query Wizard 的設定介面
-
Query Wizard Project(和表單共用相同的模組定義)
-
Query Wizard Function
-
Query Wizard Fields，查詢欄位的設定
-
Query Wizard Filter，查詢條件的設定(必須配合預存程式的參數)
¶ 匯入輔助工具
-
將 [預存程式] 的參數及欄位匯入 Kylin Wizard 中，這個工具是提供一個將 [預存程式] 和 Wizard 快速整合的機制。如果沒有這個工具，那只能逐一將欄位及條件手動輸入到 Wizard 中，效率相對就低效很多。看到這裡，您應該就能深深的體會麒麟低代碼平台，無時不刻、想方設法提高開發效率的努力。
-
匯入 [預存程式] 的參數
-
匯入 [預存程式] 的所有欄位，目前程式只會取得最後一個 Select 的結果，特殊情況下只能手工新增到 Wizard
¶ 圖表設計
¶ 實例說明，以 [客戶訂單排行統計圖] 為範例
- 上面是查詢條件，請對照下方的預存程式的 [參數]
- 預存程序
- 查詢條件和 [預存程式] 的參數配合
¶ Query Wizard 的設定介面
-
Query Wizard Project(和表單共用相同的模組定義)
-
Query Wizard Function
-
Query Wizard Fields，在 Chart 中欄位是固定的(請參考 [預存程式] 內容)，所以無須設定欄位資訊
-
Query Wizard Filter，查詢條件的設定(必須配合預存程式的參數)
¶ 如何內嵌其他網頁
- 利用 iFrame 元件
- 熟悉百度 AMIS 的前端元件
進階功能設計
¶ 設計 aside 類表單程式
- 仍以 [員工資料維護] 為範例，可先參閱第五章單檔維護的相關說明
-
前端元件如下
-
要加入 aside 需要2個部份的配合
- 第一個部分：是 Function - 左、右類別設定(下圖下方紅框)
- 第二個部分：要修改 get_treedata 這支預存程序，未來希望能升級成設定即可，但是目前仍需手工修改本程式。
¶ 設定後產生程式即可上線
- 這支程式除了基本的設定外，比較費工的是要修改預存程序，當然我們日後會整理出一個設定即用的介面，這裡也先說明了只要熟悉 SQL 的語法，就可以自行擴充系統的功能。
因為想讓系統發揮最大的戰鬥力，並解決複雜的企業商業邏輯，寫程式是難以避免的，麒麟低代碼平台強調只需要單一開發語言，也就是 SQL，即可無限擴充的實際做法。
¶ 開窗呼叫另一支程式並傳遞參數
¶ 參數主要是要過濾新程式的資料(限制範圍)
-
在表單基本操作時，常會有一種需求，需要按按鈕查詢(或設定) 關聯資料
- 例如在 Function - 執行 [設定區塊抬頭]
¶ 如何傳遞參數?
-
參數必須指定 functiontag(程式代號)，開窗時才能根據參數過濾並取得正確的資料。因為 AMIS 都是 JSON 設定，只能在少數地方寫 code，所以此處我們是利用呼叫 zen_showsource 這支系統預存程式的接口來傳遞參數(para02=beta@xxx)。
這支系統預存程式主要的功能是呼叫應用程式並載入到平台架構內執行，凡是要執行類似的作業，請參考本處的作法。如果不需要傳遞參數，將 para02 設為空白即可。
¶ 被呼叫程式的配合設定
-
要在被呼叫程式的 crud 的 _@_query_filter 設定 @ls:query_id
- 因 dollar sign 為特殊字元，無法存檔，改用 @
¶ 執行另一支網頁並傳遞參數
¶ 單純用 Link 轉移到另一支程式
-
Project To Function，利用網址傳參數
-
Fields To Function，不傳遞參數
¶ 利用 HTML5 的 Local Storage 傳遞參數
-
Function To Field，因為無法用網址傳 ProjectID，故改用 Local Storage 傳遞(請注意名稱不要重複)
- 因為沒有地方寫 code 所以用一個特殊的空的 API 單純用來用 js 寫入 Local Storage
¶ 單純的執行 API(異動資料)
-
執行 [設定最佳化], 直接更新資料庫內容
¶ 呼叫 API 並利用多種方式傳值
-
執行 [產生程式], 用 Local Storage 和 Domain 變數傳值
¶ Service 特殊的傳值方式
-
執行 [查詢 JSON 內容], 將 api 回傳值當參數
¶ 群組式的查詢設計
- 這是前一章 [查詢設計] 的進階版，請先參閱前一章的說明。主要的差別在於 [預存程式] 的寫法，目前純粹依賴預存程式處理，前端並無太大的差異。
- AMIS 嵌套元件
¶ 實例說明，以 [訂單日報表(群組別)] 的查詢為範例
- 上面是查詢條件，請對照下方的預存程式的 [參數]
- 預存程序
- 查詢條件和 [預存程式] 的參數配合
- 程式內容因為要配合 AMIS 回傳的 JSON 內容，所以要在取回的資料內容中，再加入群組頭的資料，因為目前 AMIS 無報表類的顯示元件，目前只能先用此方法暫代，日後如有合適的元件再補充說明。
¶ Query Wizard 的設定介面
-
Query Wizard Project(和表單共用相同的模組定義)
-
Query Wizard Function
-
Query Wizard Fields，查詢欄位的設定
-
Query Wizard Filter，查詢條件的設定(必須配合預存程式的參數)
¶ 通用 Excel 匯入程式
- 利用 input-excel 元件，快速建構一支通用匯入程式一支通用匯入程式
- 整合前、後端元件及 API
¶ 擴充按鈕的設定
- 表單功能常會需要可以查詢或是設定一些相關的資料，通常會利用 button 開窗來達成。
- button_type = U 表示是放在 Grid 的上方位置，I 則會產生在 Grid 右方的操作列。
- related_menuid 是開窗要執行的另一支程式代號
- [查詢報價單] 實際執行的畫面如下
權限架構說明
¶ Role-Permission 架構
https://zh.wikipedia.org/wiki/以角色為基礎的存取控制
- 以角色為基礎的存取控制(Role-based access control，RBAC)，是資訊安全領域中，一種較新且廣為使用的存取控制機制，不同於直接賦予使用者權限，而是將權限賦予角色。
這種以角色為基礎的存取控制模型，更為中性且更具靈活性的存取控制技術。
美國國家標準局重新定義了以角色為基礎的存取控制模型，並將之納為一種標準，稱之為NIST RBAC。 - 在一個組織中，會因為不同的作業功能產生不同的角色，執行某項操作的權限會被賦予特定的角色。組織成員或者工作人員(或其它系統用戶)則被賦予不同的角色，
這些用戶通過被賦予角色來取得執行某項計算機系統功能的權限。
¶ 麒麟低代碼平台 Permission 關聯圖
¶ 主要功能及 Table 介紹
- User，使用者帳號設定(table=sys_users)
- 主要欄位: userid,username,pwd(加密),token,validate
- Role，角色設定(table=sys_roles)
- 主要欄位: roleid,rolename,used_menus(配合 transfer 元件)
- Role_Users，使用者角色相應表(table=sys_userroles)
- 主要欄位: roleid,userid
- Menu setup，系統的功能表單(table=sys_menutable)
- 主要欄位: menuid,parent_menuid,caption,moduleid,islimitdata,isLocalMenu
¶ Menu Security 設定
- Menu Security 設定，設定 menu 和 role 的權限映射關係(table=sys_rolemenusecurity)
- 主要欄位: roleid,Menuid,controlname
¶ 細項元件權限設定
- 規劃中，目前尚未上線
- Function Detail Permissions Control 設定，設定能否新增、修改、刪除、擴充按鈕等權限(table=sys_menutablecontrol)
- 主要欄位: menuid,controlname,description,type
¶ 定義角色許可權
首先定義角色許可權，使用者與角色間是多對多的關係。使用者許可權繼承自角色許可權。
- 情況一：使用者所屬的多個角色存在許可權衝突時，取最大許可權，即某許可權角色A許可，角色B禁止，則該許可權為許可。
- 情況二：使用者所屬的角色均未對某許可權進行設置時，即NotSet狀態，則該許可權同禁止。
- 預設情況下，使用者許可權繼承自所屬角色的許可權。不支援使用者等級的權限設定。
附錄
¶ Node API 開發平台安裝篇
¶ Server Pre-Install
- Windows Server(以 2012 為例)
- Install IIS
¶ Install相關的DataBase(MS-SQL 2012 Express、MariaDB)
- 並回存相關的資料庫。
- MS-SQL 要記得開啟 TCP/IP 協定(組態管理員)。
- 並修改 node API 的SQL密碼(請先解壓縮api 相關程式)
¶ Install Node.JS
¶ Install Office 201x(for文件製作)
¶ Install Postman(Postman-win64-6.3.0-Setup，測試API用)
(以下是用壓縮版解壓縮後直接測試，如果無法直接用壓縮版，可以等安裝完成後，再使用同樣的方式測試是否正確安裝)
| seq | Description |
|---|---|
| 1 | http://127.0.0.1:5050/xapi/v2/zenBusiness/get\\\\_keyvalue/2/ |
| 2 | Headers Content-Type application/x-www-form-urlencoded |
| 3 | Body -> x-www-form-urlencoded Para01=xxxx Para02=flowtitle |
¶ 壓縮包安裝(簡易版)
-
將開發環境的程式壓縮後，直接解壓縮，可以直接執行。只要 Win Server和Node.js 的版本沒有太大的差異，通常都可以直接解壓縮後執行。路徑如果非預設，只要修改 api-server.bat 內的路徑即可。
-
DbClick捷徑後即可啟動，在網址輸入 localhost:5050即可執行
¶ NPM 安裝(先略，研究中)
- 逐一手動安裝(完全重新安裝)
- Node.js api 的主程式，事實上只有一支 index.js
- api-server.bat 是批次執行檔，前面已說明
- server-token.js 是舊版的主程式，僅供參考(可刪除)
- web.config 是和 IIS 整合使用的設定檔
- config\\\\ 是 db的連線設定檔
node\\\\_modules\\\\ 是本專案會使用的3-party module(由npm 自動安裝)
¶ 以下我們就step by step 從頭建立並安裝相關的 component
-
請參考 http://blogs.uuu.com.tw/Articles/post/2018/06/27/在NodeJs存取SQL-Server資料庫.aspx
的內容 -
新增目錄
mkdir test-api -
cd 到該目錄
cd test-api
- npm install
- npm init 產生 package.json
- 開始安裝使用到的 Component
- npm install express mssql –save
* npm install fs multer body-parser nodemailer cors
- Copy index.js & config 目錄到 test-api 就完成
¶ Node API 和 IIS的整合設定
- 參考文檔
http://andy51002000.blogspot.com/2017/06/iisnodejs.html (簡易版，建議)
https://brooke2010.github.io/tecblog/2021/03/14/window-IIS-run-nodejs/
由於在本機(或VM虛擬機) 無法設定固定 IP(這個動作應該都是在Server端進行)，所以以下是擷取 GCP-VM 的畫面。
- 相關軟體安裝(reference docs)
- 相關 Server 設定
¶ 安裝 iisnode (iisnode-full-v0.2.21-x64.exe)
https://github.com/azure/iisnode/wiki/iisnode-releases
¶ 安裝 URL Rewrite (rewrite\\\\_amd64\\\\_en-US.exe)
https://www.iis.net/downloads/microsoft/url-rewrite
¶ 在IIS 建立一個網站
¶ 修改web.config 內容，並放到 api soruce 目錄下即可。
¶ 設定完畢，這樣就可以用IP呼叫，而不在直接寫數字IP。但是仍須加入port，範例如下，之前會錯是以為不必加 5050 port。
http://api.gex.com.tw:5050/xapi/v2/zenBusiness/get_keyvalue/2/
¶ 完工
¶ 以下記錄一些在 amis 開發中的一些心得及特殊用法
¶ 如何執行 javascript(在一般的 json 檔案中) ?
因為目前已知都是執行 api，而在 api 的 【requestAdaptor】 可以執行一些不要太複雜的 js，可以參考
¶ Index
¶ 範例一
¶ 範例2
¶ 範例3
¶ 範例4
¶ 範例5
¶ Node.js 基礎介紹
¶ 如何執行 javascript(在一般的 json 檔案中) ?
- 因為目前已知都是執行 api，而在 api 的 [requestAdaptor] 可以執行一些不要太複雜的 js，可以參考
https://github.com/baidu/amis/issues/854
https://github.com/baidu/amis/issues/881
¶ 配合 Button 呼叫空的 API 以執行 javascript
- 在 index.html 實作，確認可以呼叫外部的 js，不是一定都要寫在 requestAdaptor 這一小段程式內
至少有一個地方可以寫 js 程式，否則彈性實在太小了
¶ 支援 localstorage 當作參數
- 我已經加入 token 機制到 post API
- https://github.com/baidu/amis/issues/2173
¶ 將變數傳入 requestAdaptor中
¶ 有參考價值的 issues
¶ visibleOn 使用方式
¶ 如何給定預設值
- https://github.com/baidu/amis/issues/364
- 基本上要先搞懂 amis 的數據域就能理解，因為資料 bind 都是透過 data domain，所以預設值當然設在 data 即可，之前一直思考的方向都是 [物件.屬性]，當然這是幹性思維，但是要用 amis 就還是得理解其核心想法。
¶ 呼叫另一個已存在的表單的方法
¶ 新增時的預設值
- 固定值，如日期、Y or N
- 需要經過運算取得，如單號、預設幣別等，已在logon後，將sys_parameter 存為 localStorage 可以在 data 取用
