願大家心想事成
Page Scripting 是什麼？
簡單來說，Page Scripting 是一種微軟 Business Central Web 頁面上，記錄使用者在 UI (User Interface) 上交互操作流程的功能。
透過 Page Scripting 的功能，即可實現將 A 環境中的操作過程，放到 B 環境中重現執行。藉此達成排除錯誤、或驗證流程的需求。
錄製與重現功能
最基礎的用法是，將其視為一種錄製功能。
譬如你在設計一個新客製或產品時，想驗證這個新產品／客製的操作流程是否在其他環境也可以正常運行。
你可以在自己安裝產品的環境中透過 Page Scripting 開啟錄製，然後開始做所謂的”使用操作”，並於完成後停止錄製。接著匯出這個流程，將這個錄製匯入至另一個安裝相同產品的環境中，然後讓此錄製執行，系統就會自動依循你錄製的操作自動地在環境中運行出來。
簡單說，Page Scripting 可支援將操作流程匯出成 yml 格式的檔案，將此檔案匯入至 Business Central 環境即可讓操作在匯入的環境重新復現。
驗證流程的正確性
除了純粹的操作重現外，在這個錄製過程中，我們可以去新增對於欄位的驗證的操作。
舉例來說，在進行錄製，並開啟一張客戶卡時，可以點選其中一個欄位按下右鍵，彈出 Page Scripting 的詳細功能；新增 Validate (驗證)，去驗證說此時此刻該欄位的值為何，來當成錄製重現過程中其中一步檢查的步驟。
這裡的驗證資料值可以去設計所謂的邏輯，對著 Page Scripting 的檢查步驟中按下右鍵 – 屬性 (Properties)，可以去自定義這個值的條件為何，例如大於小於等於…，還有特殊自定義的邏輯格式，請參考網址
https://learn.microsoft.com/en-us/power-platform/power-fx/formula-reference-canvas-apps
透過這個功能，我們可以去進一步擴展這個工具的使用情境。
．範例一：驗證欄位計算值
最簡單的使用方式，是用來驗證一個功能執行後，對應的欄位變換是否符合我們預設的處理結果。
舉個例子，假設開立一張銷售發票，選擇一個料品，得知某欄位的單價為何，這時輸入數量時，金額會應該要跟隨你輸入的數量*單價去計算出來，這時你可以設定一個驗證，去檢查明細行金額是否計算正確。
操作如下: 開啟 Page Scripting→新增一張銷售發票 (Sales Invoice) → 選擇一個客戶 → 選擇一個料品 → 修改料品單價使其固定為 5000 → 輸入數量 5 →檢查金額是否是 25,000 → 錄製完成。
接著我們嘗試播放這個流程時，如果「過程檢核」與「最終結果」都沒有問題，就會是全部綠燈通過。
假設程式導致它金額計算結果不符，就會在驗證那個節點出現 Error，同時止步於那一個步驟並報紅燈。這就是一種簡易能讓顧問使用的除錯工具。
．範例二：驗證資料筆數
在 Business central 中我們有時會看到下拉選單或者一個頁面有多少筆資料，這個也能在 Page Scripting 中做驗證，也就是檢查資料”筆數”是否正確這件事
在 Business central 中我們有時會看到下拉選單或者一個頁面有多少筆資料，這個也能在 Page Scripting 中做驗證，也就是檢查資料”筆數”是否正確這件事
舉個例子，假設我們開發一個進料檢驗的功能，執行後可將「倉儲收貨單」上需要被檢驗的「料品明細行」彙整成進料檢驗單，其他筆不需檢驗的明細行就不會新增進進料檢驗單，那麼如果想透過 Page Scripting 進行驗證可以這麼設計。
首先新增一筆倉儲收貨單→明細行輸入三行明細（其中兩行是需要料品檢驗的料品）→執行產生進料檢驗單按鈕→接著到進料檢驗單清單上，篩選到出剛剛產生的進料檢驗單→點選進去→檢查進料檢驗單明細行的資料筆數是不是兩筆。
設計完這套流程後，將這個錄製匯出，未來也許產品經歷過無數次的修改，但只要這個大原則沒變的情況下，隨時都可以將這個錄製匯入並執行，以此檢查”只有需要進料檢驗的料品會在產生進料檢驗單時寫入到明細行”這原則。當然這是很陽春的版本，口述的邏輯大致就是上面這樣。
驗證流程的正確性 - 2 (條件流程)
除了驗證值以外，在 Page Scripting 中，我們還可以做所謂的條件流程，是的~它允許你在使用 Page Scrpting 重現錄製的過程中，加入條件判斷；只有當符合某個條件時才會繼續往下驗證。
舉例來說，如果有一個產品，在客戶卡上新增一個開關「過帳日期自動加一天」，如果開啟的時候，銷售發票在建立時選擇客戶後，過帳日期應該要自動增加一天，而如果那個開關沒開啟，則銷售發票在建立時選擇客戶後，過帳日期應該要不會自動增加一天。
若我們用Page Scripting設計檢查流程時，那麼我們可能就會在流程中，去設計說如果選到了一個客戶有開啟那開關，才要”驗證”過帳日期是否增加一天這件事，否則不做驗證。
如何使用 Page Scripting 加入條件流程的範例如下
假設我們在新增一個銷售發票，選擇客戶之後，如果有將”是否過帳增加一天”欄位預設填入到銷售發票中，我們可以在銷售發票那個頁面中，對那個是否過帳增加一天的那個欄位按下右鍵，Page Scripting > Add conditional steps when，然後將條件屬性設置為True，那麼從這個步驟以後操作的步驟就是只有這個欄位是 True 的時後才會執行，這時選完這個客戶在對過帳日期設 Validate，就能完成只在特定條件下執行的流程了。
要留意的是這個條件盡可能是當下頁面上某個欄位的條件，然後條件的流程中是檢核該頁面上的某些欄位，離開流程後才做關閉頁面、跳轉頁面等操作。
．小結
Page Scripting 既有的功能，或許還有更多的情境和運用可以套入，這是一個偏向自己使用時會更加能去了解此工具的實用性或可運用範圍的功能，例如它甚至可以去設計”等待”這件事，就是到此步驟後等待幾秒，才進行下一步，更多的用法與細節，就由讀者們自行去嘗試了。
現今缺陷與未來
說了如此多，簡而言之就是這工具可以幫我們進行一定程度的除錯…嗎?
假設說你曾經了解過何謂自動化測試，Test Code相關的資訊，其實可以轉個觀念，其實透過Page Scripting去做測試，就是把Test Code的部分概念與流程放在這個工具執行流程的部分驗證中。
舉個例子我們在 Test code 中可能會準備部分的”測試用”資料，有時會限定死測試資料的部分規格，例如某些欄位的值必須是多少。而但透過 Page Scripting 則可以突破這個限制，只是如同前面舉例的在銷售發票上”指定”單價為多少這種操作，必須讓部分的參數能固定在一個值，這樣才有辦法明確定義驗證的值為何。
舉例來說我們都能明白如果單價為50，數量為5，那麼金額應該是50 * 5 = 250，但是也許系統在計算金額的時候，會受到其他許多欄位的影響，導致計算的結果並不會等於250，因此我們可能就要事先將其它會導致這個金額變化的因素相關欄位要定義好，否則如果只是很普通的使用Page Scripting去操作流程，隨意的選一個單據，隨意地讓系統代入單價數量，結果你的金額就不正確了。
當然如果想像寫程式一樣透過其他欄位去判斷也是可以的，要透過前面所提的 Formula reference 的格式代換，透過”變數”的方式去驗證資料的正確性，但如果做得太複雜就可能本末倒置，建議盡量單純化，值為多少就是多少那樣會比較合適。
此外，Page Scripting 不建議做的複雜，其實應該將每一組 Page Scripting 的錄製都視為一個 Test function，也就是一個小型的情境或”一個功能”測試，不應把一整個產品或 App 所有的功能整個放置在一個錄製中，這會導致後續假設你有”編輯需求”會變得繁雜化。
還有一個需要注意的地方，Page Scripting 運行後造成的影響是不可逆的，舉例來說如果流程中把一筆單據過帳，那麼你每次執行一次都會讓一筆新的單據過帳，因此這種流程不適合直接在正式環境中運行。
當然，我也明白一點，當需求龐大、變化如此快、功能複雜的開發情境下，想要拆解成 Page Scripting 的一份份錄製，這是可以簡單、也可以複雜的事，簡單的是如果是純錄製播放，也就是為了當成使用功能的流程”指引”而做的錄製，那並不是難事；困難的是如果將其視為一種除錯工具，就要有許多的考量。
但是這就是微軟提供的一種最便捷的測試工具，或許它存在很多不足，設計也沒有如 Test code 一樣更加嚴謹，但是它能作為一種演示工具同時又是基礎的測試工具，也許它並非是必要的，但如果想設計”程式自動測試”，這可以作為一個開始，甚至於連非技術人員都能夠不透過程式碼的方式去簡易的構思出流程，這裡就提到它的一個好處了，若有一個客戶發現問題，假設客戶或前端顧問有一點點的能力的情況，就能直接在自己環境中透過 Page Scripting 進行操作並且在最後有問題的地方去設驗證這個值，然後將這個錄製匯出丟給後面的技術顧問，讓技術顧問在自己環境中去執行判斷問題，這也就可以成為一種很純粹的顧問間的交流工具，也許可以省下前端與後端顧問還需要開會操作交流，或者錄製操作影片的時間。
