2024年8月30日金曜日

Windows11 に php をインストールする方法

Windows11 に php をインストールする方法

概要

インストーラはないのでダウンロードして適切な場所に配置して設定ファイルを編集します

環境

  • Windows11
  • php 8.3

ダウンロード

https://windows.php.net/download ここから最新の zip ファイルをダウンロードします

展開し C 直下に配置

ダウンロードしたファイルを展開しディレクトリをリネームし C 直下に配置します
執筆時点では php-8.3.11-nts-Win32-vs16-x64 というディレクトリ名なのでこれを php に変えれば OK です

C:\php という感じで配置します

php.ini の作成

C:\php\php.ini-development をコピーして C:\php\php.ini を作成します

拡張機能の有効化

例えば mysqli という拡張を有効にしたい場合は php.ini の以下の部分を修正します

extension=mysqli
extension_dir = "C:\php\ext"

という感じで拡張機能があるパスと有効にしたい拡張機能のコメントを外せば OK です

動作確認

コマンドプロンプトを起動します

cd c:\php
php -v

でバージョンが表示されれば OK です
cd しないで php コマンドを使いたい場合は PATH に通しましょう

おまけ: cgi サーバを起動する方法

nginx で php を動かす場合に必要です
コマンドプロンプトで以下を実行しましょう

cd c:\php
start php-cgi -b 127.0.0.1:9000

おまけ: 動作には Visual C++ のランタイムが必要

https://learn.microsoft.com/ja-jp/cpp/windows/latest-supported-vc-redist?view=msvc-170 ここから X64 版をダウンロードしてインストールすれば OK です

最後に

windows11 で php を動かす場合にはインストーラはないので zip をダウンロードして配置するようにしましょう
アンインストールする場合はディレクトリを削除すれば OK です

2024年8月29日木曜日

ServiceNow 個人学習リンクまとめ

ServiceNow 個人学習リンクまとめ

アカウント取得から簡単なアプリ作成、ワークフロー作成、MIDServer インストールあたりを網羅している学習コンテンツです

環境

  • ServiceNow (2024/08/05 時点)
    • Release Washington DC

一覧

その他

  • Publish は PDI 環境ではできません
  • PDI 環境では Store は使えません

2024年8月28日水曜日

ServiceNow の開発画面を日本語化する方法

ServiceNow の開発画面を日本語化する方法

概要

Application Manager で日本語化プラグインをインストールします

環境

  • ServiceNow (2024/08/05 時点)
    • Release Washington DC

プラグインのインストール

All -> Application Manager を検索します

プラグインの検索画面で「Japanese」を入力します
「I18N: Japanese Translations」というプラグインが表示されたらインストールしましょう

インストールには数十分かかります
完了すると Installed タブに表示されます

あとはユーザの設定から言語を変更します
Preferences -> Language & Region -> Language で日本語を選択します

ダイアログを閉じると反映が開始されます
ちょっとラグがありますがしばらく待つと日本語化された画面が表示されます
おそらく自動で日本語化しているので一部の箇所は日本語化されていないので注意しましょう

最後に

戻したい場合は Language を English にすれば OK です
正直サービス名で検索できなくなってりするので英語のままのほうがいいと思います

2024年8月27日火曜日

ServiceNow の Workflow Studio を使ってワークフローを作成してみる

ServiceNow の Workflow Studio を使ってワークフローを作成してみる

概要

Workflow Studio はワークフローを作成するのに適したツールです
今回は簡単なワークフローを作ってみました

環境

  • ServiceNow (2024/08/05 時点)
    • Release Washington DC

Workflow Studio を開く

トップページから開きましょう

フローの一覧が表示されます

フローを作成する

右上の New -> Flow を選択してフローを作成します

今回は新しいレコードが追加されたらそのコピーのレコードを自動的に追加する簡単なフローを作成します

まずはフローの名前を決定しフローを登録するアプリを入力します

フローを定義する画面に移動します

フローの定義

まずはトリガーを作成します
トリガーはフローが実行されるトリガーです
今回は「新しいレコードが作成されたら」がトリガーになります

Add a trigger を選択して追加します

今回は Created でテーブルはアプリに紐づいているテーブルを選択します
Done を選択してトリガーを作成します

次にアクションを追加します
Add an Action で追加できます
アクション以外にも次のフローを追加することができますが今回は簡単なアクションを1つだけ追加します
追加するアクションは「コピーのレコードを追加する」になります

Action を選択すると様々なアクションが表示されるので「Create Record」を選択します

レコードを追加するテーブルを選択しレコードに追加する内容を決定します
Fields -> Add field value を選択します

今回入力された情報のコピーのレコードを作成します
Workflow では前のフローの情報を fd_data というオブジェクトから参照することができます

name というカラムに対して入力された値に「copy_」というプレフィックスを付与してコピーレコードを登録するようにします

その場合にはフィールドの値にスクリプトを指定することができます
フィールドの横にスクリプトを指定するボタンがあるので押すとスクリプトを入力できます
今回は以下を登録します

return "copy_" + fd_data.trigger.current.name

入力できたら Save で登録します

動作確認

ワークフローが作成できたらテストしてみます
右上の Test からテストできます

新規で登録するレコードの情報を入力し Submit します
パラメータを入力したら Run Test でワークフローが開始されます

するとワークフローが始まります
結果を確認する場合は「Your test has finished running. View the flow execution details.」を選択すると確認できます

ワークフローが完了していることが確認できます

更に実際にデータを確認するとちゃんと copy がついたレコードも作成されていることも確認できます

最後に

Workflow Studio でワークフローを作成するのがモダンなワークフローの作り方っぽいです
同様のツールに Workflow Editor がありますが最近は Workflow Studio を使うのが良いようです

過去に Logic and automation を使ってワークフローを作成しましたがどうやら Workflow Studio で作った場合も Logic and automation に紐づくようです

2024年8月26日月曜日

MID Server に任意のスクリプトファイルをデプロイする方法

MID Server に任意のスクリプトファイルをデプロイする方法

概要

前回任意のスクリプトを実行する方法を紹介しました
今回は自分で作成した任意のスクリプトを MID Server 上にデプロイする方法を紹介します

環境

  • ServiceNow (2024/08/05 時点)
    • Release Washington DC
  • Ubuntu 22.04
  • MID Server 2023-12-20

スクリプトの追加

All -> MID Server Script Files

一覧から New で追加します

  • Name -> 好きな名前を入力します
  • Parent -> SSHScriptFiles
  • Script -> 好きなシェルスクリプトを入力します

Parent はディレクトリ名に使われます
シェルスクリプトは SSHScriptFiles を指定するのが良さそうなので SSHScriptFiles を指定しましょう

作成できたら Submit/Update を選択します

同期の確認

スクリプトを作成するとすぐに同期が始まります
/opt/servicenow/mid/agent/scripts/ServiceWatch/SSHScriptFiles/show_hostname.sh 実行権限はないので手動で設定しましょう

ls -l /opt/servicenow/mid/agent/scripts/ServiceWatch/SSHScriptFiles/show_hostname.sh
-rw-r--r-- 1 devops docker 8 Aug 19 12:19 /opt/servicenow/mid/agent/scripts/ServiceWatch/SSHScriptFiles/show_hostname.sh

最後に

ServiceNow から MID Server に対して任意のスクリプトを配置する方法を紹介しました
シェルスクリプトだけでなく好きなファイルを配置することもできます
またディレクトリだけを配置することもできます

配置先のパスのルールは決まっているので別のパスにデプロイしたい場合は他のスクリプトを実行するか手動でシンボリックリンクや移動してあげましょう

2024年8月25日日曜日

Python の unittest mock を使って requests の get をモックする方法

Python の unittest mock を使って requests の get をモックする方法

概要

unittest の mock を使って request.get をモックする方法を紹介します
更に pytest の fixture を使います

環境

  • macOS 11.7.10
  • Python 3.11.6
  • requests 2.32.3
  • pytest 8.2.2

サンプルコード

httpbin にリクエストしてその結果を dict に変換します

import requests


class HttpBinClient:
    def __init__(self) -> None:
        pass

    def fetch(self) -> requests.Response:
        return requests.get("https://httpbin.org/get")

    def to_json(self, response: requests.Response) -> dict:
        return response.json()


if __name__ == "__main__":
    hbc = HttpBinClient()
    res = hbc.fetch()
    print(hbc.to_json(res))

テストコード

httpbin のレスポンスには url というフィールドがありアクセスした url が含まれているのでそれが正しいかテストするコードを作成します

  • vim test/test_app.py
from app import HttpBinClient


class TestHttpBinClient:
    def test_fetch(self):
        hbc = HttpBinClient()
        response = hbc.fetch()
        result = hbc.to_json(response)
        assert result["url"] == "https://httpbin.org/get"
  • pipenv run pytest -s test/test_app.py

これで実行すると問題なく成功します
今回はこのテストにおいて requests.get で実際に外部にリクエストする部分をモックします

モックする conftest

conftest を使ってモックします
ポイントは requests.get に patch を当てつつ更にレスポンスのオブジェクトを正しく生成することです

  • vim test/conftest.py
from unittest.mock import Mock, patch

import pytest
import requests


@pytest.fixture(autouse=True)
def mock_request_get():
    with patch("requests.get") as m:
        # requests のレスポンスオブジェクトを生成、理由は requests.get の返り値の型が requests.Response なため
        response = requests.Response()
        # json 関数をモックします、関数をモックする場合は Mock クラスを使って return_value でその関数の返り値を指定します
        response.json = Mock(return_value={"url": "http://localhost"})
        response.status_code = 200
        # あとはモックオブジェクト (requests.get) の返り値に対してモックしたレスポンスを割り当てます
        m.return_value = response
        # 今回は with 句を使って patch しているため yield でモックオブジェクトを指定しなければいけません
        yield m

動作確認

  • pipenv run pytest -s test/test_app.py

で先程成功したテストが失敗することを確認します
モックでは実際にアクセスしないのでモックに指定した偽の返り値になるためエラーになります

最後に

pytest + unitest mock で requests.get をモックしていました
同じように post などもモックできます

2024年8月24日土曜日

MID Server で任意のコマンドを実行する方法

MID Server で任意のコマンドを実行する方法

概要

MID Server をインストールしたマシン上で任意のコードを実行する方法を紹介します
MID Server のインストール方法はこちらを参照してください

環境

  • ServiceNow (2024/08/05 時点)
    • Release Washington DC
  • Ubuntu 22.04
  • MID Server 2023-12-20

実行するスクリプトの配置

まずは実行するスクリプトと MID Server 上に配置します
今回はインストール時に配置される /opt/servicenow/mid/agent/scripts/ServiceWatch/SSHScriptFiles/cpus.sh を使います

実行権限だけ与えてあげましょう

  • chmod +x /opt/servicenow/mid/agent/scripts/ServiceWatch/SSHScriptFiles/cpus.sh

ECC Queue の追加

ServiceNow のインスタンスから MID Server 上でコマンドを実行するにはキューにコマンド情報を登録します

All -> ECC Queue で移動します

そして New から新規でキューイングする情報を追加します

追加画面になったら実行するコマンドの情報を記載します

  • Agent -> mid.server.My_Linux_Mid_Server
  • Topic -> Command
  • Name /opt/servicenow/mid/agent/scripts/ServiceWatch/SSHScriptFiles/cpus.sh
  • Queue -> input

Agent は自身の登録した MID Server 名を記載してください
Name に実行するスクリプトのパスを指定します
コマンドを実行する場合は Queue は input を指定します

結果確認

コマンドの結果は output Queue で来ます
シェルスクリプトの実行結果が格納されていれば OK です

結果が error になる場合は足りないコマンドをインストールしたりスクリプトを直接編集しても OK です
正しく成功しているのに error になる場合は手動でステータスを変更しても OK です

ただ今回使用した cpus.sh は MID Server Script Files という機能で常に ServiceNow 側と同期しているので編集してもすぐに書き換えられてしまうので注意しましょう

最後に

ServiceNow のインスタンス上から MID Server 上に任意のコマンドを実行する方法を紹介しました
基本ファイルを配置する必要があるのでそれが面倒ですが ServiceNow にはスクリプトを MID Server に配布する仕組みもあるのでそれを使うと簡単にできます
次回はファイルを配置する方法を紹介します

参考サイト

2024年8月23日金曜日

MID Server をインストールする方法

MID Server をインストールする方法

概要

MID Server は ServiceNow が提供するサーバインストール型のエージェントです
これをインストールすることでサーバの情報を ServiceNow に保存することができアラートやメトリックスの表示ができるようになります
今回は Ubuntu サーバにインストールしてみました

環境

  • ServiceNow (2024/08/05 時点)
    • Release Washington DC
  • Ubuntu 22.04
  • MID Server 2023-12-20

ダウンロード

All -> MID Server -> Downloads

で deb 版をダウンロードします
300MB ほどあります

インストール

ダウンロードしたらインストールしていきます

All -> Installation Instructions

でドキュメントに飛べます
各種アカウントなどを作成してからインストールしていきます

MID Server 用アカウントの作成

All -> Users から作成します
ユーザの追加方法は過去に紹介している方法と同様です
適切なロールを設定してあげましょう
また作成できたら ServiceNow にログインできることも確認すると良いかなと思います

なおロールには必ず mid_server ロールが割り当たるようにしてください

deb パッケージのインストール

Ubuntu サーバ上に配置して以下を実行していきます

  • scp mid-linux-installer.washingtondc-12-20-2023__patch4-hotfix1-06-10-2024_06-17-2024_2231.linux.x86-64.deb host01:
  • sudo dpkg -i mid-linux-installer.washingtondc-12-20-2023__patch4-hotfix1-06-10-2024_06-17-2024_2231.linux.x86-64.deb

これで /opt/servicenow/mid/agent/ にインストーラが展開されます
なおインストールするにはディスクの容量が 36GB必要になるのでディスクの容量がない場合は別のパスに移動したりシンボリックリンクで対応しても OK です

  • sudo chmod +x /opt/servicenow/mid/agent/installer.sh
  • sudo /opt/servicenow/mid/agent/installer.sh

ServiceNow のインスタンスの URL や先ほど作成した mid_server ロールのユーザを入力します
証明書や相互認証の部分、プロキシに関しては今回はすべて No で OK です

Enter the ServiceNow Instance URL [https://YOUR_INSTANCE.service-now.com/] : https://dev123456.service-now.com
Do you want to use proxy? [Enter Y or N] : N
Do you want to use Mutual Authentication? [Enter Y or N] : N
Validating the Instance URL...
Enter the username for mid user : mid_server_user
Enter the password for mid user:
Validating the Mid-user details...
Username and password are valid.
Do you want to enable Certificate Revocation? [Enter Y or N] : N
Enter the Mid Server Name [My_Linux_Mid_Server] : My_Linux_Mid_Server
Enter the unique name for the service to be created [mid] : mid
Checking for the uniqueness of the service name...
Enter the long name for the service [ServiceNow_MID_Server] : ServiceNow_MID_Server
Enter the Non-Root User Name to run this service :
You have entered the root user. Please specify a non-root user.
Enter the Non-Root User Name to run this service : devops
*******************************************************************************************

    NOTE: A non-root user can manage a service only when the user has required privileges.
  For more information, refer https://hi.service-now.com/kb_view.do?sysparm_article=KB0815542

*******************************************************************************************
Enter yes for the below displayed prompt if you want to start the daemon with out any errors...
The agent directory is /add_disk1/servicenow/mid/agent
Do you want to block all other user access and change the ownership of the entire agent directory at /add_disk1/servicenow/mid/agent based on the mid.shconf_override settings (Enter yes or YES to confirm) ? yes
Block all other user access...
Change user ownership to devops ...
Change group ownership to docker ...
Detected Linux:
Installing the ServiceNow_MID_Server daemon with systemd...
Creating default service file...
Created symlink /etc/systemd/system/multi-user.target.wants/mid.service → /etc/systemd/system/mid.service.
Starting ServiceNow_MID_Server with systemd...
Waiting for ServiceNow_MID_Server...
running: PID:3711838
Mid is running as a service successfully..

起動しているか確認します

  • systemctl status mid
● mid.service - ServiceNow_MID_Server
     Loaded: loaded (/etc/systemd/system/mid.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2024-08-19 09:47:06 JST; 37s ago
    Process: 3711754 ExecStart=/add_disk1/servicenow/mid/agent/bin/mid.sh start sysd (code=exited, status=0/SUCCESS)
   Main PID: 3711838 (wrapper-linux-x)
      Tasks: 84 (limit: 4513)
     Memory: 258.0M
        CPU: 16.589s
     CGroup: /system.slice/mid.service
             ├─3711838 /add_disk1/servicenow/mid/agent/bin/./wrapper-linux-x86-64 /add_disk1/servicenow/mid/agent/bin/../conf/wrapper.conf wrapper.syslog.ide>
             └─3711883 /add_disk1/servicenow/mid/agent/jre/bin/java -Djava.util.logging.config.file=properties/glide.properties -Dsun.net.maxDatagramSockets=>

Aug 19 09:47:01 host01 mid.sh[3711754]: Starting ServiceNow_MID_Server...
Aug 19 09:47:05 host01 mid.sh[3711754]: Waiting for ServiceNow_MID_Server.......
Aug 19 09:47:06 host01 mid.sh[3711754]: running: PID:3711838

登録されているか確認

All -> MID Servers で確認できます
先ほど登録した MID Server が一覧に表示されることを確認しましょう

検証する

登録したサーバを検証します
先程の登録された MID Server を選択し Related LInks から Validate を選択します

各種確認して Save を選択します

このあと一覧を再度確認して Validated の絡むが Validating -> Yes になれば OK です
うまく Yes にならない場合は MID Server のプロセスを再起動してみましょう

  • sudo systemctl restart mid

ログの場所

/opt/servicenow/mid/agent/logs/agent0.log.0 にあります

最後に

ServiceNow の MID Server を Ubuntu にインストールする方法を紹介しました
MID Server 用のユーザを作成する必要があるのと mid_server というロールを設定するのがポイントです
またインストールするサーバのディスクサイズにも注意しましょう

参考サイト

2024年8月22日木曜日

ServiceNow でアプリのコードを Github と連携する方法 (Source control)

ServiceNow でアプリのコードを Github と連携する方法 (Source control)

概要

ServiceNow で Source control 機能を使って外部の git レポジトリと連携してみます
今回は Github を使います

環境

  • ServiceNow (2024/08/05 時点)
    • Release Washington DC

Github のリポジトリの作成

アプリと同じ名前にするとわかりやすいかもです
作成できればプライベートでもパブリックリポジトリでも OK です (できればプライベートリポジトリがいいかもです)

Personal Access Token の取得

Settings -> Developer settings -> Personal access tokens -> Tokens (classic)

ServiceNow へのクレデンシャルの登録

All -> Credentials を開きます
App Engine Studio ではなくトップページの All から検索すると早いです

開けたら右上の New から新規でクレデンシャルを作成します

Basic Auth Credentials を選択します

あとは先程作成した Github の Personal Access Token の情報を入力すれば OK です
ユーザ名は Github のアカウント名を入力しましょう

アプリから Source Control で連携

App Engine Studio で作業します
アプリを開いて Source control から「Link to source control」を選択します

設定画面が表示されたら Github のリポジトリ情報を登録していきます
ブランチ名はそのブランチに push するとアプリ側にも反映されるブランチになります

入力したら「Link to source control」を選択します

動作確認

連携が完了すると Github 側にアプリのコードがプッシュされていることが確認できます

試しにブランチにプッシュするとアプリ側に設定が反映されることが確認できると思います

クライアントスクリプトやデータソースの設定が XML で管理されていることが確認できます

最後に

アプリを設定などを git リポジトリと連携して直接 XML で管理することができます
慣れればこっちのほうが楽なこともありそうです

git であれば Github でなくてもいいので Gitlab や bitbucket などとも連携可能だと思います

参考サイト

2024年8月21日水曜日

ServiceNow のデータテーブルに REST API でアクセスする方法

ServiceNow のデータテーブルに REST API でアクセスする方法

概要

今までは Experience の Portal や Workspace、Form などからデータテーブルにアクセスしました
今回は REST API を使ってアクセスしてみます

環境

  • ServiceNow (2024/08/05 時点)
    • Release Washington DC

GET

curl -s "https://dev123456.service-now.com/api/now/table/x_1507109_test4_user" \
-X GET \
-H "Accept:application/json" \
-u 'admin':'xxxxxxxxxxxx' | jq .

DELETE

レコードを識別するのは SysID になります

curl -s "https://dev123456.service-now.com/api/now/table/x_1507109_test4_user/cfc966eb83330210114dc170deaad32d" \
-X DELETE \                   
-H "Accept:application/json" \  
-u 'admin':'xxxxxxxxxxxx'

UPDATE

PATCH を使うようです

curl -s "https://dev123456.service-now.com/api/now/table/x_1507109_test4_user/07c966eb83330210114dc170deaad32d" \
-X PATCH \
-H "Accept:application/json" \
-H "Content-Type:application/json" \
-d '{"name":"changed_name"}' \
-u 'admin':'xxxxxxxxxxxx' | jq .

テーブル名の確認方法

App Engine Stduio ならテーブルのプロパティで確認できます

システム関連のテーブルにアクセスするのであれば Tables & Columns などで確認しましょう

API をコールするユーザ

テーブルにアクセスできる権限が必要です
権限はアプリごとにロールベースで管理されているので適切なロールをユーザに割り当ててあげましょう

最後に

ServiceNow の REST API を試してみました
他にもアプリを操作したりアプリレベルの情報も REST API で操作できるので画面でできることはすべて REST API でもできると思います

基本的には外部のシステムと連携する場合に使う感じになるのかなと思います

参考サイト

2024年8月18日日曜日

ServiceNow のテーブルにあるレコードを一括で削除する方法

ServiceNow のテーブルにあるレコードを一括で削除する方法

概要

App Engine Studio だとデータテーブルからレコードを削除する場合 1 行ずつしか削除できません
今回はテーブルにあるレコードを一括で削除する方法を紹介します

環境

  • ServiceNow (2024/08/05 時点)
    • Release Washington DC

方法

すべてのサービスから「Tables & Columns」で検索します

テーブルの一覧が表示されるので対象のテーブルを検索します
検索機能がないので Ctrl +f などで検索しましょう

すべてのレコードを削除するテーブルを選択したら「Delete all records」を選択します

ダイアログが表示されたら delete を入力して OK を選択することがですべてのレコードをが削除されます

最後に

すべてのレコードを削除する場合には App Engine Studio でなく Tables & Columns を使いましょう

参考サイト

2024年8月17日土曜日

ServiceNow でフォーム送信後に完了ページに遷移する方法

ServiceNow でフォーム送信後に完了ページに遷移する方法

概要

過去に独自のフォームを作成してフォームのデータを登録できるようにしました
今回は登録後に完了ページに遷移する方法を紹介します

環境

  • ServiceNow (2024/08/05 時点)
    • Release Washington DC

完了ページの用意

何でも OK です
ポータルを作成した際に自動で作成されたものがあるのでそれでも OK です

不要なボタンなどがあれば削除しましょう
とりあえず今回はトップページに移動するボタンのみにします

ページ遷移用のクライアントスクリプトの追加

フォームのページ (Record Page(request)) に追加します

名前は何でも OK です
スクリプトの内容は以下になります

フォームのアクションが inserted なら登録完了とみなし画面を遷移します

/*
 * @param {params} params
 * @param {api} params.api
 * @param {any} params.event
 * @param {any} params.imports
 */
function handler({
    api,
    event,
    helpers,
    imports
}) {
    // フォーム情報の取得
    const name = api.data.glide_form_1.nowRecordFormBlob.formFieldValues.name.value;
    // アクションの結果が inserted になっているかチェック
    const {
        status: action
    } = event.payload;
    if (action !== 'inserted') {
        return;
    }
    // name が空じゃないなら成功とみなしページを成功ページに遷移する
    console.log("move page!!"); 
        helpers.navigate.to('order_success', {
            // 必要な場合は次のページに context.props を渡す
            // sysId: event.payload.screenParams.sys_id,
            // table: event.payload.screenParams.table
        });
}

遷移先の画面情報は route 情報を文字列として渡します
route 情報は各ページの Settings から確認することができます

フォームにイベントを追加する

次にフォームにイベントを追加します
フォームのテキスト情報がサーバに登録されたり内容が変更された場合のイベントを取得することができます

フォームはデータリソースにあるので出たリソースから Events タグで Add event mapping で追加します

「Screen Status Changed」というイベントがあるのでこれを選択します

Screen Status Changed のイベント時に発火するクライアントスクリプトを選択します
先ほど作成したクライアントスクリプトを選択します

フォームにイベントを追加できたら完了です

動作確認

Preview から確認しましょう
フォームにデータを入力し Submit すると自動で画面が遷移することが確認できます
もし画面が遷移しない場合は action などの条件が正しいか event.payload のなどを確認してみましょう

最後に

フォームでデータ登録後に画面を遷移する方法を紹介しました
過去に Link to destination イベントで画面を遷移する方法を紹介しましたが今回はクライアントスクリプトで遷移する方法を紹介しました

クライアントスクリプトで遷移する場合は helpers.navigate.to を使います