Groovyの実行環境を用意する(SoapUIを用いた自動化の準備)
■はじめに
最近は工数削減、自動化の流れが流行りなのでSoapUIの便利な使い方を学習して、手作業でデータ投入しているところを自動化を図ります。 SoapUIで自動化したいと思った際に避けて通れないのがGroovyです。 まずはGroovyの実行環境の構築方法を説明します。
■環境
■インストーラーのダウンロード
Windowsの場合はインストーラーがありましたのでそれをダウンロードします。 今回は 3.0.9をインストールしていきます。
下記URLにアクセスします。
The Apache Groovy programming language - Download
画面中ほどにある「Windows Installer」をクリックします。
このリンクを押下すると、ダウンロード用のリポジトリに飛びます。 そこで、「groovy-3.0.9.msi」をクリックしてダウンロードします。
■インストーラーでインストール
ダウンロードしたインストーラーの画面に従ってインストール作業を進めていきます。このインストールにはAdmin権限が必要です。
インストールのタイプを選択する画面が出てきますので、今回は「Typical」を選択してインストールします。
インストールが完了するとデスクトップに「Groovy Console」と「Groovy Shell」のアイコンが出来上がります。
■Groovyのテスト
インストールしたGroovyが正常に動くか 「Hello World!」を表示するスクリプトを作成し実行してみます。 まず、「Groovy Console」を起動します。
画面上部に下記スクリプトを記載します。
println "Hello World!"
記載したら画面上部の「Script」を選択し、「Run」を選択します。画面下部にHello World!と表示されたら実行テストは完了です。
■おわりに
これでGroovyの実行環境ができました。次回はまだSoapUIに触れずに、Groovyで記述した簡単なスクリプトを紹介していきます。 必須でやりたいのはcsvファイルの読込となります。
メールの送信試験用にSMTPサーバを立てる(smtp4dev)
■はじめに
アプリケーションにはよくEメールを送信したいというケースがあると思います。 Eメールの試験では、文面や、from、toのアドレスが想定通りかどうかなど確認項目がいくつかあります。 ただ、実運用しているSMTPサーバにリクエストを出してしまうと、Eメールが相手に届いてしまい迷惑になってしまうことがあるため、 試験用にSMTPサーバを立てる必要が出てきます。 今回は試験用にSMTPのリクエストを受領し応答を返却するsmtp4devをWindows上で動かした際の動作などを記載していきます。
■試験用のSMTPサーバのアプリケーションはどんなものがあるか
いろんなアプリケーションがあります。
例えば
などがあります。それぞれ特色があるので環境やニーズにあったアプリケーションを利用すると便利です。
今回は現在も継続的に更新がされており、Windows環境で簡単に動かせそうなsmtp4devについて記載していきます。
■smtp4devとは
smtp4devはダミーのSMTPサーバのアプリケーションとなっており、Windows, Linux, Mac OSのソースコードがあり簡単に導入できるアプリケーションとなっています。 もちろんdockerもあります。
今回はWindowsで動かしていきます。本記事の動作環境は下記となります。
■環境
- ホストOS: Windows 10 home 64bit
- smtp4dev: 3.1.3.2
■動かし方
単純に動かしたい場合は、ダウンロードして解凍したフォルダ内にある Rnwood.Smtp4dev.exe をダブルクリックします。 そうすると、コンソールが立ち上がりsmtp4devが起動します。 各種SMTPサーバの設定は、同フォルダ内の appsettings.json を編集します。
■デフォルトで使用するネットワークポートと設定
smtp4devではデフォルトで下記ポートを利用します。
SMTP ServerとIMAP Serverのポート番号については、設定ファイルで変更が可能です。Web UIについて起動時のオプションで設定変更が可能です。 また、Web UIはデフォルト起動時はローカルホストからのみ接続が可能となっており、リモートの別マシンからWeb UIにアクセスしたい場合は、起動時に --urls オプションを利用します。
■受信したメールはどこに保管されるか
デフォルトでは APPDATA の中に保管されます。エクスプローラーで「%APPDATA%\smtp4dev\」にアクセスすると、database.dbというファイルが出来上がっておりその何か受信したメールの情報が入っています。 これはSQLiteのファイルとなっています。
■いろいろといじってみる①リモートの別マシンからWeb UIにアクセスしてみる。
デフォルトのネットワーク設定だとWeb UIにリモートからアクセスできないので、コマンドラインからexeファイルを起動する際に --urlsオプションを付けてみます。
> Rnwood.Smtp4dev.exe --urls=http://*:5000
こちらのコマンドではurlsオプションで外部から5000番ポートにアクセスできるようにしています。ホストマシンのセキュリティソフトやセキュリティ設定または、Firewallで通信ポートが閉じられているとアクセスできないので注意してください。
私は同じローカルエリアネットワークにいるiPhoneから接続を試してみたところ、うまくページが表示されず苦戦しました。 単純に5000番ポートのみアクセス許可すると、画面は開けるが右上のsmtp serverの稼働状況のところはタイムアウトします。 ソースコードまだ読んでいないのですが、Windowsの場合はリモートプロシージャコールなども考慮する必要がありそうです。
また、Web UIにアクセスするブラウザが古い場合は、smtp4devのロゴとloadingのメッセージのみ表記となります。
Web page just shows smtp4dev logo and "Loading..." · Issue #353 · rnwood/smtp4dev · GitHub
■いろいろといじってみる②Windowsのサービスに登録する
GithubのinstallationのページにWindowsサービスへの登録コマンドがあるので実行してみます。 管理者権限でコマンドプロンプトを立ち上げ下記コマンドを実施する。Rnwood.Smtp4dev.exeはC:\smtp4devに配置しました。
> sc.exe create Smtp4dev binPath= "C:\smtp4dev\Rnwood.Smtp4dev.exe --service"
そうするとSmtp4devというサービスが登録することができました。serviceに対応しているのは便利ですね。 ただこのままだとWeb UIの起動がデフォルトのままなので、外部からアクセスすることができません。 先ほどの外部からの設定と同じようにurlsオプションを設定します。
> sc.exe create Smtp4dev binPath= "C:\smtp4dev\Rnwood.Smtp4dev.exe --service --urls=http://*:5000"
こうすることでサービス起動時も外部からWeb UIにアクセスすることが可能になりました。
ちなみにWindowsサービスで%APPDATA%はどこを挿すかというと下記になります。
C:\Windows\System32\config\systemprofile\AppData\Roaming
こちらの下にsmtp4devのフォルダが作成され、database.dbなどのファイルが配置されます。
■おわりに
今回はsmtp4devについて紹介しました。開発者の方も積極的に更新をされているので、今後の成長も見込めてよいアプリケーションと個人的に思います。 ただ連続でリクエストを送るとエラーになる確率が高そうなので、あくまで時々テストするとかがよいのかなと思いました。
MailDevも気になっているのでsmtp4devでしばらく動かしてみて至らない点があったらMailDevについても調べようと思います。
SQL Serverを初めて運用する人におすすめの本
Amazonで技術書を検索していたところ、 私が新卒入社した時にお世話になった本がリニューアルされたものを見つけたので記事にしたいと思います。
■はじめに
世の中には多くのDB製品があり現場によって使用している製品は異なります。 SQL Serverを利用している現場だった場合に読んでおくと便利な本がありますので紹介させていただきます。
前置きとしてSQL Serverのバージョンごとに本が出版されていたりします。 特定バージョンの操作方法やインストール方法を知りたいのであれば各バージョン本を購入したらよいかと思います。
■SQL Serverの古いバージョンについて勉強したいとき
2021年になってSQL Server 2000? SQL Server 2005?ってそんな古い製品を使っている現場はあるのかって思うかもしれません。 システム刷新等に積極的ではない会社は十分に現役で利用しているのではないでしょうか。
そんな現場の場合は下記本をお勧めします。
絵で見てわかるSQL Serverの内部構造 (DB Magazine Selection)
- 作者:平山 理
- 発売日: 2009/03/03
- メディア: 単行本（ソフトカバー）
私は2013年の6月にこちらの本を購入しました。 SQL Server 2000などはWebの記事等は残っているかもしれませんが、どんどん情報がなくなっていきます。 また最新の本だと情報が新しく、古いバージョンにはない機能の紹介も多かったりします。 そんな中で基本的な挙動を学習するにはこちらの本がおすすめです。 SQL Serverはどう動いているのか？をしっかり勉強することができます。
■新しめのSQL Server(SQL Server 2012以降~）のバージョンについて勉強したいとき
上記で紹介させていただいた本のリニューアルが2020年にありました。 そちらが下記になります。
- 作者:平山 理
- 発売日: 2020/09/14
- メディア: 単行本（ソフトカバー）
SQL Server 2012で登場した列ストアインデックスや、SQL Server 2014で登場したインメモリOLTP、SQL Server 2016で登場したクエリストアなど、 新しめのSQL Serverの機能について紹介されている点が、以前の書籍との大きな違いとなります。 SQL Serverは多くの機能を提供しており使いこなすには、表面上の実装テクニックだけではなく仕組みを理解することが重要です。 また、前作と同様に後半にトラブルシューティングも記載されておりよく起きる事象についてあらかじめ学習できるのもよいと思いました。
■2冊とも買う必要があるのか？
ここは個人的な意見になりますが、例えばSQL Server 2016を利用してる現場であれば、2つ目に紹介させていただたリニューアル本のみで十分と考えています。 また、SQL Server 2000~2008R2利用している現場であれば、1つ目に紹介させていただいた本のみで十分と考えています。 理由は新機能部分以外目次は大体一緒なためです。
■おわりに
今回私が気になった本を紹介しました。 新年度になって部署異動や、現場の変更、はたまた新卒/中途入社など多くの人の移動がある時期と思います。 SQL Serverを利用する現場になった際は、こちらの本を手に取っていただけたら幸いです。
SQL Server から PostgreSQL への移行について
お久しぶりです。ひよです。私はコロナ下でも在宅ワークしながら生きています。 今日は久々に記事を書きたいと思います。
■はじめに
いままでSQL Server向けの開発および運用をメインにしていたのですが、PostgreSQLも使っていきたいという声がありました。 そこでSQL ServerからPostgreSQLへの移行を行う際の参考になるサイトがあったので情報をまとめたいと思います。
今回参考にしたのはこちらです。
PostgreSQL エンタープライズ・コンソーシアム : 活動報告トップページ
こちらのサイトの情報をまとめているが"PostgreSQLエンタープライズ・コンソーシアム"という団体です。 詳細についてはこちらをご確認ください。
それでは本文記載していきます。
■DB移行時に何をしなきゃいけないの
DB製品を変更するときは大きく下記2つの移行を行う必要があります。
- データの移行
- アプリケーションの移行
それぞれについて記載していきたいと思います。 一部筆者の思いが書かれている部分もありますのでご了承ください。
初めて実施される方はどのような作業が必要か全体を把握しておいた方がよいため下記2つの資料が参考になります。
■データの移行
DB製品を変更するときにデータの移行は重要になってきます。過去データはすべて捨ててよいというような要件はまずないのではないかと思います。
一般的に移行元のDBからデータを抽出し、移行先のDBにインポートできる形に変換しインポートを行います。
- SQL Serverではinsert文を作り出すようなdumpコマンドがないので、CSV形式のファイルに出力します。
- 出力したCSVファイルについて、改行コードの変換や、文字コードの変換を行いPostgreSQLにインポートできる形に整形します。 ※何を変換するかは、それぞれの環境によって文字コードも異なりますし、ご自身の環境に合わせて対応が必要となります。
- PostgreSQLでは、COPYコマンドでCSVファイルをテーブルに取り込みます。
上記3ステップだけなので簡単かと思いますが、データ量が多い場合は作業を行う環境により、CSVファイルの作成およびファイルの転送時間、CSVファイルの加工処理時間、PostgreSQLへのデータ取込み時間がそれぞれかかってきますので、予定通りの時間内で各作業が終了するのかを確認することが大切です。
また、上記ではCOPYコマンドの紹介をしていますが、PGEConsのレポートでは、COPYコマンドだと異常時に全件ロールバックがかかるため、"pg_bulkload"を利用することを推奨していました。
データ移行については下記URLが参考になります。
■アプリケーションの移行
データ移行と同様に重要なのがアプリケーションの移行となります。アプリケーションといってもいくつか種類があるのと、現在の作り方によって異なるため対応は環境により千差万別と思います。
DB製品が変わると例えばDB上にユーザが作成したプログラムの"ストアドプロシージャ"や、DB製品が用意している組み込み関数の有無などが発生することと、SQLの書き方なども影響してきます。 例えばSQL ServerとPostgreSQLの差としては、PostgreSQLにはPROCEDUREはないため、FUNCTIONで代用する事になります。またSQL ServerではUUIDを発行する関数がデフォルトでありますが、PostgreSQLでは追加モジュールをインストールしないと使えません。
SQLの書き方については箇条書きですが下記影響があります。
- TOP句がないため、LIMIT句などに書き換える。
- 列の別名について、標準SQLではない記載をしている箇所は標準SQLに書き換える。
- INSERT文のINTOが省略されていた場合、省略できないため書き足す。
- DELETE文のFROMが省略されていた場合、省略できないため書き足す。
- OUTPUT句はPostgreSQLにはない。
- MERGE文はPostgreSQLは対応していないため、書き換える必要がある。
- PostgreSQLはVIEWに対しては更新できない。
- 文字列リテラルの区切り文字に二重引用符は使えない。
- 識別名を表す時に角括弧は、二重引用符に書き換える。
- 文字列連結の時は、+を || 演算子に置き換える。
- LIKE演算子の中で文字クラスを扱っている部分は書き換える。 などなどこれ以外にも差があります。
これらを書き換えて問題なくコンパイルが通る形にしたうえで十分に試験を行う必要があります。 こういった一覧をすべてにまとめてくれているものがあるのはとても役に立ちますね。
アプリケーション移行については下記URLが参考になります。
■おわりに
今までSQL Serverについて詳細を勉強してきていたのが今後PostgreSQLとかに変更されていくと、私会社にいらないんじゃないかなと思いました。 今後の身の振り方を考えるタイミングが来たのかも知れません。
pm2でNode.jsのプロセスを永続化する
■はじめに
遅くなりましたが2020年あけましておめでとうございます。今年もよろしくお願いします。
久々に投稿はNode.jsに関するものとなりました。
Expressを使用したアプリで予期せぬエラーが発生するたびにプロセスが停止してしまい、対応工数が膨らんでしまっているため、プロセスの永続化方法を調べました。
node.jsのプロセスをデーモン化するツール
「node デーモン」で検索するとforeverとpm2という2つのツールがヒットしました。npmのサイトを見るとpm2の方が週間ダウンロード数が多いのと、管理画面がかっこよかったのでpm2を試してみることにします。
Expressのサイトにもプロセスマネージャーのページがあったため、こちらを参考にしていただけるといいと思います。Express アプリケーション用のプロセス・マネージャー
早速実機で起動確認をしていきます。
■テスト環境
- OS: Windows Server 2016 Standard
- Node: v12.15.0
- npm: 6.13.4
- express-generator: 4.16.1
- pm2: 4.2.3
■アウトライン
- Nodeアプリケーションの準備
- pm2のインストール
- pm2の実行
1. Nodeアプリケーションの準備
Nodeアプリケーションはexpress-generatorで作成したものを使用していきます。
以前の下記記事と同じように実行します。
テスト環境ではまっさらなOSにNode.jsをインストールしています。
npm startを行い画面が表示されたのでアプリケーションの準備はOKです。
2. pm2のインストール
pm2については下記コマンドを実行することでインストールできます。
プロセスマネージャーはNodeをインストールしたマシンで共通で利用するべき機能だと思うため、globalインストールしています。
# npm install -g pm2
Windows環境だと一部のモジュールのOSが対応していないみたいでSKIPされましたが、無視して進みます。
3. pm2の実行
pm2でexpress-generatorで作成したアプリを起動してみます。 pm2の基本的な実行方法は、
# pm2 start app.js
となっています。筆者のサンプルはexpress-generatorで作成したアプリなので、このアプリの起動方法を検討します。いくつか方法があるようですがそのうち一つだけ紹介します。
簡単にググってみると下記コマンドで起動できるという記事を目にしましたが、Windows環境からなのか正常に起動しませんでした。
# pm2 start npm -- start
※pm2コマンドは成功したように見えますが、pm2 startしてもstatusがonlineにならずerrorとなりました。
解決策npmの起動スクリプトを直接実行する
「npm start」コマンドを実行したときの起動コマンドはpackage.jsonに記載されています。 デフォルトだと
"start": "node ./bin/www"
と記載されているので、その通りに実行します。
# pm2 start ./bin/www
下記ログが表示されました。
# pm2 stop 0
下記ログが表示され、statusがstoppedとなっており停止されています。またhttp://localhost:3000にアクセスするとページが表示されなくなりました。
■おわりに
Windows環境で今回テストを行いましたが、CentOSなどのLinux環境だとpm2がそのまますんなり起動できるのか気になるところです。
どちらにせよ起動はできましたが、内部処理の挙動がわかっていないのでプロダクション環境にデプロイするのはまだ先になりそうです。
それまでは古典的ですがwindowsタスクスケジュールからプロセス監視の処理を流し続けます…
tSQLt のアサーションを紹介する
■はじめに
tSQLtについて引き続き勉強したことを記載していきます。
本記事ではtSQLtのアサーションについて紹介します。
■Assertions
tSQLtの公式ドキュメントに下記ページがあります。
このページではtSQLtが用意してるアサーションのストアドプロシージャと、
失敗のストアドプロシージャが記載されています。
シンタックスは公式ページを見てもらえればと思います。
AssertEmptyTable
AssertEmptyTableストアドプロシージャは、第一引数のテーブルが空かどうかをチェックします。
例ではビューの結果セットが空かどうかをチェックするコードが記載されています。
AssertEquals
AssertEqualsストアドプロシージャは、第一引数の値と、第二引数の値が一致しているかどうかをチェックします。
ドキュメントのページでは、オブジェクトの型も比較した例が記載されていてわかりやすいです。
AssertEqulasString
AssertEqualsStringストアドプロシージャは、第一引数と第二引数の文字列が一致しているかどうかをチェックします。
NullとNullではない文字列はエラーとなります。
AssertEqualsTable
AssertEqualsTableストアドプロシージャは、第一引数のテーブル名のテーブルと、第二引数のテーブル名のテーブルの中身を比較し同一の場合は成功となります。
AssertEqualsTableScheme
AssertEqualsTableSchemeストアドプロシージャは、第一引数のテーブル名のテーブルと、第二引数のテーブル名のテーブルのスキーマを比較し同一の場合は成功となります。
AssertEqualsTableはテーブルの中身を比較するのに対して、AssertEqualsTableSchemeはテーブルのスキーマを比較しています。
AssertLike
AssertLikeストアドプロシージャは、第一引数のパターンと、第二引数の値を比較し一致するパターンの場合は成功となります。
AssertNotEquals
AssertNotEqualsストアドプロシージャは、第一引数と第二引数の値が一致してない場合に成功します。
AssertObjectDoesNotExist
AssertObjectDoesNotExistストアドプロシージャは、第一引数のオブジェクトがない場合に成功します。
AssertObjectExists
AssertObjectExistsストアドプロシージャは、第一引数のオブジェクトが存在する場合に成功します。
Fail
Failストアドプロシージャは、実行された場合に失敗を返します。引数にエラーメッセージを記載することができます。
■おわりに
アサーションも多くの種類が用意されており、単体でテストの結果判定には十分なのではないかと思いました。
残りのExpectationsとIsolating dependenciesを学んだら実際の単体テストの例を記載できたらいいかなと思ってます。
tSQLtでテストケースの作成と実行を行う
■はじめに
ひとつ前の記事でtSQLtのインストールについて記載しました。
これからtSQLtの用意する処理を公式ドキュメントをもとに勉強します。
ひとつ前の記事
■Test Creation and Execution
tSQLtの公式ドキュメントに次のページがあります。このページについて本記事では紹介します。
このドキュメントのページではテストクラスを作成するとどうなるのか？と、テストクラスを実行するとどうなるのかが記載されています。
テストクラスを作成するとどうなるのか？
tSQLt.NewTestClassを用いてテストクラスを作成するとスキーマが作成されます。このスキーマを用いてテストクラスを識別して実行します。注意点はすでに同じスキーマがあった場合ははじめに削除してから作成されます。
テストクラスを実行するとどうなるのか？
- テストクラスのスキーマ名のすべてのストアドプロシージャを調べ、これらをテストケースとみなします。
- 各テストケースについて下記処理が実行されます。
- すべてのテストケースが完了すると、コンソールに結果が表示されます。
テストケースの実行用のストアドプロシージャに、tSQLt,RunTestClassとtSQLt.RunAllの2種類があります。tSQLt.RunTestClassは引数のスキーマ名のテストクラスを実行します。tSQLt.RunAllはデータベース内のすべてのテストクラスを実行します。
■関連するストアドプロシージャ
ドキュメントサイトには下記ストアドプロシージャについて説明があります。シンタックスなどはドキュメントを参照いただくとし、簡単に概要を記載します。
DropClass
引数のスキーマ名のテストクラスを削除します。スキーマの中に存在するテストケース（ストアドプロシージャ）も削除されるので注意して実行するのをお勧めします。
NewTestClass
引数の名前のテストクラスのスキーマを作成します。すでに同名のスキーマが存在する場合は、存在するスキーマを削除したのち作成します。
RenameClass
第一引数のテストクラスを、第二引数のテストクラス名に変更を行います。テストクラス名を変更した場合は、変更対象のテストクラス内のストアドプロシージャのスキーマ名も変更になります。
Run
引数のテストクラスを実行します。tSQLt.RunTestClassとの違いは、tSQLt.Runの場合は第二引数にテスト結果のフォーマットを指定することができます。指定できるフォーマットは後ほど調べてわかったらコメントに記載したいと思います。
RunAll
データベース内のすべてのテストクラスを実行します。
■おわりに
導入しようとしているフレームワークがどのように動作するのかを把握するのは、非常に大事だと思っています。ブラックボックスのままだと、何か問題が起きた場合にどこが問題かわからないので、公式ドキュメントをもとに基本的な動作を学べました。次の記事もまた公式ドキュメントをもとに、アサーションについて記載していきたいと思います。
