開発者の皆さん、こんにちは！

1つ前の記事では、VSCodeのObjectScriptエクステンションに追加されたRESTサービスのデバッグツールについてご紹介しましたが、この記事では、RESTクライアントなどからHTTP要求を実行し、処理中のIRIS内プロセスにアタッチしながらデバッグを行う方法についてご紹介します。

​ UDL形式でのインポート・エクスポートが出来ない古いCahceバージョンのソースを保守していたり、古くからのバージョン管理下においてXMLでのバージョン管理を行っている環境であったりと、未だにXMLでのエクスポート・インポートが必要になる場面はまれにあるかと思います。 今回、そういった環境下でもわざわざ管理ポータルを開かずとも、VSCodeでXML形式でエクスポートする拡張機能をリリースしましたので、共有させて頂きます。

機能について

編集画面、あるいは、VSCodeのエクスプローラータブ内からクラスを選択し、コンテキストメニューの「XML形式でエクスポート」を実行します。

XMLファイルは所定の場所に保存されます。保存先は設定で指定が出来ます。

複数のクラスを選択した場合、初期値では１対１でXMLファイルが保存されます。

設定を変更する事で、１つのXMLファイルとして保存する事も可能です。

利用方法

1. 拡張機能の検索窓から"ObjectScript To XML"を検索し、インストールします。

2. READMEに記載されているソースをダウンロードし、IRISへインポートします。

3. ウェブ・アプリケーションを作成します。

4. 必要な場合、拡張機能の設定値を変更します。

"objectscript-to-xml": {
    "applicationName": "/exml-api",
    "exportDir": "exports",
    "bundled": false
}

• applicationNameに作成したウェブ・アプリケーションの名前を指定します。

• exportDirにはエクスポートしたXMLファイルの配置先を指定します。

• bundledがtrueの場合は、１つのXMLファイルとしてエクスポートされます。既定値はfalseです。

​

Caché技術ガイドのいくつかをIRIS版に書き換えた文書を作成しましたので公開します。

IRISファーストステップガイド
IRISBasicTechnologyGuide

- ObjectScript操作ガイド

- オブジェクト操作ガイド

- 多次元データエンジンの概念およびアーキテクチャー
IRIS SQLガイド

ほとんどの方が @Daniel Tamajon の CachéQuality プロジェクトをご存知かと思います。 まだご存知でない方のために説明すると、InterSystems 製品用に記述されたコードの静的構文アナライザーです。 コード内の様々な種類の問題や潜在的なバグがお客様のプロダクション環境で見つかる前に、それらを検出して解決するのに役立てられます。 つまり、CachéQuality を使用することで、より優れた製品を提供できるようになります。 ObjectScript コードのチェックに使用されるルールの完全なリストは、こちらをご覧ください。

これは Studio ですでに提供されているものですが、 VSCode でも使用できるようになりました。

インストール

VSCode の拡張機能セクションで、「cachequality」を検索し、SonarLint for CachéQuality をインストールします。より優れたエクスペリエンスを得るには、先に VSCode for ObjectScript をインストールしてください。 いずれの拡張機能も、「objectscript」の検索で見つかります。

この拡張機能をインストールした時点から、構成を行わずに使用し始めることができ、クラスを開くと、検出されるすべての問題が下線表示されるようになります。

下線表示にマウスポインターを合わせると、詳細を表示できます。

また、直接 VSCode で問題の詳細を開くこともできます。

VSCode には問題ビューが備わっており、Cmd+Shift+M ホットキーで有効にできます。このビューには、開いているソースファイルで検出された問題のリストが表示されます。 CacheQuality が検出した問題のリストを確認し、実際の場所に移動できます。

修正された行は保存後に再チェックされます

ただし、制限があります。 ルールのリストと、ルールに関連する他のいくつかのパラメーターを制御できません。 拡張機能は、デフォルト値による事前構成済みで提供されます。 さらに制御が必要な場合は、コネクテッドモードを使用できます。

コネクテッドモード

この拡張機能には、コネクテッドというモードも備わっています。 このモードでは、SonarQube サーバーをインストール済みの CacheQuality プラグインに接続できます。

SonarQube を使って、ルールのリストをカスタマイズできます。 ルールのパラメーターを無効化または有効化し、変更できます。 たとえば、`To method has too many lines` ルールはデフォルトで 50 行以降にトリガーされますが、この数値を変更することができます。

SonarQube Server がある場合は、まず、プロジェクト全体を解析する必要があります。 これには様々な方法があり、詳細は SonarQube ドキュメントに記載されています。 また、VSCode からプロジェクトにアクセスするにはトークンが必要です。

VSCode 設定の変更

    "sonarlint.connectedMode.project": {
        "projectKey": "Samples",
        "serverId": "local"
    },
    "sonarlint.connectedMode.servers": [
        {
            "serverId": "local",
            "serverUrl": "http://localhost:9000",
            "token": "65b19eb2ef04cd81a033c89820acf65d1f349c4f"
        }
    ]

projectKey は SonarQube に定義されているもので、サーバーセクションに定義されたリストの serverId である必要があります。

設定を保存し、SonarQube 側に変更を保存したら、バインディングを更新して VSCode を最新状態にします。

設定が正しく更新されたら、以下の通知が表示されます。

プロジェクトに使用されているルールのリストをカスタマイズする場合は、まず、ビルトインの品質プロファイル Caché Quality をコピーする必要があります。

そして、プロジェクトに新しいプロファイルを有効化します。

検出された一部の問題は SonarQube で解決でき、VSCode 拡張機能はそれを認識するため、再度表示されることはありません。

たとえば、このような問題があります。

呼び出されないメソッドの問題を誤検出として解決し、変数の問題を修正しないようにしましょう。

ファイルを開き直すと、新しい情報でもう一度解析されます。 %OnNew メソッドには未解決の問題が残っていません。

問題とフィードバック

CacheQuality プロジェクト自体はオープンソースではありませんが、VSCode の拡張機能はオープンソースです。 問題やフィードバックはそちらにお送りください。

開発者の皆様はじめまして。 私からはIRISのソースコントロール機能を用いたソースの自動チェック機能のご紹介をしたいと思います。 チーム開発では、ソースの可読性や実装方法等がある程度統一されるようにコーディング規約を作成すると思います。 しかし、メンバーの入れ替わりでコーディング規約の説明をしていても徹底されないことが起こることも少なくありません。 なので、ソースコントロールを使用してコンパイル時に自動的にチェックするようにしました。 IRIS内で完結させるメリットとして、エラーチェックだけでなくチェック後にエラーがなければコンパイルまで自動で行えること、 %Dictionary.ClassDefinition（クラス定義）を使用できるので、チェッククラスを作成しやすいこと等があげられます。

目次

1. ソースコントロールについて
2. 今回用意したチェック用クラスの紹介
3. ソースコントロールへの設定
4. 実際の動作
5. 感想

１．ソースコントロールについて まず、ソースコントロールについて簡単に記載します。 ソースコントロールとは、一般的にコードに対する変更を追跡し管理することを表します。 IRISのソースコントロール機能には様々なメソッドが用意されています。 今回はそれを使用することでソースの自動チェック機能を実現していきます。 参考リンク：InterSystems IRIS とソース・コントロール・システムの統合、　ソース・コントロール設定の構成

２．今回用意したチェック用クラスの紹介 今回作成したチェック用クラスには基底クラスとして、「%Studio.SourceControl.Base」と「%Studio.Extension.Base」（%Studio.SourceControl.Baseの基底クラス）を使用しています。 上記のクラスにはログイン時のイベントやロード前イベントなどが定義されており、今回は「OnBeforeCompile」（コンパイル前イベント）を使用しました。

では、実際のチェック用クラスの内容をご紹介します。 今回は以下をコーディング規則として実装をしています。 ①クラスの命名チェック - 「XXXX」始まりのクラス名であること ②インデントチェック - インデントは4の倍数の半角空白で埋めること ③変数の利用チェック - 定義した変数は利用すること ④引数の利用チェック - パラメータとして受け取った引数は利用すること

Class User.CompileChk Extends %Studio.SourceControl.Base
{

///  処理概要 ：コンパイル前チェック
///  <br>IN ：InternalName : コンパイル対象クラス
///  <br>OUT ：%Status
///  <br>処理詳細：規約に則さない実装がされている場合、コンパイルエラーにする。
Method OnBeforeCompile(InternalName As %String, ByRef qstruct As %String) As %Status
{
    Set InternalName = $REPLACE(InternalName, ".CLS", "")
    Set clsDef = ##Class(%Dictionary.ClassDefinition).%OpenId(InternalName)

    Set SKIPuFLG = $$$NO
    Write !,"****************コンパイルチェック開始****************",!
    Write "TARGET ： "_InternalName,!
    Set hasErr = 0
    
    #; クラス名チェック
    Set hasErr = hasErr + '##class(User.Chk.ClassNamingChecker).%New().IsCorrectDefine(clsDef)
    #; インデントチェック
    Set hasErr = hasErr + '##class(User.Chk.IndentChecker).%New().UseWrongIndent(clsDef)
    #; 変数の利用チェック
    Set hasErr = hasErr + '##class(User.Chk.UseValChecker).%New().UseVal(clsDef)
    #; 引数の利用チェック
    Set hasErr = hasErr + '##class(User.Chk.UseArgsChecker).%New().UseArgs(clsDef)
    

    Write "****************コンパイルチェック完了****************",!
    If (hasErr > 0) {
        Return $$$ERROR($$$GeneralError, "コンパイルエラーがあります。")
    } Else {
        Return $$$OK
    }
}

}

①クラスの命名チェッククラス - User.Chk.ClassNamingChecker Class User.Chk.ClassNamingChecker Extends %RegisteredObject {

///  処理概要 ：クラス定義の命名規約違反チェック
///  <br>IN ：clsDef : クラス定義
///  <br>OUT ：%Boolean
///  <br>処理詳細：クラスの命名がコーディング規約に従っているかどうかをチェックする。
Method IsCorrectDefine(clsDef As %Dictionary.ClassDefinition) As %Boolean
{
    Write "*クラス名チェック",!

    Set ret = $$$YES
    If (clsDef '= "") {
        Set clsName = clsDef.Name
        Set ret = ..WriteStartWithStrErr(clsName)
    }

    Return ret
}

///  処理概要 ：命名先頭不正のエラー表示
///  <br>IN ：clsName クラス名/ keyword キーワード
///  <br>OUT ：%Boolean
///  <br>処理詳細：クラス名の先頭がキーワードで開始していなければエラーを表示する。
Method WriteStartWithStrErr(clsName As %String) As %Boolean [ Private ]
{
    If ($FIND(clsName, ".XXXX") > 0) {
        #; OK
        Return $$$YES
    } Else {
        Write "E: クラス名はXXXXという単語で始まる必要があります。",!
        Return $$$NO
    }
}

}

クラス内で行っていること 引数として%Dictionary.ClassDefinition（クラス定義）を受け取り、クラス定義内のプロパティであるNameを使用することで クラス名を取得。取得したクラス名に対して、「.XXXX」を＄FINDで検索することでクラスの先頭が「XXXX」であるかチェックを行います。

②インデントチェック - User.Chk.IndentChecker

Class User.Chk.IndentChecker Extends %RegisteredObject
{

///  処理概要 ：インデント不正チェック
///  <br>IN ：clsDef : クラス定義
///  <br>OUT ：%Boolean
///  <br>処理詳細：インデントが4の倍数になっているかをチェックをする。
Method UseWrongIndent(clsDef As %Dictionary.ClassDefinition) As %Boolean
{
    Write "*インデント不正チェック",!
    Set isCorrect = $$$YES
    Set count = clsDef.Methods.Count()
    For i = 1: 1: count {
        Set cnt = 0
        Set method = clsDef.Methods.GetAt(i)
        Do method.Implementation.Rewind()

        While ('method.Implementation.AtEnd) {
            Set cnt = cnt + 1
            Set line = method.Implementation.ReadLine()
            If (line = "") {
                Continue
            }

            If ('$MATCH(line, "^( {4}){1,}[^ ].*")) {
                Set isCorrect = $$$NO
                Write "E: インデントが4の倍数になっていません。: "_method.Name_"+"_cnt_line,!
            }
        }
    }

    Return isCorrect
}

}

クラス内で行っていること 引数として%Dictionary.ClassDefinition（クラス定義）を受け取り、クラス定義内のプロパティであるMethods.Count()でメソッドの数を取得。 メソッドごとに1行ずつチェックを行います。チェックは正規表現を使用（^( {4}){1,}[^ ].*の部分）し、半角スペースが4の倍数になっているかチェックを行います。

③変数の利用チェック - User.Chk.UseValChecker

Class User.Chk.UseValChecker Extends %RegisteredObject
{

///  処理概要 ：変数の利用チェック
///  <br>IN ：clsDef : クラス定義
///  <br>OUT ：%Boolean
///  <br>処理詳細：定義された変数が利用されているかをチェックをする。
Method UseVal(clsDef As %Dictionary.ClassDefinition) As %Boolean
{

    Set isCorrect = $$$YES
    Set count = clsDef.Methods.Count()
    For i = 1: 1: count {
        Set cnt = 0
        Set method = clsDef.Methods.GetAt(i)
        Do method.Implementation.Rewind()

        Set args = method.FormalSpec
        Set argList = {}
        For j = 1: 1: $LENGTH(args, ",") {
            Set arg = $REPLACE($REPLACE($REPLACE($PIECE($PIECE(args, ",", j), ":", 1), "&", ""), "*", ""), "...", "")
            If (arg = "") {
                Continue
            }
            Do argList.%Set(arg, "")
        }

        Set valList = {}
        While ('method.Implementation.AtEnd) {
            Set cnt = cnt + 1
            Set line = method.Implementation.ReadLine()
            If (line = "") {
                Continue
            }
            If (..HasComment(line)) {
                Continue
            }

            If ($FIND(line, "Set ") > 0) {
                Set valNm = $PIECE($REPLACE($PIECE($PIECE(line, "Set ", 2), "="), " ", ""), "(")
                #; オブジェクトへの参照は対象外。
                If (($FIND(valNm, ".") = 0) && ($FIND(valNm, "$") = 0)) {
                    #; 変数の定義があればObjectに登録。
                    If (('valList.%IsDefined(valNm)) && 'argList.%IsDefined(valNm)) {
                        Do valList.%Set(valNm, $$$NO)
                    }
                }
            }

            Set iter = valList.%GetIterator()
            While iter.%GetNext(.key, .value) {
                If ($FIND($REPLACE(line, "Set "_key_" ", ""), key) > 0) {
                    Do valList.%Set(key, $$$YES)
                }
            }
        }
        Set iter = valList.%GetIterator()
        While iter.%GetNext(.key, .value) {
            If ('value) {
                Write "E: "_method.Name_"() にて変数"_key_"は定義されていますが、利用されていない可能性があります。",!
                Set isCorrect = $$$NO
            }
        }
    }
    Return isCorrect
}

Method HasComment(line As %String) As %Boolean [ Private ]
{
    Return ($MATCH(line, "^( )*#;.*") > 0) || ($MATCH(line, "^( )*//.*") > 0)
}

}

クラス内で行っていること ②で行ったようにメソッド単位でチェックを行います。method.FormalSpec でメソッドの引数のリストを含む文字列を取得します。 上記で取得した文字列から、引数のみを抽出して引数リストを作ります。ここまで来たら、メソッドを1行ずつチェックしていきます。 HasCommentメソッドでコメントの場合は読み飛ばすようにしています。まず、「Set」の使用をチェックします。（If ($FIND(line, "Set ") > 0) {） 使用されている場合でもオブジェクトへの参照は対象外とするため、「.」や「$」が使用されている場合は読み飛ばします。（If (($FIND(valNm, ".") = 0) && ($FIND(valNm, "$") = 0)) {） 「.」や「$」が使用されていないかつ、引数のリストに存在しない場合は後のチェックのためにリストに追加します。（value側は$$$NOで登録しておきます） チェックリストを順番にリストのキー項目が定義箇所以外で使用されているかチェックしていきます。（L50～L54） 使用されている場合、該当キー項目のvalueを$$$YESに更新しておきます。 チェック処理としては上記で完了です。あとはvalueが$$$NOの項目を洗い出して、チェック完了となります。

④引数の利用チェック - User.Chk.UseArgsChecker

Class User.Chk.UseArgsChecker Extends %RegisteredObject
{

///  処理概要 ：引数の利用チェック
///  <br>IN ：clsDef : クラス定義
///  <br>OUT ：%Boolean
///  <br>処理詳細：引数が利用されているかをチェックする。
Method UseArgs(clsDef As %Dictionary.ClassDefinition) As %Boolean
{
    Write "*引数の利用チェック",!
    Set ngKeyword = $LISTBUILD(")", """", "}")

    Set isCorrect = $$$YES
    Set count = clsDef.Methods.Count()
    For i = 1: 1: count {
        Set method = clsDef.Methods.GetAt(i)
        Set args = method.FormalSpec

        Do method.Implementation.Rewind()
        Set str = method.Implementation.Read()
        For j = 1: 1: $LENGTH(args, ",") {
            Set arg = $REPLACE($REPLACE($REPLACE($PIECE($PIECE(args, ",", j), ":", 1), "&", ""), "*", ""), "...", "")
            If (arg = "") {
                Continue
            }

            Set isIgnore = $$$NO
            Set ptr = 0
            While $LISTNEXT(ngKeyword, ptr, value) {
                #; NGリストの内容が含まれていると、切り出し対象外。
                If ($FIND(arg, value) > 0) {
                    Set isIgnore = $$$YES
                    Quit
                }
            }
            If (isIgnore) {
                Continue
            }

            If ($FIND(str, arg) = 0) {
                Write "E: 引数が利用されていません。: "_method.Name_"/"_arg,!
                Set isCorrect = $$$NO
            }
        }
    }

    Return isCorrect
}

}

クラス内で行っていること まず、コメントなどを引っ掛けないためにチェックしない文字を定義します。（L10） ③と同様にメソッド単位でチェックをするようにします。（L13～） メソッドの引数を取得します。（L16） メソッドの最初の行からチェックするようにポインタをストリームの先頭にしてメソッドの読込を行います。（L18、L19） 引数の数分チェックをまわしていきます。（L20） 引数の中にチェックしない文字が入っているかチェックします。（L28～L34） チェックしない文字が入っていない場合は、読み込んだメソッドの中で引数が使用されているかチェックを行います。（L39～L42）

３．ソースコントロールへの設定 管理ポータルにて、[システム管理]⇒[構成]⇒[追加の設定]⇒[ソースコントロール] を開くと ソースコントロールの設定画面となります。

ソースコントロールクラス名の一覧には「%Studio.SourceControl.Base」クラスを継承したクラスが表示されます。 ソースコントロールを行いたいネームスペースを選択し、使用したいソースコントロールクラスを選択⇒保存します。 今回はUSERのネームスペースにチェック用クラス用意していますが、％SYSにソースコントロールクラスを作成することで全てのネームスペースに対して使用することができます。

４．実際の動作 今回テスト用に用意したクラスが以下のクラスです。

Class User.Test.NewClass1 Extends %RegisteredObject
{

///  処理概要 ：テストメソッド
///  <br>IN ：Str1 : テスト用文字列１
///  <br>IN ：Str2 : テスト用文字列２
///  <br>OUT ：%Boolean
Method TestMethod(Str1 As %String, Str2 As %String) As %Boolean
{
   Set test1 = Str1
    Set test2 = "TEST"
    
    Set ^TESTG(test1,"abc") = "hugehuge"
    
    Return $$$OK
}

}

クラス名が「XXXX」始まりでないこと。 - クラスの命名チェック インデントが４の倍数個の半角スペースになっていないこと。（L10) - インデントチェック 定義した変数test2が使用されていないこと。 - 変数の使用チェック TestMethodの引数として用意したStr2が使用されていないこと。 - 引数の使用チェック

実際にコンパイルした結果がこちらです。

すべてチェックに引っかかっており、コンパイルもされないようになっています。 では、チェッククラスに指摘された部分を修正したものをコンパイルしてみます。

Class User.Test.XXXXNewClass1 Extends %RegisteredObject
{

///  処理概要 ：テストメソッド
///  <br>IN ：Str1 : テスト用文字列１
///  <br>IN ：Str2 : テスト用文字列２
///  <br>OUT ：%Boolean
Method TestMethod(Str1 As %String, Str2 As %String) As %Boolean
{
    Set test1 = Str1
    Set test2 = "TEST"
    Set ^TESTG(test1,test2) = Str2
    Return $$$OK
}

}

見事にコンパイルが成功しました。

５．感想 今回参考例として４つのチェックを行いましたが、工夫や組み込み方次第では色々なチェックを組み込めると感じました。 Ex.) 変数がキャメルケースになっているか、利用してほしくないプロパティ等が使用されているか etc… また、他のライブラリでチェックツールは色々とあるかと思いますが、今回はIRISの中だけで完結させており、 チェックだけでなくエラーが出なかった時はコンパイルまで通るところがやはり良い部分に感じました。 今回使用したクラスはGithubにアップしておりますので、興味のある方はご確認いただければと思います。 追記）インデントチェッククラスをEmbedded Pythonで記載してみました。（Githubにもアップしております）

Class User.Chk.IndentCheckerP Extends %RegisteredObject
{

///  処理概要   ：インデント不正チェック
///  <br>IN     ：clsDef : クラス定義
///  <br>OUT    ：%Boolean
///  <br>処理詳細：インデントが4の倍数になっているかをチェックをする。
ClassMethod UseWrongIndentP(clsDef As %Dictionary.ClassDefinition) As %Boolean [ Language = python ]
{
	import iris
	import re
	
	print("*インデント不正チェック\n")
	
	isCorrect = 1
	count = clsDef.Methods.Count()
	for i in range(count):
	    cnt = 0
	    method = clsDef.Methods.GetAt(i + 1)
	    while not method.Implementation.AtEnd:
	        cnt += 1
	        line = method.Implementation.ReadLine()
	        if line == '':
	            continue
	        if len(re.compile("^( {4}){1,}[^ ].*").findall(line)) == 0:
	            isCorrect = 0
	            print("E: インデントが4の倍数になっていません。: " + method.Name + str(cnt) + str(line) + "\n") 
	return isCorrect
}

}

以上になります。ご一読いただき、ありがとうございました。

開発者の皆さん、こんにちは！ InterSystems IRIS（以下、IRIS）を使用したアプリケーション開発において、皆さんは環境設定をどうされていますか？ 私は最近になって、「インストールマニフェスト」という機能があることを知りました。 これは、管理ポータルでポチポチしていた作業をコード化・自動化できる強力なツールです！ 最初こそとっつきづらかったものの良いところがたくさんあるなと思ったので、簡単にではありますが皆さんにその良さと始め方をご紹介したいと思います。

なお、私が使用しているIRISバージョンは以下です。

2022.1

バージョンが異なる場合、違う書き方になっているもの等が存在する場合がありますので、 公式ドキュメント等を参照し適宜読み替えていただければと思います。

目次

1. はじめに
2. インストールマニフェストとは
3. インストールマニフェストのメリット・デメリット
4. インストールマニフェストの始め方と基本構造
   1. マニフェストの作成
   2. マニフェストの編集
   3. マニフェストの実行
5. インストールマニフェストでできること
   1. 変数の設定
   2. ネームスペースとデータベースの設定
   3. データのインポートとマッピング
   4. セキュリティ設定
   5. InterOperability 機能の設定
6. インストールマニフェスト以外で行う環境設定
   1. ObjectScriptによる実装
   2. Pythonによる実装
7. まとめ

1. はじめに

IRISを使用するにあたって、管理ポータルでの環境設定は切っても切れない作業だと思います。 IRIS のインストールマニフェストを使用することで、ネームスペース、データベース、セキュリティ設定、InterOperabilityの有効化、 さらにはカスタムコードの実行まで、一連のプロセスを自動化することができます。

本記事では、実際のマニフェストファイルを例に挙げながら、IRIS の環境設定自動化の方法について解説します。

なお、本記事で解説しているサンプルコードの全文と、付随するフォルダ・ファイルについては、Githubにて公開しています。

2. インストールマニフェストとは

IRIS のインストールマニフェストとは、%Installerというツールのことを指します。 インストールマニフェスト定義を記述するだけで、 IRIS環境設定を変更するために必要なコードを自動生成することができます。 他人に共有する際は、定義したインストールマニフェストを配布するだけで済みます。

インストールマニフェストは XML 形式で記述されます。 主要な要素として <Manifest>、<Namespace>、<Configuration>、<Database> などがあります。

なお、公式ドキュメントは以下です。

インストール・マニフェストの作成および使用

3.インストールマニフェストのメリット・デメリット

私が使ってみて感じた、インストールマニフェストのメリット・デメリットについてお伝えします。 全ての場合でインストールマニフェストが優れているとは言えないと思いますので、下記を参考に使用したほうが良いかどうか判断してもらえたらと思います。

• メリット

  • IRIS環境構築（管理ポータルで手動で実行していた作業）の自動化ができる
  • 環境構築内容をコードとして管理できる
  • 共通の環境を誰でも簡単に、素早く作れるようになる
  • 事前に内容を定義しておけるので、管理ポータルで操作してうっかり設定ミスや設定忘れをしてしまうといったことがなくなる

• デメリット

  • 環境構築経験が豊富でない人にとっては、公式ドキュメントを読みながらでもコードが示す内容の把握が難解なところがある
  • マニフェストの記法を理解した人でないと、コードのメンテナンスを実施できない
  • 定義の作成、定義の配布、実行方法の共有など、事前準備に手間がかかるため、少人数の環境が対象だったり、設定項目が少なかったりすると手間のほうが大きくなる可能性がある

4. インストールマニフェストの始め方と基本構造

4-1. マニフェストの作成

インストールマニフェストは、簡単に作成することができます。 例えばあなたがスタジオを使っている場合、下記の手順でテンプレートを作成できます。

ファイル > 新規作成 > 一般 > %Installer マニフェスト > OK

こうして作成されるマニフェストは、以下のようになっています。

Include %occInclude  

/// %Installer Manifest MyApp.MyInstaller
Class MyApp.MyInstaller
{  
  
/// マニフェスト定義.  
XData MyManifest [ XMLNamespace = INSTALLER ]  
{  
<Manifest>
	<Namespace>
		<Configuration>
			<Database>
				<!-- Your Manifest code here -->
			</Database>
		</Configuration>
	</Namespace>
</Manifest>
}  
  
/// これは XGL により生成されたメソッド・ジェネレーターです。.  
ClassMethod setup(ByRef pVars, pLogLevel As %Integer = 3, pInstaller As %Installer.Installer, pLogger As %Installer.AbstractLogger) As %Status [ CodeMode = objectgenerator, Internal ]  
{  
    #; XGL ドキュメントでこのメソッドのコードを生成する.  
    Quit ##class(%Installer.Manifest).%Generate(%compiledclass, %code, "MyManifest")  
}  
  
}

4-2. マニフェストの編集

なにやら見覚えのないコードがたくさん生成されますが、安心してください。 そのうち、私たちが編集すればよいのは基本的に下記の部分のみです。

<Manifest>
	<Namespace>
		<Configuration>
			<Database>
				<!-- Your Manifest code here -->
			</Database>
		</Configuration>
	</Namespace>
</Manifest>

■マニフェストの基本構造

詳細については後ほど解説しますが、ここでは基本的な構造について紹介していきます。

• <Manifest>：すべてのタグのルートタグである必要がある。 他のすべてのタグを含む。
• <Namespace>：ネームスペースを定義する。 【親タグ：<Manifest>】
• <Configuration>：<Namespace>内で構成タグの親タグとして記述する必要がある。【親タグ：<Namespace>】
• <Database>：データベースを定義する。 【親タグ：<Configuration>】

ここで覚えるべきは、<Manifest>タグは唯一無二ですべてのルートタグとなること、 その中身となるそれぞれのタグにも親子関係があるためそれを守らなければならないこと、の２点です。

これら以外の記述は、インストールマニフェストの作成や実行に必要なコードです。 詳細の説明については、下記のページにあるので任せたいと思います。

%InstallerでInterSystems Cachéにアプリケーションをデプロイする

4-3. マニフェストの実行

このマニフェストを実行したいときは、ターミナルで以下のコマンドを実行してください。 ※マニフェストを実行する時は、％SYSネームスペースで実行することを推奨します。（それ以外のネームスペースでも動作はします）

USER>zn "%SYS"
%SYS>do ##class(MyApp.MyInstaller).setup()

そうすると、マニフェストが環境設定のためのコードを生成し、そのコードが実際にIRISの環境設定を変更していきます。

5. インストールマニフェストでできること

それではさっそく、インストールマニフェストで実際にできることについてみていきましょう。 私が触ったことのある機能を中心に紹介していますが、前述の公式ドキュメントにはそれ以外の設定もできるXMLタグが多数紹介されていますので、参照してみてください。

5-1. 変数の設定

マニフェストでは、変数を設定することができます。 変数設定ができるタグには２種類あります。

• <Default>：変数値がまだ設定されていない場合のみ、変数値を設定します。（すでに値が設定されている場合、無効になる）【親タグ：<Manifest>】
• <Var>：マニフェストで使用できる変数を定義および設定します。【親タグ：<Manifest>】

<Var Name="var1" Value="aaa" />
// 事前に変数 var1 が設定されているので、var1 は aaa のまま
<Default Name="var1" Value="bbb" />
// 事前に変数 var2 は設定されていないので、var2 は ccc になる
<Default Name="var2" Value="ccc" />

5-2. ネームスペースとデータベースの設定

マニフェストを使用して、ネームスペースとそれに関連するデータベースを簡単に作成できます。 関連するタグは３種類です。

• <Namespace>：ネームスペースを定義する。【親タグ：<Manifest>】
  • Name：ネームスペースの名前
  • Create：新しいネームスペースを作成するかどうか（yes/no/overwrite） ※デフォルト：yes
  • Code：コード用データベースの指定
  • Data：データ用データベースの指定
  • Ensemble：InterOperabilityを使用するネームスペースかどうかの指定
• <Configuration>：<Namespace> 内で構成タグの親タグとして記述する必要がある。【親タグ：<Namespace>】
• <Database>：データベースを定義する。【親タグ：<Configuration>】
  • Name：データベース名
  • Dir：データベース・ディレクトリ
  • Create：新しいデータベースを作成するかどうか
  • InitialSize：データベースの初期サイズ（MB）
  • Resource：データベースへのアクセスを制御するリソース
  • PublicPermissions：リソースに割り当てられる許可の値（新規作成リソースのみ適用）（R/W/RW）

<Default Name="Namespace" Value="TESTNMSP"/>  
<Default Name="DATADB" Value="${Namespace}-GBL"/>  
<Default Name="CODEDB" Value="${Namespace}-RTN"/>
<Default Name="SetupDir" Value="C:\work\git"/>

<!-- ネームスペース作成 -->  
<Namespace Name="${Namespace}" Code="${CODEDB}" Data="${DATADB}" Create="yes" Ensemble="0">  
	<!-- DB作成 -->  
	<Configuration>  
		<Database Name="${DATADB}" Dir="C:\IRISDB\${Namespace}\GBL" Create="yes" InitialSize="100" Resource="%DB_${DATADB}" PublicPermissions="R"/>  
		<Database Name="${CODEDB}" Dir="C:\IRISDB\${Namespace}\RTN" Create="yes" InitialSize="10" Resource="%DB_${CODEDB}" PublicPermissions="R"/>  
	</Configuration>  
</Namespace>

■結果（管理ポータル画面）

（ネームスペース）

（データベース）

5-3. データのインポートとマッピング

マニフェストを使用して、特定のネームスペースに既存のデータやコードをインポートすることもできます。 関連するタグは１種類です。（既出除く）

• <Import>：ファイルをインポートする。（%SYSTEM.OBJ.ImportDir または %SYSTEM.OBJ.Load を使用する）【親タグ：<Namespace>】
  • File：インポートするファイルまたはフォルダ
  • Flags：コンパイル・フラグ（参考：フラグおよび修飾子）
  • Recurse：再帰的にインポートするかどうかを指定　※デフォルト：0
  • IgnoreErrors：エラー時に続行するかどうかを指定　※デフォルト：0

<Default Name="Namespace" Value="TESTNMSP"/>  
<Default Name="DATADB" Value="${Namespace}-GBL"/>  
<Default Name="CODEDB" Value="${Namespace}-RTN"/>
<Default Name="SetupDir" Value="C:\work\git"/>

<Namespace Name="${Namespace}" Code="${CODEDB}" Data="${DATADB}" Create="yes" Ensemble="0">  
	<!-- グローバル、クラス、ルーチンインポート -->  
	<Import File="${SetupDir}\Test1" Flags="ck" Recurse="1" IgnoreErrors="1"/>  
	<Import File="${SetupDir}\Test2" Flags="ck" Recurse="1" IgnoreErrors="1"/>  
</Namespace>

■結果（管理ポータル画面）

マニフェストを使用して、グローバルやクラスをマッピングすることもできます。 関連するタグは３種類です。（既出除く）

• <GlobalMapping>：グローバルを現在のネームスペースにマッピングする。【親タグ：<Configuration>】
  • Global：グローバル名
  • From：グローバルのソース・ネームスペース
• <ClassMapping>：パッケージを現在のネームスペースにマッピングする。【親タグ：<Configuration>】
  • Package：マップするパッケージ
  • From：マッピングに使用するソース・データベース
• <RoutineMapping>：ルーチンを現在のネームスペースにマッピングする。【親タグ：<Configuration>】
  • Name ：ルーチン
  • Type ：ルーチン・タイプ
  • From：ルーチンのソース・データベース

<Default Name="Namespace" Value="TESTNMSP"/>
<Default Name="Namespace2" Value="${Namespace}2"/>  
<Default Name="DATADB2" Value="${Namespace2}-GBL"/>  
<Default Name="CODEDB2" Value="${Namespace2}-RTN"/>

<Namespace Name="${Namespace2}" Code="${CODEDB2}" Data="${DATADB2}" Create="yes" Ensemble="0">  
	<Configuration>
		<!-- DB作成 -->  
		<Database Name="${DATADB2}" Dir="C:\IRISDB\${Namespace2}\GBL" Create="yes" InitialSize="100" Resource="%DB_${DATADB2}" PublicPermissions="R"/>  
		<Database Name="${CODEDB2}" Dir="C:\IRISDB\${Namespace2}\RTN" Create="yes" InitialSize="10" Resource="%DB_${CODEDB2}" PublicPermissions="R"/>  
		<!-- グローバル、クラス、ルーチンマッピング設定 -->  
		<GlobalMapping Global="test2" From="${DATADB}"/>  
		<ClassMapping Package="Test2" From="${CODEDB}"/>  
	</Configuration>  
</Namespace>

■結果（管理ポータル画面）

5-4. セキュリティ設定

マニフェストを使用して、ロールやユーザアカウントを複数作成することができます。 関連するタグは２種類です。

• <Role>：ロールを定義する。【親タグ：<Manifest>】
  • Name：ロール名
  • Description：ロールの説明（カンマ不可）
  • Resources：ロールで保持されているリソースと特権。
  • RolesGranted：付与されるロール
• <User>：ユーザを定義する。【親タグ：<Manifest>】
  • Username：ユーザ名
  • PasswordVar：ユーザ・パスワードが含まれる変数の名前（変数名を渡す必要があることに注意）
  • Fullname：ユーザのフルネーム
  • Roles：ユーザを割り当てるロールのリスト
  • Namespace：ユーザの実行開始ネームスペース
  • Enabled：ユーザが有効かどうか
  • Comment：オプションコメント
  • ChangePassword：次回ログイン時にユーザにパスワードの変更を要求するかどうか
  • ExpirationDate：それ以降のユーザ・ログインが無効になる日付

<Default Name="TestUserPw" Value="12345"/>

	<!-- ロール作成・変更 -->  
<Role  
	Name="TestOperator"  
	Description="テスト運用者ロール"  
	Resources="%DB_TESTNMSP-GBL:RW,%DB_TESTNMSP-RTN:RW"  
	RolesGranted="%Developer"/>  
<Role  
	Name="TestAdministrator"  
	Description="テスト管理者ロール"  
	RolesGranted="%All"/>  
 
<!-- ユーザ作成・変更 -->  
<User  
	Username="TestUser1"  
	PasswordVar="TestUserPw"  
	Fullname="テストユーザ1"  
	Roles="TestOperator"  
	Namespace="USER"  
	Enabled="1"  
	Comment="テストユーザ1"/>  
<User  
	Username="TestUser2"  
	PasswordVar="TestUserPw"  
	Fullname="テストユーザ2"  
	Roles="TestAdministrator"  
	Namespace="USER"  
	Enabled="1"  
	Comment="テストユーザ2"/> 

■結果（管理ポータル画面）

（ロール）

（ユーザ）

■クラスメソッドの実行（Invoke）

また、管理ポータルのセキュリティ設定をまるっと読み込むこともできます。 これにより、管理ポータルやターミナル等のログインの有効化や、詳細のセキュリティ設定までを一括で行うことができます。 ロールやユーザアカウントについても、この読み込みにより一括で作成することができます。 関連するタグは２種類です。（既出除く）

• <Invoke>：クラス・メソッドを呼び出して、実行結果を変数の値として返す。【親タグ：<Namespace>】
  • Class：クラス名
  • Method：メソッド名
  • CheckStatus：返されたステータスをチェックするかどうか
  • Return：結果の書き込み先の変数の名前
• <Arg>：<Invoke> または <Error> から呼び出されるメソッドに引数を渡す。【親タグ：<Invoke>, <Error>】
  • Value：引数の値

<Default Name="SetupDir" Value="C:\work\git"/>

<Namespace Name="%SYS" Create="overwrite">  
	<!-- セキュリティ設定のインポート -->  
	<Invoke Class="Security.System" Method="ImportAll" CheckStatus="false">  
		<Arg Value="${SetupDir}\SecurityExport.xml"/>  
	</Invoke>  
</Namespace>

これらのタグは、セキュリティ設定のインポート以外にも様々な用途に使用することができます。 例えば、タスクスケジュール全体のインポートをセキュリティと同じように行ったり、自作のクラスの処理を実行したり、既存のシステムクラスの処理を実行したりなどです。

※管理ポータルのログインの有効化設定については、2024.3以降のバージョンであればマニフェストのタグにて変更することができます。 （ターミナルのログイン有効化については、現在は<Invoke>を用いる方法か、後述の別途マニフェスト以外のコードを書く方法で実現するしかありません） 具体的には、下記のタグで実現できます。

• <CSPApplication>：クラス内で定義されている 1 つ以上の Web アプリケーションを定義する。【親タグ：<Namespace>】
  • AuthenticationMethods：有効な認証方法（例：32=password、64=unauthenticated）
  • CSPEnabled：CSP が有効かどうか　※デフォルト：1
  • DefaultTimeout：セッション・タイムアウト
  • Description：説明
  • Directory：CSP ファイルへのパス
  • Url：Webアプリケーションの名前
  • ：

※セキュリティ設定のインポートの事前準備として、管理ポータルのセキュリティ設定（上述の「SecurityExport.xml」にあたるもの）をXMLとしてエクスポートしておく必要があります。 エクスポートは、次のように実施します。 ターミナルで^SECURITY ユーティリティを起動し、12) System parameter setup > 5) Export All Security settings を選択します。 そうすると、C:\InterSystems\[IRISインスタンス名]\mgr\SecurityExport.xml ができているはずです。 （IRISを入れている場所によっては出力場所は異なります）

★４．セキュリティ情報（ユーザ・サービスなど）のインポートInterSystems 製品の設定内容をインポート／エクスポートする方法 > セキュリティについて

%SYS>Do ^SECURITY
：
Option? 12       // System parameter setup
：
Option? 5        // Export All Security settings

Export ALL security records? Yes => Yes

Export to file name SecurityExport.xml =>
Parameters? "WNS" =>
Confirm export of selected security records to SecurityExport.xml? No => Yes

■結果（管理ポータル画面）

（デフォルトでは管理ポータルのログイン時にパスワード認証はないが、それをマニフェストで有効化した例）

5-5. InterOperability 機能の設定

InterOperability機能を使用する場合、専用のネームスペースを作成することができます。 また、プロダクションを自動的に設定することもできます。 関連するタグは２種類です。<Namespace>も改めて紹介します。

• <Namespace>：ネームスペースを定義する。【親タグ：<Manifest>】
  • Name：ネームスペースの名前
  • Create：新しいネームスペースを作成するかどうか（yes/no/overwrite） ※デフォルト：yes
  • Code：コード用データベースの指定
  • Data：データ用データベースの指定
  • Ensemble：InterOperabilityを使用するネームスペースかどうかの指定
• <Production>：プロダクションを定義する。【親タグ：<Namespace>】
  • Name：プロダクション名
  • AutoStart：プロダクションを自動的に起動するかどうか　※デフォルト：0

<Default Name="Namespace3" Value="ENSNMSP"/>
<Default Name="DATADB3" Value="${Namespace3}-GBL"/>  
<Default Name="CODEDB3" Value="${Namespace3}-RTN"/>  
<Default Name="SetupDir" Value="C:\work\git"/>

<Namespace  Name="${Namespace3}"  Code="${CODEDB3}"  Data="${DATADB3}"  Create="yes"  Ensemble="1">
	<!-- Database作成などの設定は省略 -->
	<!-- グローバル、クラス、ルーチンインポート -->  
	<Import File="C:\work\git\Test3" Flags="ck" Recurse="1" IgnoreErrors="1"/>
	<!-- プロダクションの作成 -->
	<Production  Name="Test3.job.Main"  AutoStart="1"  />
</Namespace>

■結果（管理ポータル画面）

6. インストールマニフェスト以外で行う環境設定

マニフェストを作成していると、管理ポータルでは設定できるけどマニフェストではどうやるのだろう？という設定に度々出会います。 公式ドキュメントを見るなどしてマニフェストでの実現方法がわかる場合もありますが、 中にはマニフェストでは実現方法がないもの、後続のバージョンでは修正されたが今使っているバージョンではバグが残っており実現できないもの、 等がある場合があります。

その場合、あきらめて管理ポータルで設定するというのも手ですが、 別途コード化してマニフェストの処理と一緒に実施してしまうのもありです。

実際に、いくつかの設定をマニフェスト以外のコードで実現し、それをマニフェストと一緒に実行するコードの簡単な例をご紹介します。

6-1. ObjectScriptによる実装

下記のコードでは、マニフェストの生成・実行処理であるsetupメソッド（前述のスタジオでの新規作成にて自動作成されるメソッド）を、 自作のsetupExecuteというメソッドでラップしています。 その上で、ロケールの変更や不要タスクの一時停止といった処理をコードで記述し、実行します。

/// <h2>マニフェスト生成・実行処理</h2>  
/// <p><pre>SAMPLES>  
/// Do ##class(MyApp.MyInstaller).setup()  
/// </p></pre>  
ClassMethod setup(ByRef pVars, pLogLevel As %Integer = 3, pInstaller As %Installer.Installer, pLogger As %Installer.AbstractLogger) As %Status [ CodeMode = objectgenerator, Internal ]  
{  
	#; XGL ドキュメントでこのメソッドのコードを生成する.  
	Quit ##class(%Installer.Manifest).%Generate(%compiledclass, %code, "MyManifest")  
}  
  
/// <h2>セットアップ開始処理</h2>  
/// <p>return %Status</p>  
/// <p><pre>SAMPLES>  
/// Do ##class(MyApp.MyInstaller).setupExecute()  
/// </p></pre>  
ClassMethod setupExecute(ByRef pVars) As %Status  
{  
	Set tSC = 0  
	New $NAMESPACE  
	Set $NAMESPACE = "%SYS"  
	#; すでにネームスペースがあるときはManifestの処理はスキップ  
	If ('##class(%SYS.Namespace).Exists("TESTNMSP")) {  
		Set tSC = ..setup(.pVars)  
	}  
	  
	#; 日本語ロケールへ変更  
	Do ##class(Config.NLS.Locales).Install("jpuw")  
	#; 不要なタスクを停止  
	Do ..SuspendTask()  
	  
	Return tSC  
}

/// <h2>タスク停止</h2>  
/// <p>不要なタスクスケジュールを停止する。</p>  
/// <p><pre>SAMPLES>  
/// Do ##class(MyApp.MyInstaller).SuspendTask()  
/// </p></pre>  
ClassMethod SuspendTask()  
{  
	Set targetId = -1  
	Set query = 0  
	Set query($INCREMENT(query)) = "SELECT %ID,Name FROM %SYS.Task"  
	Set tStatement = ##class(%SQL.Statement).%New()  
	Do tStatement.%Prepare(.query)  
	Set result = tStatement.%Execute()  
	While (result.%Next()) {  
		If (result.%GetData(2) = "機能トラッカー") {  
			Set targetId = result.%GetData(1)  
			Quit  
		}  
	}  
	If (targetId '= -1) {  
		#; 機能トラッカーを一時停止  
		Do ##class("%SYS.TaskSuper").Suspend(targetId)  
	}  
}

これを実行する時は、setupメソッドではなくsetupExecuteメソッドを、ターミナルから実行します。 %SYSネームスペースから実行してください。

USER>ZN "%SYS"
%SYS>Do ##class(MyApp.MyInstaller).setupExecute()

■結果（管理ポータル画面）

（機能トラッカーを一時停止した結果）

6-2. Pythonによる実装

本題からは逸れてしまいますが、「InterSystems Embedded Python」について私は今まで触ったことがなかったため、この機会にチャレンジしてみました。 簡単にですが、その結果と所感について述べたいと思います。

6-1の内容を、Embedded Pythonを用いて書き換えたコードは以下です。 ※setupメソッドについては「objectgeneratorメソッド」という特別なメソッドのため、ObjectScriptのみでしか動作しません。そのため、Pythonへの書き換えはできないようでした。

/// <h2>マニフェスト生成・実行処理</h2>
/// <p><pre>SAMPLES>
/// Do ##class(MyApp.MyInstaller).setup()
/// </p></pre>
ClassMethod setup(ByRef pVars, pLogLevel As %Integer = 3, pInstaller As %Installer.Installer, pLogger As %Installer.AbstractLogger) As %Status [ CodeMode = objectgenerator, Internal ]
{
     #; XGL ドキュメントでこのメソッドのコードを生成する.
     Quit ##class(%Installer.Manifest).%Generate(%compiledclass, %code, "MyManifest")
}

/// <h2>セットアップ開始処理</h2>
/// <p>return %Status</p>
/// <p><pre>SAMPLES>
/// Do ##class(MyApp.MyInstaller).setupExecute()
/// </p></pre>
ClassMethod setupExecute(pVars As %SYS.Python = "") As %Status [ Language = python ]
{
	import iris
	tSC = 0
	# すでにネームスペースがあるときはManifestの処理はスキップ
	if not iris.cls('%SYS.Namespace').Exists('TESTNMSP') == 1:
		tSC = iris.cls(__name__).setup(pVars)

	# 日本語ロケールへ変更
	iris.cls('Config.NLS.Locales').Install('jpuw')
	# 不要なタスクを停止
	iris.cls(__name__).SuspendTask()

	return tSC
}

/// <h2>タスク停止</h2>
/// <p>不要なタスクスケジュールを停止する。</p>
/// <p><pre>SAMPLES>
/// Do ##class(MyApp.MyInstaller).SuspendTask()
/// </p></pre>
ClassMethod SuspendTask() [ Language = python ]
{
	import iris
	
	targetId = -1
	df = iris.sql.exec('SELECT %ID,Name FROM %SYS.Task').dataframe()
	for i in range(len(df)):
		if df.iloc[i, 1] == '機能トラッカー':
			targetId = df.iloc[i, 0]
			break

	if not targetId == -1:
    	# 機能トラッカーを一時停止
		iris.cls('%SYS.TaskSuper').Suspend(int(targetId))
}

※SuspendTaskメソッドの実行に当たっては、事前にpandasライブラリのインストールが必要です。 未インストールの場合、下記のコマンドを実行してインストールを実行してください。 （IRISを入れている場所によっては対象のパスは異なります）

> cd C:\InterSystems\[IRISインスタンス名]\bin
> irispip install --target ..\mgr\python pandas

Embededd Pythonを少しだけ使用してみた所感としては、 純粋にPythonを書くところは知っている記法をそのまま書けるので苦なく書けましたが、 IRISとの連携部分（IRISのクラスを利用するなどIRIS独自の機能を利用したいとき）は都度書き方を調べる必要があったので少し大変でした。 一度書き方を覚えてしまえばより多くのコードを書く時でも問題なさそうですが、慣れが必要だと思います。 ObjectScriptの記法に慣れていると、ObjectScriptで当たり前にできることがPythonでは実装が難しい、直感的に書けない場合もあるようなので、注意が必要です。

しかし、それを踏まえてもコードをPythonで書けるのは良いと思いました！ Pythonの記法のメリットとしてObjectScriptよりもシンプルに記載できる箇所も多いですし、 前述のPythonでは実装が難しい部分についても、バージョンがあがっていくことで機能は徐々に追加されていくと思いますので、これからに期待ができます。 なにより、ObjectScriptの経験がない人に対しても共通の言語を持てるというのはとても素晴らしいことだと思います。

これを実行する時は、ObjectScriptのときと同じで問題ありません。 %SYSネームスペースから実行してください。 ※そうでないと、「Config.NLS.Locales」の実行時にエラーとなります（%SYSにあるパッケージのため）

USER>ZN "%SYS"
%SYS>Do ##class(MyApp.MyInstaller).setupExecute()

7. まとめ

IRIS のインストールマニフェストを使用することで、環境設定の自動化が可能になり、共通の環境を素早く構築できます。 これにより、開発チームの生産性が向上し、人為的なミスも減らすことができそうです。

本記事で興味を持っていただいた方は、ぜひインストールマニフェストを使ってみてください！ 以上、ここまでお読みいただきありがとうございました。

開発者の皆さん、こんにちは。

2023年5月にご案内した記事「2023.2 からスタジオが非推奨となります」でもご案内しましたが、インターシステムズは、IRIS 2023.2のリリースからスタジオの廃止を発表しました。

詳細な非推奨計画は2023年11月にお知らせした記事「InterSystems Studio の非推奨に関するお知らせ」でご案内していましたが、バージョン2024.2のプレビューリリースが始まり現在その計画の最初のマイルストーンに到達しました。

バージョン2024.2 プレビューキット以降、Windows キットにはスタジオが含まれなくなります。つまり、このキットを使用した新規インストールでは スタジオがインストールされません。既存のインスタンスをバージョン 2024.2以降にアップグレードした場合は、インスタンスの bin ディレクトリから スタジオが削除されます。

VS Code でファイルを編集しているときに、グローバル値のチェックやいくつかの ObjectScript コマンドの実行が必要だったことはありませんか？ これが可能になりました。しかもセットアップは不要です！ vscode-objectscript 拡張機能バージョン 2.10.0 以上を持っており、InterSystems IRIS 2023.3 以降に接続している場合は、サーバーの場所に関係なくサーバーへのターミナル接続を開けるようになりました。

この新しいターミナルを開く方法には 3 つあります。

• コマンドパレットの「Launch WebSocket Terminal」（WebSocket ターミナルを起動）コマンド（Windows では Ctrl-Shift-P、Mac では Cmd-Shift-P）:

• VS Code が統合されたターミナルの Profiles（プロファイル）メニュー:

• Server Manager 拡張機能のサーバーツリー:

WebSocket ターミナルは、読み取り、ネームスペースの切り替え、中断、カスタムターミナルプロンプトなど、標準 ObjectScript シェルの多数の機能をサポートしていますが、 この記事では、これに特有の 3 つの機能に焦点を当てたいと思います。

• コマンド入力は構文の色付けがされるため、実行する前に入力が構文的に正しいことを確認できます。

• ターミナルは複数行の編集モードをサポートしています。Enter を押すと、入力が実行されるのではなく新しい行が追加されます。 新しい行は、コマンド入力に閉じられていない開始波括弧 { または開始丸括弧 ( がある場合に追加されます。

• VS Code のシェル統合に完全に組み込まれているため、VS Code はコマンドの入出力を検出できます。 このため、コマンドを簡単に再実行したり、カーソルでテキストをハイライトせずにコマンド出力をクリップボードにコピーしたりすることができます。

機能の全リストについては、公式ドキュメントをご覧ください。 この機能の改善アイデアがありますか？ ぜひお聞かせください！ 提案は、拡張機能の GitHub リポジトリに投稿できます。 この投稿のすべてのスクリーンショットでは、新しい "InterSystems Default Dark Modern" VS Code テーマが使用されています。InterSystems Language Server 拡張機能バージョン 2.4.0 以降で使用可能です。

VS Code に焦点を当てた 2 つの現地ウェビナー（ヘブライ語による「Intro」および「Beyond Basics」）に続き、フォローアップとして参加者向けに送信した関連リソースのリンクを用意しました。 コミュニティのために、ここでもそれを共有しています。
便利なリソースをぜひさらに追加してください。

• VS Code の全般的なリソース
  • Install and Use ObjectScript Extensions for VS Code（動画、4 分）
  • Working with ObjectScript Classes in VS Code for Client-Side Editing（動画、4 分）
  • Configuring VS Code Workspaces for Multiple ObjectScript Connections（動画、6 分）
  • Developing on an InterSystems Server Using VS Code（学習パス、2 時間）
  • VS Code Introduction（「VS Code の導入」ドキュメント）
  • Introducing VS Code – （動画、ヘブライ語による録画ウェビナー、1 時間）
  • Developer Community Videos on VS Code（YouTube チャンネル再生リスト）

• ターミナル / CLI
  • WebSocket ターミナル
    • Using the WebSocket Terminal（「WebSocket ターミナルの使用」ドキュメント）
    • VS Code の統合ターミナルで ObjectScript コマンドを実行する方法（「VS Code の統合ターミナルで ObjectScript コマンドを実行する方法」コミュニティ記事、読了目安 2 分）
  • Web ターミナル *
    • Launch From InterSystems Server Manager（Open Exchange アプリケーション）
    • Web Terminal（Open Exchange アプリケーション）
    • Web Terminal for InterSystems Products（プロジェクトページ）

• デバッグ
  • Running and Debugging（「実行とデバッグ」ドキュメント）
  • VSCode を使った ObjectScript コードのデバッグ（「VSCode を使って ObjectScript コードをデバッグする」コミュニティ記事、読了目安 9 分）
  • Using the VS Code Debugger for InterSystems ObjectScript（動画、6 分）

• サーバーサイド開発
  • Server-side Editing（「サーバーサイド編集」ドキュメント）

• ソース管理
  • クライアントサイドのソース管理
    • Using Git source control VS Code（VS Code ドキュメント）
  • サーバーサイドのソース管理
    • サンプル Git ソースプロジェクト
      • 共有開発環境にてGitを使用する（開発者コミュニティ）
        • Git for Shared Development Environments（Open Exchange アプリケーション）

• コードスニペット
  • Adding your own snippets to VS Code（「VS Code に独自のスニペットを追加する」コミュニティ記事、読了目安 1 分）
  • Load Studio Snippets Command（「Load Studio Snippets（Studio スニペットを読み込む）コマンド」ドキュメント）
  • Share VS Code snippets as IPM / ZPM packages（「IPM / ZPM パッケージとして VS Code スニペットを共有」コミュニティのお知らせ）
    • OEX VS Code Snippets Template（Open Exchange アプリケーション）
  • How to provide VS Code settings, snippets and debug configurations to everyone working server-side in a shared namespace（「サーバーの共有ネームスペースにて作業する皆さんに VS Code の設定、スニペット、およびデバッグ構成を提供する方法」）
    • VS Code per Namespace Settings（Open Exchange アプリケーション）
  • Snippets in Visual Studio Code（VS Code ドキュメント）

• Studio からの移行
  • Migrate from Studio（「Studio からの移行」ドキュメント）

• その他の InterSystems 関連拡張機能 *
  • Testing Manager
    • InterSystems Testing Manager - %UnitTest フレームワーク向けの新しい VS Code 拡張機能（開発者コミュニティ）
    • InterSystems Testing Manager for VS Code（Open Exchange アプリケーション）
    • InterSystems Testing Manager（VS Code Marketplace）
  • Web ターミナルランチャー
    • Launch WebTerminals from InterSystems Server Manager（VS Code Marketplace）
  • SQLTools
    • SQLTools
    • SQLTools Driver for InterSystems
  • Deltanji
    • Deltanji（VS Code Marketplace）
    • Deltanji Source Control（製品ホームページ）
    • Demo of Deltanji: source control tailored for InterSystems IRIS（動画、録画ウェビナー、57 分）
  • objectscriptQuality
    • objectscriptQuality（VS Code Marketplace）
    • CachéQuality for VSCode now available（「VSCode 用 CachéQuality が公開されました」コミュニティのお知らせ）
  • OnwObjectScriptExtension
    • OwnObjectScriptExtension（VS Code Marketplace）
    • Boost your ObjectScript Development with the OwnObjectScriptExtension（「OwnObjectScriptExtension で ObjectScript 開発を強化」コミュニティ記事、読了目安 3 分）

• その他の一般機能関連の拡張機能 *
  • REST API
    • OpenAPI (Swagger) Editor
    • Thunder Client
  • DevOps
    • Docker
    • Kubernetes
    • YAML
  • 医療データ標準規格
    • HL7Tools
    • FHIR Shorthand (FSH)

* サードパーティ製エクステンションはサポートされません

VS Code を使ってコードを編集する場合、設定モデルでは、ワークスペースルートフォルダの .vscode サブフォルダにある settings.json ファイルを使用して、一部の設定にフォルダ固有の値を指定できます。 ワークスペースのルートフォルダ内で作業している場合、ここで設定した値は個人設定の値よりも優先されます。

isfs-type ワークスペースを使用してサーバー上のネームスペースで直接操作している場合は、現在および将来のネームスペースごとに特別な .vscode フォルダをサポートするようにそのサーバーを構成しておく必要があります。 このフォルダはフォルダ固有のコードスニペットとデバッグ起動構成も提供できます。

この機能をセットアップしておくと、設定（またはスニペット、またはデバッグ構成）をサーバーに配置することで、そのサーバーで作業するすべての VS Code ユーザーがすぐにそれを使用できるようになるというメリットがあります。

たとえば、Deltanji ソース管理は、機能拡張を使って VS Code に統合されます。 サーバー側の設定ストレージを使用すれば、結果が設定に依存する場合に、特定のネームスペースに接続するすべての開発者が Deltanji 拡張機能から同じ結果を得ることができるようになります。

サーバーがネームスペースごとに .vscode サブフォルダをホストして公開するように構成するのは、1 回限りのタスクです。 手順はドキュメント化されていますが、サーバーで ZPM / IPM を使用できる場合は、vscode-per-namespace-settings パッケージをインストールすると自動的に実行することができます。 ソースコードを含むこのパッケージの詳細は、Open Exchange をご覧ください。

圧縮と切り捨ての原理は何ですか? パフォーマンスに影響するのかな?

開発者の皆さん、こんにちは！

多くの方が、Open Exchange と GitHub で InterSystems ObjectScript ライブラリを公開しています。

でも、開発者がプロジェクトの使用とコラボレーションを簡単に行えるようにするにはどうしていますか？

この記事では、ファイルの標準セットをリポジトリにコピーするだけで、ObjectScript プロジェクトを簡単に起動して作業する方法をご紹介します。

では始めましょう！

概要 - 以下のファイルをこちらのリポジトリからお使いのリポジトリにコピーしてください。

Dockerfile

docker-compose.yml

Installer.cls

iris.script

settings.json{#9f423fcac90bf80939d78b509e9c2dd2-d165a4a3719c56158cd42a4899e791c99338ce73}

.dockerignore{#f7c5b4068637e2def526f9bbc7200c4e-c292b730421792d809e51f096c25eb859f53b637}
.gitattributes{#fc723d30b02a4cca7a534518111c1a66-051218936162e5338d54836895e0b651e57973e1}
.gitignore{#a084b794bc0759e7a6b77810e01874f2-e6aff5167df2097c253736b40468e7b21e577eeb}

すると、プロジェクトを起動して共同作業する標準的な方法が得られます。 以下は、この仕組みと動作する理由についての記事です。

注意: この記事では、InterSystems IRIS 2019.1 以降で実行可能なプロジェクトを対象としています。

InterSystems IRIS プロジェクトの起動環境の選択

通常、開発者には、プロジェクト/ライブラリを試して、素早く安全な方法であることを確認していただきたいと思っています。

私見としては、新しいものを素早く安全に起動するには、Docker コンテナが理想的だと考えています。起動、インポート、コンパイル、計算するあらゆるものがホストマシンにとって安全であり、いかなるシステムやコードも破壊されたり損なわれたりすることがないことを開発者に保証できるためです。 何らかの問題が発生した場合は、コンテナを止めて削除するだけで済みます。 アプリケーションが膨大なディスクスペースを占有するのであれば、コンテナを削除すれば、容量を解放できます。 アプリケーションがデータベース構成を破損するのであれば、破損した構成のあるコンテナを削除するだけです。 このように単純で安全なのです。

Docker コンテナでは、安全と標準化を得られます。

バニラ InterSystems IRIS Docker コンテナを実行するには、IRIS Community Edition イメージを実行するのが最も簡単です。

1. Docker デスクトップをインストールします。 

2. OS のターミナルで以下を実行します。

docker run --rm -p 52773:52773 --init --name my-iris store/intersystems/iris-community:2020.1.0.199.0

3. 次に、ホストブラウザで管理ポータルを開きます。

http://localhost:52773/csp/sys/UtilHome.csp

4. または IRIS へのターミナルを開きます。

   docker exec -it my-iris iris session IRIS

5. IRIS コンテナが不要になれば、それを停止します。

   docker stop my-iris

さて、 IRIS を Docker コンテナで実行しますが、 開発者にはコードを IRIS にインストールして、いくらかの設定を行ってほしいと考えているとします。 以下ではこれについて説明します。

ObjectScript ファイルのインポート

最も単純な InterSystems ObjectScript プロジェクトには、クラス、ルーチン、マクロ、グローバルなどの一連の ObjectScript ファイルが含めることができます。 命名規則とフォルダ構造の提案についての記事をご覧ください。

問題は、このコードをどのようにして IRIS コンテナにインポートするかです。

ここで役立つのが Dockerfile です。これを使用して、バニラ IRIS コンテナを取得し、リポジトリから IRIS にすべてのコードをインポートして、必要に応じて IRIS で設定を行います。 リポジトリに Dockerfile を追加する必要があります。

ObjectScript テンプレートリポジトリから取得した Dockerfile を調べてみましょう。

ARG IMAGE=store/intersystems/irishealth:2019.3.0.308.0-community
ARG IMAGE=store/intersystems/iris-community:2019.3.0.309.0
ARG IMAGE=store/intersystems/iris-community:2019.4.0.379.0
ARG IMAGE=store/intersystems/iris-community:2020.1.0.199.0
FROM $IMAGE

USER root

WORKDIR /opt/irisapp
RUN chown ${ISC_PACKAGE_MGRUSER}:${ISC_PACKAGE_IRISGROUP} /opt/irisapp

USER irisowner

COPY  Installer.cls .
COPY  src src
COPY iris.script /tmp/iris.script # run iris and initial 

RUN iris start IRIS \
    && iris session IRIS < /tmp/iris.script

最初の ARG の行は $IMAGE 変数を設定しており、それを FROM で使用します。 これは、$IMAGE 変数を変更するために FROM の前の最後の行が何であるかだけを切り替えて、さまざまな IRIS バージョンでコードをテスト/実行するのに適しています。 

以下のコードがあります。 

ARG IMAGE=store/intersystems/iris-community:2020.1.0.199.0

FROM $IMAGE

これは、IRIS 2020 Community Edition ビルド 199 を使用するということです。

リポジトリからコードをインポートするため、リポジトリのファイルを Docker コンテナにコピーする必要があります。 以下の行はそれを行います。

USER root

WORKDIR /opt/irisapp
RUN chown ${ISC_PACKAGE_MGRUSER}:${ISC_PACKAGE_IRISGROUP} /opt/irisapp

USER irisowner

COPY  Installer.cls .
COPY  src src

USER root - ここで、ユーザーをルートに切り替えて、フォルダを作成してファイルを Docker にコピーします。

WORKDIR /opt/irisapp - この行では、ファイルをコピーする workdir をセットアップしています。

RUN chown ${ISC_PACKAGE_MGRUSER}:${ISC_PACKAGE_IRISGROUP} /opt/irisapp   -  ここでは、irisowner ユーザーと IRIS を実行するグループに権限を付与しています。

USER irisowner - ユーザーを root から irisowner に切り替えます。

COPY Installer.cls .  - workdir のルートに Installer.cls をコピーしています。 このピリオドを忘れないでください。

COPY src src - ソースファイルをリポジトリの src フォルダから Docekr の workdir の src フォルダにコピーします。

次のブロックでは、初期スクリプトを実行し、インストーラーと ObjectScript コードを呼び出します。

COPY iris.script /tmp/iris.script # run iris and initial 
RUN iris start IRIS \
    && iris session IRIS < /tmp/iris.script

COPY iris.script / - iris.script をルートディレクトリにコピーします。 コンテナをセットアップするために呼び出す ObjectScript が含まれます。

RUN iris start IRIS</span>  - IRIS を起動します。

&& iris session IRIS < /tmp/iris.script - IRIS ターミナルを起動し、それに最初の ObjectScript を入力します。

以上です！ Docker にファイルをインポートする Dockerfile ができました。 installer.cls と iris.script の 2 つのファイルが残っています。ではそれらを詳しく見てみましょう。

Installer.cls

Class App.Installer
{

XData setup
{
<Manifest>
  <Default Name="SourceDir" Value="#{$system.Process.CurrentDirectory()}src"/>
  <Default Name="Namespace" Value="IRISAPP"/>
  <Default Name="app" Value="irisapp" />

  <Namespace Name="${Namespace}" Code="${Namespace}" Data="${Namespace}" Create="yes" Ensemble="no">

    <Configuration>
      <Database Name="${Namespace}" Dir="/opt/${app}/data" Create="yes" Resource="%DB_${Namespace}"/>

      <Import File="${SourceDir}" Flags="ck" Recurse="1"/>
    </Configuration>
    <CSPApplication Url="/csp/${app}" Directory="${cspdir}${app}"  ServeFiles="1" Recurse="1" MatchRoles=":%DB_${Namespace}" AuthenticationMethods="32"
       
    />
  </Namespace>

</Manifest>
}

ClassMethod setup(ByRef pVars, pLogLevel As %Integer = 3, pInstaller As %Installer.Installer, pLogger As %Installer.AbstractLogger) As %Status [ CodeMode = objectgenerator, Internal ]
{
  #; Let XGL document generate code for this method. 
  Quit ##class(%Installer.Manifest).%Generate(%compiledclass, %code, "setup")
}

}

率直に言って、ファイルのインポートに Installer.cls は必要ありません。 これは 1 行で実行可能です。 ただし、コードをインポートするほかに、CSP アプリのセットアップ、セキュリティ設定の追加、データベースとネームスペースの作成を行わなければなりません。

この Installer.cls では、 IRISAPP という名前で新しいデータベースとネームスペースを作成し、このネームスペースのデフォルトの /csp/irisapp アプリケーションを作成します。

すべては、<Namespace> 要素で行います。

<Namespace Name="${Namespace}" Code="${Namespace}" Data="${Namespace}" Create="yes" Ensemble="no">

    <Configuration>
      <Database Name="${Namespace}" Dir="/opt/${app}/data" Create="yes" Resource="%DB_${Namespace}"/>

      <Import File="${SourceDir}" Flags="ck" Recurse="1"/>
    </Configuration>
    <CSPApplication Url="/csp/${app}" Directory="${cspdir}${app}"  ServeFiles="1" Recurse="1" MatchRoles=":%DB_${Namespace}" AuthenticationMethods="32"
       
    />
  </Namespace>

そして、Import タグを使って、SourceDir からすべてのファイルをインポートします。

<Import File="${SourceDir}" Flags="ck" Recurse="1"/>

この SourceDir は変数であり、現在のディレクトリ/src フォルダに設定されています。

<Default Name="SourceDir" Value="#{$system.Process.CurrentDirectory()}src"/>

これらの設定を含む Installer.cls によって、src フォルダから任意の ObjectScript コードをインポートするわかりやすい新しいデータベース IRISAPP を作成できるという確信を持つことができます。

iris.script

ここに、IRIS コンテナを起動する初期の ObjectScript セットアップコードを挿入してください。

例: 開発にはパスワードのプロンプトは不要であるため、ここでは、installer.cls を読み込んで実行してから、パスワードの初回変更リクエストを回避するために、UserPasswords を永久にしています。

; run installer to create namespace
do $SYSTEM.OBJ.Load("/opt/irisapp/Installer.cls", "ck")
set sc = ##class(App.Installer).setup()  zn "%SYS"
Do ##class(Security.Users).UnExpireUserPasswords("*") ; call your initial methods here
halt

docker-compose.yml

docker-compose.yml はなぜ必要なのでしょうか。Dockerfile と同様に、イメージをただビルドして実行するだけではいけないのでしょうか。 もちろん、そうすることは可能です。 ただし、docker-compose.yml を使用すれば作業が単純になります。

通常、docker-compose.yml は、1 つのネットワークに接続された複数の Docker イメージを起動するために使用されます。

docker-compose.yml は、多数のパラメーターを処理する場合に、1 つの Docker イメージの起動をより簡単にするためにも使用できます。 これを使用すれは、ポートのマッピング、ボリューム、VSCode 接続パラメーターなどを Docker に渡すことができます。

version: '3.6' 
services:
  iris:
    build: 
      context: .
      dockerfile: Dockerfile
    restart: always
    ports: 
      - 51773
      - 52773
      - 53773
    volumes:
      - ~/iris.key:/usr/irissys/mgr/iris.key
      - ./:/irisdev/app

ここでは、サービス iris を宣言しています。これは Dockerfile を使用し、IRIS の 51773、52773、53773 ポートを公開するサービスです。 また、このサービスは、ホストマシンのホームディレクトリの iris.key と期待される IRIS フォルダ、およびソースコードのルートフォルダと /irisdev/app フォルダの 2 つのボリュームのマッピングも行います。

docker-compose によって、セットアップされるパラメーターに関係なく、イメージをビルドして実行するためのコマンドをより短く、統一することができます。

いずれの場合でも、以下のようにしてイメージをビルドします。

$ docker-compose up -d

 そして以下のようにして IRIS ターミナルを開きます。

$ docker-compose exec iris iris session iris

Node: 05a09e256d6b, Instance: IRIS

USER>

また、docker-compose.yml では、VSCode ObjectScript プラグインの接続もセットアップできます。

.vscode/settings.json

ObjectScript アドオン接続設定に関連しているのは、以下の部分です。

{
    "objectscript.conn" :{
      "ns": "IRISAPP",
      "active": true,
      "docker-compose": {
        "service": "iris",
        "internalPort": 52773
      }
    }     

}

ここにあるのは設定です。VSCode ObjectScript プラグインのデフォルトの設定とは異なります。

ここでは、IRISAPP ネームスペース（Installer.cls で作成）に接続すると述べています。

"ns": "IRISAPP",

そして、docker-compose の設定があります。これは、サービス「iris」内の docker-compose ファイルで、VSCode が 52773 がマッピングされているポートに接続すると書かれています。

"docker-compose": {
        "service": "iris",
        "internalPort": 52773
      }

52773 について調べたところ、これはマップされたポートが 52773 に対して定義されていないことがわかります。

ports: 
      - 51773
      - 52773
      - 53773

つまり、ホストマシンのポートで利用できるランダムなポートが取得され、VSCode は自動的にランダムなポートを介して、docker 上でこの IRIS に接続するということです。

これは非常に便利な機能です。IRIS を使用して任意の量の Docker イメージをランダムなポート上で実行し、VSCode をそれらのポートに自動的に接続するオプションが提供されるためです。

他のファイルはどうでしょうか？

以下のファイルもあります。

.dockerignore  - 作成した Docker ファイルにコピーしない不要なホストマシンのファイルをフィルターするために使用できるファイル。 通常、.git や .DS_Store は必須です。

.gitattributes - git の属性。ソース内の ObjectScript ファイルの行末を統一します。 Windows と Mac/Ubuntu オーナーがリポジトリで共同作業する場合に非常に便利です。

.gitignore - Git で変更履歴を追跡しないファイル。 通常、.DS_Store などの非表示の OS レベルのファイルです。

以上です！

リポジトリを Docker 実行可能にし、コラボレーションしやすくするにはどうすればよいでしょうか。

1. このリポジトリをクローンします。

2. 以下のファイルをすべてコピーします。

Dockerfile

docker-compose.yml

Installer.cls

iris.script

settings.json{#9f423fcac90bf80939d78b509e9c2dd2-d165a4a3719c56158cd42a4899e791c99338ce73}

.dockerignore{#f7c5b4068637e2def526f9bbc7200c4e-c292b730421792d809e51f096c25eb859f53b637}
.gitattributes{#fc723d30b02a4cca7a534518111c1a66-051218936162e5338d54836895e0b651e57973e1}
.gitignore{#a084b794bc0759e7a6b77810e01874f2-e6aff5167df2097c253736b40468e7b21e577eeb}

上記をリポジトリにコピーしてください。

Dockerfile のこの行を IRIS にインポートする ObjectScript のあるリポジトリ内のディレクトリに一致するように変更します（in /src フォルダにある場合は変更しません）。

それだけです。 すべての人（あなた自身も含む）が、新しい IRISAPP ネームスペースでコードをインポートできるようになります。

プロジェクトの起動方法

IRIS で ObjectScript プロジェクトを実行するためのアルゴリズムは以下の通りです。

1. プロジェクトをローカルに Git clone します。

2. プロジェクトを実行します。

$ docker-compose up -d

$ docker-compose exec iris iris session iris

Node: 05a09e256d6b, Instance: IRIS

USER>zn "IRISAPP"

**開発者によるプロジェクトへの貢献方法 **

1. リポジトリをフォークして、フォークされたリポジトリをローカルに Git clone します。

2. VSCode でフォルダを開きます（Docker と ObjectScript の拡張機能が VSCode にインストールされている必要があります）。

3. docker-compose.yml を右クリックし、再起動します。VSCode ObjectScript が自動的に接続され、編集/コンパイル/デバッグできるうようになります。

4. リポジトリに変更をコミット、プッシュ、およびプルリクエストします。

以下は、この仕組みを説明する簡単な Gif です。

以上です！ それでは、コーディングをお楽しみください！

IRIS コンテナに VSCode を追加する

繰り返し利用できる開発環境をセットアップするには、環境用のコンテナを起動するのが最も簡単な方法の 1 つです。 素早く繰り返す際には、自分の開発コンテナ内に vscode インスタンスをホストするのが非常に便利なことが分かりました。 そこで、ブラウザベースの vscode を IRIS コンテナに追加するための簡易コンテナスクリプトを作成しました。 これは、ほとんどの 2021.1+ のコンテナで動作するはずです。 私のコードリポジトリはこちらにあります。

vscode を含み事前に接続された InterSystems IRIS コンテナ

概要

このプロジェクトでは、ホストされた（Web ベース）バージョンの vscode を同じコンテナ内で利用できる IRIS コンテナを作成します。 これには、以下が含まれます。

• 同じコンテナコードの編集
• コンテナの IRIS インスタンスへの事前接続
• 管理ポータルからのリンク
• コンテナによる IDE の自動起動

クイックスタート

1. ダウンロードするか、git clone https://github.com/nickmitchko/Hosting-vscode-in-a-container.git を実行します。
2. プロジェクトのルートで次を実行します: docker build . -t vscode-irishealth-ml:latest --no-cache
3. docker-compose up を実行します。
   • Docker Compose を使用していませんか？ こちらをご覧ください。
4. 管理ポータルに移動します。
5. このガイドの始めにあるユーザーとパスワードを使ってログインします。
6. お気に入りのペインで VSCODE リンクをクリックします。
7. プロンプトが表示されたら、vscode で同じパスワードを使用して IRIS インスタンスに接続します。

# プロジェクト用の新しいフォルダ
mkdir vscode-iris
cd vscode-iris

# ここでリポジトリをクローン
git clone https://github.com/nickmitchko/Hosting-vscode-in-a-container.git .

# イメージをビルド
docker build . -t vscode-irishealth-ml:latest --no-cache

# (A) または (B) のいずれかを実行
#
# (A) Compose ファイルを実行
docker-compose up
# または (B) デーモンを使用する場合
docker-compose up -d

永続性を追加する

永続的な IRIS インスタンスを使用する場合は、docker-compose.yml ファイルの 16 行目から 20 行目のコメントを解除します。 これにより、コンテナに永続ストレージマウントが追加されます。

    volumes:
    - "./durable/:/durable/"
    environment:
    - ISC_DATA_DIRECTORY=/durable/iconfig

ベースイメージを変更する

このイメージは、InterSystems 開発者コミュニティ zpm イメージに基づいてビルドされています（こちらにあります）。 これらのイメージには、パッケージリポジトリから簡単にインストールれきる zpm コマンドが含まれていますが、90 日間のコミュニティライセンスしか付帯していません。

ビルドに使用されているイメージタグは以下のとおりです。

FROM intersystemsdc/irishealth-ml-community:latest

イメージを変更する場合は、Docker ファイルの最初の行を希望するイメージタグ（カスタム IRIS インスタンスかサポートされているインスタンスのいずれか）に変更してください。 以下に例を示します。

FROM containers.intersystems.com/intersystems/irishealth-community:2021.2.0.651.0

Docker-Compose を使用しない場合

Docker Compose を使用しない場合でも、以下のようにしてコンテナを実行できます。

# コンテナをビルドした後
# --after コマンドは必須
docker run --name vscode -d \
    --publish 1972:1972 \
    --publish 52773:52773 \
    --publish 51773:51773 \
    --publish 53773:53773 \
    --publish 8080:8080 \
    --publish 8888:8888 \
    vscode-irishealth-ml:latest \
    --after "/bin/bash /install/boot.sh"

2023年5月に発表し、Global Summit 2023 における多くのプレゼンテーションや活発な議論をへて、インターシステムズは Intersytems Studio の非推奨に関する計画を引き続き進めています。（非推奨とは、インターシステムズが積極的に開発しなくなった、より優れたオプションが存在する機能またはテクノロジを示します）

こちらの内容は、今後のリリースにより変わる(不要になる)可能性があります。

バージョン2023.2以降で、IRISスタジオが非推奨となったこともあり、VSCode拡張機能を評価される方も今後増えるかと思います。

既存のCache'資産をお持ちで、ソース管理をソースコントロールフックで実施されている方などにおかれましては、その際にサーバサイド編集を選択される方もおられるかと思います。

VSCode拡張には、Cache'/IRISスタジオの「ファイルから検索」と同じ要領でサーチを行いたいというご要望に応えるための機能が備わっています。その導入方法が、VSCodeの未公開APIを使用している関係で、ひと手間かかるものとなっているため、解説します。

方法は複数ありますが、手順を簡素化するべく、なるべくGUIを使わない方法をご紹介しています。

導入方法

サーバサイドのサーチ機能は、VSCodeの"Proposed API"であるTextSearchProvider,FileSearchProvideを使用しています。 いずれこれらのAPIが安定化してStableとしてリリースされるまでの措置として、これらを使用している拡張機能はマーケットプレイスからの導入(クリックするだけの簡単インストール)が制限されています。

サーバサイドのサーチ機能を使用する目的でVisual Studio Code Insidersリリースを使用する必要はないようです。

それまでは、マニュアルで導入する必要があります。以降、その導入手順をご紹介します。

InterSystems ObjectScriptのベータ版を導入

使用中のバージョンの「次のバージョン」のbeta.1をインストールします。

VSCode拡張は、日々更新・改良されていますので、常に最新バージョンを保つことをお勧めします。

使用中のバージョンは、下記で確認できます。

この例では2.10.3ですので、2.10.4-beta.1をダウンロードし、ダウンロードされたファイル(拡張子vsix)を、Extentionsにドラッグ＆ドロップします。

再起動を促されますので、VSCodeを再起動します。

Proposed APIを有効化

Command Paletteで"Preferences: Configure Runtime Arguments"を選択し、下記を追加します。

	"enable-proposed-api": ["intersystems-community.vscode-objectscript"]

実体はC:\Users\Windowsユーザ名.vscode\argv.jsonにありますので、直接編集しても良いです。

// This configuration file allows you to pass permanent command line arguments to VS Code.
// Only a subset of arguments is currently supported to reduce the likelihood of breaking
// the installation.
//
// PLEASE DO NOT CHANGE WITHOUT UNDERSTANDING THE IMPACT
//
// NOTE: Changing this file requires a restart of VS Code.
{
	// Use software rendering instead of hardware accelerated rendering.
	// This can help in cases where you see rendering issues in VS Code.
	// "disable-hardware-acceleration": true,

	// Allows to disable crash reporting.
	// Should restart the app if the value is changed.
	"enable-crash-reporter": true,

	// Unique id used for correlating crash reports sent from this instance.
	// Do not edit this value.
	"crash-reporter-id": "xxxxxxxxxxxxx",

	"enable-proposed-api": ["intersystems-community.vscode-objectscript"]
}

有効化されると、OUTPUT(ObjectScript)に下記のようなメッセージが表示されるようになります。

VSCodeのワークスペースを作成・保存

VSCodeのワークスペースを作成・保存して、アクセスしたいIRIS環境を追加(感覚的にはマウントする感じです)します。

この作業はUIで行っても良いのですが、ここではワークスペースの設定ファイル(.code-workspace.code-workspace)を直接編集する方法をご紹介します。ワークスペースの設定ファイルをVSCode自身で編集するには、いったん、フォルダとして開き直します。

編集後の.code-workspace.code-workspaceは下記のようになります。

{
	"folders": [
		{
			"name": "local:scdemo",
			"uri": "isfs://local:scdemo/",
		},
		{
			"name": "local:samples",
			"uri": "isfs://local:samples/"
		},
		{
			"path": "."
		}
	],
	"settings": {
		"objectscript.showExplorer": false,
		"intersystems.servers": {
			"local": {
				"webServer": {
					"scheme": "http",
					"host": "localhost",
					"port": 52773
				},
				"username": "SuperUser"
			}
		}
	}
}

上記の意味は

• local:scdemoという名前(name)で,アクセス先サーバ isfs://local/ のネームスペースscdemoを、ワークスペースにマウントする
• local:samplesという名前(name)で,アクセス先サーバ isfs://local/ のネームスペースsamplesを、ワークスペースにマウントする
• フォルダの"."、つまりルートフォルダをワークスペースにマウントする（これはローカルにファイルがなければ不要です）
• ただしサーバlocalの実体は、http://localhost:52773/ 、IRISユーザ名SuperUserを使用する

となります。IRISサーバのホスト名やポート、ユーザ名は、環境に合わせて変更してください。

nameは、検索対象のフォルダ名の一部として使用されますので、あまり長くすると、サーチ結果を読みにくくなります。

これでサーバサイド編集やサーバサイドサーチを使用する準備が出来ました。ワークスペースとして開き直してください。

ご参考までに、UIで行う方法は下記になります。

接続するIRISサーバの定義と、ネームスペース指定して、仮想的なファイルシステムであるisfsをワークスペースに追加します。

使用

ここまでの作業を行ったフォルダをGitHubで公開してありますので、ご利用ください。git cloneした後に、フォルダ内の.code-workspace.code-workspaceをワークスペースとして開いて使用します。

うまく設定が出来ていれば、Exploreに下記のようなフォルダが表示されます。

この時点で、各フォルダをクリックすれば、IRISサーバ内の要素がツリー表示され、編集、保存(コンパイル)可能になっているはずです。

初めてアクセスする場合はパスワードを聞いてきます。以降、The extenstion 'InterSystems Language Server' wants to sign in using InterSystems Server Credentials.と表示されたら、Allowを押して使用するCredential(SupseUser on localなど)を選択してください。この辺りは、通常のサーバサイド編集時の操作と同じです。

肝心のサーチ機能ですが、Control+シフト+Fを押してファイルサーチ機能を開いてください。普通にVSCodeでファイルサーチを行う要領で、サーチワードを入力すると、ヒットした対象が列挙されます。大量にヒットした場合、(画像のように)Collapse Allアイコンで全体を折りたたんで、まずはヒット件数表示すると良いかもしれません。

files to includeにフォルダ指定するのと同じ要領で、フィルタ設定すると、サーチ対象もフィルタされます。

EnsLibパッケージを対象にする場合。

ワイルドカードを含む場合。

MACのみを対象にする場合。

名前が分かっている場合は、Quick Open機能を使用できます。フォルダツリーを使って、大量に存在するクラスやルーチンの中から、編集対象をピックアップするのが大変な時に役立ちます。

開発者の皆さん、こんにちは！

ObjectScriptのコード実行中にエラーが発生した場合 "<UNDEFINED>HelloWorld+2^Simple.Demo.1 *name" のようなエラーメッセージが表示されます。

エラーメッセージの読み方については、ObjectScriptクックブックの「ObjectScriptでエラーが発生したら」のエラーメッセージの読み方 をご参照ください。

エラー行の特定を行う際、VSCodeのコマンドパレットを利用すると簡単に対象行にジャンプできますので、以下、方法をご紹介します。

1）VSCodeのView→Command Palette...　を開きます。

2) 「ObjectScript:Open Error Location...」を選択します（初回は表示項目に登場しないため > の後ろに ObjectScript と入力すると表示されます）。

3) テキストボックスが表示されるので、エラーメッセージの出力情報の中から　ラベル名＋行数^生成ルーチン名 をコピーして貼り付け、Enterをクリックします。

※スタジオにも同様の機能がありますが、VSCodeの場合対象となるコード（生成コードの元コード）をVSCode上で表示していなくても対象となる生成ルーチンを開きエラー行をポイントしてくれます。

開発者の皆さん、こんにちは！

スタジオを利用されている方にはお馴染みのソースコードの「XMLファイルへのエクスポート／インポート機能」がVSCodeのObjectScriptエクステンションに追加されました！ （ObjectScript 2.10.0以降に含まれています。こちらのリクエストが元となりました👉https://github.com/intersystems-community/vscode-objectscript/issues/1158   エクステンションの追加番号は#1171です）

今まで、過去エクスポートしたXMLファイルをVSCodeから参照するためには、管理ポータル（またはスタジオ）を利用してインポートする必要がありましたが、VSCodeの画面だけでできるようになりました！

💡注意1： InterSystems IRIS ／InterSystems IRIS for Health 2023.2以降のバージョンに接続した状態でご利用いただける機能です。

💡注意2：この機能は管理ポータルやスタジオのインポート／エクスポートのVSCode版のような機能となるため、インポートしたソースコードはサーバ側にインポートされ、エクスポートはサーバ側コードを選択してXMLファイルにエクスポートする動作となります。XMLファイルインポート後、VSCodeのワークスペースでローカルファイル（*.cls や *.mac）として編集 したい場合は、 ObjectScriptエクステンションマークをクリックし、対象のコードを選択→エクスポート の手順でローカルにエクスポートする必要があります。

開発者の皆さん、こんにちは！

ご存知のように、InterSystems IRIS インターオペラビリティソリューションには、プロダクション、ビジネスルール、ビジネスプロセス、データ変換、レコードマッパーなどの様々なエレメントが含まれています。 また、UI ツールを使用してこれらの要素を作成し、変更することもあります。  もちろん、UI ツールで行った変更をソース管理する便利で堅牢な方法も必要です。

長い間、これは手動（クラス、エレメント、グローバルなどのエクスポート）か面倒な設定作業手順によって行われてきました。そのため、ソース管理 UI の自動化で節約された時間は、設定のセットアップとメンテナンスの時間で相殺されていました。

現在では、この問題はなくなりました。 パッケージファースト開発と @Timothy Leavitt の git-source-control という IPM パッケージの使用という 2 つのアプローチによる結果です。

詳細は以下のとおりです！

免責事項: これは、インターオペラビリティのプロダクションのエレメントがリポジトリ内のファイルである場合の、クライアント側の開発アプローチに関連しています。

よって、ソリューションは非常に単純であるため、この記事は長くありません。

Docker で開発しており、IRIS を使って開発環境の Docker イメージをビルドしたら、ソリューションを IPM モジュールとして読み込んでいるとします。 これは、「パッケージファースト」開発と呼ばれ、関連する動画や記事が存在する手法です。 基本的には、開発環境の Docker イメージを IRIS でビルドすると、クライアントのサーバーにデプロイされるときに、ソリューションがパッケージとして読み込まれるという考え方になります。

ソリューションのパッケージファースト開発環境を作るには、module.xml をリポジトリに追加し、そのすべての要素を記述して、Docker イメージのビルドフェーズで「zpm load "repository/folder"」コマンドを呼び出します。

この考え方を、サンプルテンプレートの IRIS Interoperability template とそれに使用する module.xml を使って示しましょう。 パッケージは、Docker ビルド中に以下のように読み込まれています。

zpm "load /home/irisowner/irisdev/ -v":1:1

ソース 

パッケージソース管理を読み込む前に配置された以下の 2 行を見てください。 これにより、ソース管理はパッケージ内のすべての相互運用性要素に対して自動的に動作し始め、適切なフォルダに適切な形式でエクスポートされます。

zpm "install git-source-control"do##class(%Studio.SourceControl.Interface).SourceControlClassSet("SourceControl.Git.Extension")

ソース

仕組み

最近、git-source-control アプリは、開発モードで読み込まれるソース管理用の IPM パッケージをサポートするようになりました。 エクスポートするフォルダを読み取り、module.xml からソースの構造をインポートします。 詳細は、@Timothy Leavitt が説明できます。

ターミナルで、環境がビルドされた後の IPM モジュールのリストを確認すると、読み込まれたモジュールが実際に開発モードになっているのが分かります。

USER>zpm=============================================================================
|| Welcome to the Package Manager Shell (ZPM).                             ||
|| Enter q/quit to exit the shell. Enter ?/help to view available commands ||
=============================================================================
zpm:USER>list
git-source-control      2.1.0
interoperability-sample 0.1.2 (DeveloperMode)
sslclient               1.0.1
zpm:USER>

では試してみましょう。 

このリポジトリをクローンし、VSCode で開いてイメージをビルドしました。 以下では、相互運用性 UI とソース管理をテストしています。 UI に変更を加えるとすぐに、ソースと差分に表示されます。

できました！ それだけです！ 

まとめると、プロジェクトで相互運用性 UI 要素のソース管理を行うには、以下を行います。

1. Docker イメージをビルド中に、iris.script に 2 行を追加します。

zpm "install git-source-control"do##class(%Studio.SourceControl.Interface).SourceControlClassSet("SourceControl.Git.Extension")

その後、以下のようにして、ソリューションをモジュールとして読み込みます。

zpm "load /home/irisowner/irisdev/ -v":1:1

2. または、Interoperability template からリポジトリを作成して新規に始めることもできます。

お読みいただきありがとうございました！ コメントやフィードバックをお待ちしています！

コミュニティの皆さん、こんにちは！

最近では、誰もが Github、GitLab、bitbucket などのリポジトリにプロジェクトのソースコードを保管していると思います。 InterSystems IRIS プロジェクトについても同様で、Open Exchange にチェックされています。

InterSystems Data Platform で特定のリポジトリの操作を開始または継続するたびに、何をしているでしょうか？

ローカルの InterSystems IRIS マシン、プロジェクト用の環境のセットアップ、ソースコードのインポートが必要です。

つまり、すべての開発者は以下を実行しています。

1. リポジトリからコードをチェックアウトする。
2. ローカル IRIS インストールをインストール/実行する。
3. プロジェクト用の新しいネームスペース/データベースを作成する
4. コードをこの新しいネームスペースにインポートする。
5. すべての残りの環境をセットアップする。
6. プロジェクトのコーディングを開始/継続する。 

リポジトリを Docker 化すると、この手順は次の 3 つのステップに短縮できます。

1. リポジトリからコードをチェックアウトする。
2. docker-compose build を実行する。 
3. プロジェクトのコーディングを開始/継続する。 

メリット: 実行に数分かかる上、頭が痛くなるようなステップ 3、4、5 を行わなくて済みます。

次の数ステップで、（ほぼ）すべての InterSystems リポジトリを Dcoker 化できます。 では、やってみましょう！

**リポジトリを Docker 化する方法は？その意味は？ **

基本的に、マシンに Docker をインストールし、コードと環境をコンテナに構築し、そのコンテナを Docker で実行すれば、最初に開発者が導入した方法で動作するようにするという考えです。 「OS のバージョンは何？」や「この IRIS インストールには他に何かあった？」といった疑問はありません。

毎回、クリーンなページ（またはクリーンな IRIS コンテナ）を使用して環境（ネームスペース、データベース、ウェブアプリ、ユーザー/ロール）がセットアップされ、作成したばかりのクリーンなデータベースにコードがインポートされます。

この「Docker 化」手順によって、現在のリポジトリに大きな悪影響が及ぶでしょうか？ 

及びません。 リポジトリのルートに独自にセットアップできるいくつかのツールに従った 2～3 個の新しいファイルを追加する必要があります。

前提条件

docker をダウンロードしてインストールします。

IRIS docker イメージをダウンロードしてインストールします。 この例では、WRC-preview からダウンロードできる完全な InterSystems IRIS プレビュー（iris:2019.1.0S.111.0）を使用します。詳細をご覧ください。

キーを必要とするインスタンスを操作する場合は、常に使用する場所に iris.key を配置します。  私の場合は、Mac の Home ディレクトリに置きました。

リポジトリの Docker 化

リポジトリを Docker 化するには、リポジトリのルートフォルダに 3 つのファイルを追加する必要があります。

こちらは、ISC-DEV プロジェクトの Docker 化されたレポジトリの例です。これは、IRIS データベースからソースコードをインポート/エクスポートするのに役立ちます。  このリポジトリには、以下に説明する追加の Dockerfile、docker-compose.yml、および installer.cls が含まれています。

まず、Dockerfile です。これは、docker-compose build コマンドで使用されます。

<p>
</p>

<p>
  WORKDIR /opt/app
</p>

<p>
  COPY ./Installer.cls ./
</p>

<p>
  COPY ./cls/ ./src/
</p>

<p>
  RUN iris start $ISC_PACKAGE_INSTANCENAME quietly EmergencyId=sys,sys && \
</p>

<p>
      /bin/echo -e "sys\nsys\n" \
</p>

<p>
              # ユーザー管理者に %ALL を付与
</p>

<p>
              " Do ##class(Security.Users).UnExpireUserPasswords(\"*\")\n" \
</p>

<p>
              " Do ##class(Security.Users).AddRoles(\"admin\", \"%ALL\")\n" \
</p>

<p>
              # インストーラのインポートと実行
</p>

<p>
              " Do \$system.OBJ.Load(\"/opt/app/Installer.cls\",\"ck\")\n" \
</p>

<p>
              " Set sc = ##class(App.Installer).setup(, 3)\n" \
</p>

<p>
              " If 'sc do \$zu(4, \$JOB, 1)\n" \
</p>

<p>
              # OS レベルの認証を導入（コンテナのログイン/パス プロンプトを削除するため）
</p>

<p>
              " Do ##class(Security.System).Get(,.p)\n" \
</p>

<p>
              " Set p(\"AutheEnabled\")=p(\"AutheEnabled\")+16\n" \
</p>

<p>
              " Do ##class(Security.System).Modify(,.p)\n" \
</p>

<p>
              " halt" \
</p>

<p>
      | iris session $ISC_PACKAGE_INSTANCENAME && \
</p>

<p>
      /bin/echo -e "sys\nsys\n" \
</p>

<p>
      | iris stop $ISC_PACKAGE_INSTANCENAME quietly
</p>

<p>
  CMD [ "-l", "/usr/irissys/mgr/messages.log" ]
</p>   

<p>
   
</p>

この Dockerfile は installer.cls とソースコードをリポジトリの /cls フォルダから /src フォルダ、そしてコンテナにコピーします。

また、いくつかの構成設定も実行します。これにより、管理者ユーザーに %All ロールと無期限のパスワード「SYS」が付与され、OS レベルの認証が導入され、%Installer が実行されます。 

%Installer とは何でしょうか？

Class App.Installer
{
XData MyInstall [ XMLNamespace = INSTALLER ]
{
<Manifest>
  <Default Name="NAMESPACE" Value="ISCDEV"/>
  <Default Name="DBNAME" Value="ISCDEV"/>
  <Default Name="APPPATH" Dir="/opt/app/" />
  <Default Name="SOURCESPATH" Dir="${APPPATH}src" />
  <Default Name="RESOURCE" Value="%DB_${DBNAME}" /> 

  <Namespace Name="${NAMESPACE}" Code="${DBNAME}-CODE" Data="${DBNAME}-DATA" Create="yes" Ensemble="0">
    <Configuration>
      <Database Name="${DBNAME}-CODE" Dir="${APPPATH}${DBNAME}-CODE" Create="yes" Resource="${RESOURCE}"/>
      <Database Name="${DBNAME}-DATA" Dir="${APPPATH}${DBNAME}-DATA" Create="yes" Resource="${RESOURCE}"/>
    </Configuration>
    <Import File="${SOURCESPATH}" Recurse="1"/>
  </Namespace>

</Manifest>
}

ClassMethod setup(ByRef pVars, pLogLevel As %Integer = 3, pInstaller As %Installer.Installer, pLogger As %Installer.AbstractLogger) As %Status [ CodeMode = objectgenerator, Internal ]
{
  Return ##class(%Installer.Manifest).%Generate(%compiledclass, %code, "MyInstall")
}

}

これは、ネームスペース/データベース ISCDEV を作成し、ソースフォルダである -/src からコードをインポートします。

次は、docker-compose.yml ファイルです。これは、docker-compose up コマンドでコンテナを実行するときに使用されます。

version: '2.4'
services:
  iris:
    build: .
    restart: always
    ports:
      - 52773:52773
    volumes:
      - ~/iris.key:/usr/irissys/mgr/iris.key

この構成によって、Docker に対し、ホストのどのポートで IRIS の動作が期待されるかを指示します。 最初（52773）はホスト、2 つ目はコンテナのコンテナ内部ポート（52773）です。

volumes セクションでは、docker-compose.yml は、IRIS が検索するコンテナ内でマシン上の iris キーへのアクセスを提供します。

- ~/iris.key:/usr/irissys/mgr/iris.key

このリポジトリでコーディングを始めるには、以下を実行します。

1. 任意のローカルディレクトリにリポジトリを Clone/git pull します。

 2. このディレクトリでターミナルを開き、以下を実行します。

user# docker-compose build

これによりコンテナがビルドされます。

3. プロジェクトで IRIS コンテナを実行します。

user# docker-compose up -d

お好きな IDE を開いて、localhost://52773 のサーバーに接続し、InterSystems IRIS Data Platform で作業を始めましょう！;)

この 3 つのファイルを使用して、リポジトリを Docker 化できます。 Dockerfile のソースコードに適切な名前、Installer.cls に適切なネームスペースを付けて、docker-compose.yml に iris.key を配置するだけで、InterSystems IRIS を使った日常の開発で、Docker コンテナを活用することができます。

開発者の皆さん、こんにちは！

IRISのRESTディスパッチクラスのデバッグがVSCodeで簡単にできるようになりましたので、利用手順についてご紹介します。

開発者の皆さん、こんにちは！

InterSystems デベロッパーツールコンテスト2023 の21の応募作品の中から、Experts Nomination 第3位に輝いた @Lorenzo Scalese  さんの OpenAPI-Suite（OpenAPI3.0 からObjectScriptコードを生成するためのツールセット）についてご紹介します。

現時点でIRISはOpenAPI2.0までの対応なのですが、このツールの凄いところは、OpenAPI3.0に対応しているところです！

提供している機能は、以下の通りです。

1. サーバー側クラスの作成（OpenAPI2.0と同様に、APIファーストで作成するRESTディスパッチクラスの作成に必要なクラス群を作成します。）
2. HTTPクライアントクラスの作成
3. クライアントプロダクション（ビジネス・サービス、ビジネス・オペレーション、ビジネス・プロセス、Ens.Request、Ens.Response）
4. このツールから生成する機能を指定できるWebインターフェース
5. OpenAPI 1.x、2.x からバージョン3.0への変換ツール

各機能について詳しくは、@Lorenzo Scales さんが書かれた記事「OpenAPI Suite - Part 1」「OpenAPI Suite - Part 2」をご参照ください。

開発者の皆さん、こんにちは！

InterSystems デベロッパーツールコンテスト2023 の21の応募作品の中から、Experts Nomination 第2位に輝いた @John Murray  さんの DX Jetpack for VS Code （VSCodeを使用するIRIS開発者のエクスペリエンスを向上させるツール）についてご紹介します。

開発された @John Murray さんが書かれた記事「Introducing DX Jetpack for VS Code」には、3つの新しいエクステンションについて紹介されていますが、ここでは、gj :: codeSpex と ObjectScript Class View の使用例をご紹介します。

まずは、VSCodeをご用意ください。

Extentionの検索窓で、gj と入力する以下の表示になります。

この中から、をインストールしてみました。

試しにクラス定義を作成してみたところ、行番号右隣に吹き出しのマークが登場し、クリックするとクラス定義で使用しているデータタイプの解説が表示されました。

クラスメソッドの場合は、そのメソッドで使用している引数や戻り値のデータタイプを表示してくれました。

クラスリファレンスをいちいち開いて確認しなくても、エディタ上で確認ができて便利ですね。

開発者の皆さん、こんにちは！

InterSystems IRIS で embedded python を使用する一般的なプロジェクトの出発点として推奨できる、最小限の embedded python テンプレート をご紹介しましょう。

特徴:

• Embedded python対応
• Embedded Pythonの3つの開発方法の例
• VSCode開発対応
• Dockerが利用可能
• オンラインデモが可能
• ZPM First開発対応。

以下、その特徴について説明しましょう。

Embedded Pythonによる3つの開発モード

ObjectScript から python のライブラリをコールする

これは、%SYS.Pythonクラスにより、Pythonのライブラリをインポートし、ObjectScirptを介してPythonをコールすることができるようになったからです。 ドキュメント, 例. 以下のコードを参照してください。

ClassMethod Today() As%Status
{
  Set sc = $$$OKSet dt = ##class(%SYS.Python).Import("datetime")
  write dt.date.today().isoformat()
  Return sc
}

Python で ObjectScript クラスメソッドを記述する

実際、開発者はメソッドのシグネチャに [Language=python] タグを付けて、pure python でコーディングできるようになった。また、ObjectScriptのクラスやグローバルを参照するためのヘルパーpythonライブラリ "iris"も用意されています。 ドキュメント、例、以下のサンプルコード

ClassMethod CreateRecordPython(propValue As %VarString, ByRef id As %Integer) [ Language = python ]
{
    import iris
    obj=iris.cls(__name__)._New()
    obj.Test=propValue
    sc=obj._Save()
    id=obj._Id()
    return sc
}

InterSystems IRISソリューションのpure pythonでのコーディング

これは、開発者がIRISを扱う方法の3番目のオプションです。  ここでは、pythonスクリプトをIRISに接続する必要があり、これはENV変数とCallInサービスの "On "を介して行うことができます（詳細は以下を参照）。一度セットアップされたPythonスクリプトは、IRISとの共有メモリで実行されます。ここで、"iris" ライブラリが非常に役に立ちます。 ドキュメント, 例. 

defcreate_rec(var):
    obj=iris.cls('dc.python.PersistentClass')._New()
    obj.Test=var
    obj._Save()
    id=obj._Id()
    return id

# テストレコード作成from datetime import datetime
now=str(datetime.now())
print("dc.python.PersistentClass　で新しいレコードを作成する")
print(create_rec(now))

## SQLを実行し、データをプリントするdefrun_sql(query):
    rs=iris.sql.exec(query)
    for idx, row in enumerate(rs):
        print(f"[{idx}]: {row}")

query="dc_python.PersistentClass から * を選択する"
print("SQLクエリの実行 "+query)
run_sql(query)

Dockerが可能

テンプレートリポジトリは、コンテナ内でIRISを実行し、Embedded Pythonの調整に必要なすべてをセットアップします。

環境変数。Embedded PythonはIRISに接続してPythonスクリプトを実行するために、特定の環境変数の設定を必要とします。以下は、それを助ける設定をdockerfileに記述しています：

# init Python env
ENV PYTHON_PATH=/usr/irissys/bin/irispython
ENV SRC_PATH=/irisrun/repo
ENV IRISUSERNAME "SuperUser"
ENV IRISPASSWORD "SYS"
ENV IRISNAMESPACE "USER"

また、Embedded Python は CallIn サービスを "ON" にする必要があり、これは docker build フェーズで iris.script で行われます。

; Embedded Pythonのcallinを可能do##class(Security.Services).Get("%Service_CallIn",.prop)
    set prop("Enabled")=1set prop("AutheEnabled")=48do##class(Security.Services).Modify("%Service_CallIn",.prop)

また、あなたのソリューションには、いくつかの Python ライブラリのインストールが必要かもしれません。これは、リポジトリのルートにある requirements.txt とdockerfileにある pip3 コールによって提供されます：

pip3 install -r requirements.txt && \

VSCode開発対応

VSCodeでdockerを使って開発するのはとても便利です。Embedded pythonのVSCodeを使ったIRISソリューションをdockerで開発する場合、Devcontainer modeに切り替える必要があります。 .devcontainer フォルダに devcontainer.json ファイル を導入してください。これは、どのDockerサービスと連携する必要があるかを記述しており（私たちのケースではirisです）。コンテナ内で動作しているIRISが使用するPythonエンジンが提供するVSCode内のPythonスクリプトを実行するのに役立ちます。 devcontainer.json ファイルには、コンテナモードでどの extensions を使用する必要があるのかを記述したセクションもあります。

"extensions": [
        "ms-python.python",
        "ms-python.vscode-pylance",
        "intersystems-community.vscode-objectscript",
        "intersystems.language-server",
        "intersystems-community.servermanager",
        "ms-vscode.docker"
    ],

ZPMを使用したEmbedded Pythonソリューションのインストール

このテンプレートは、「ZPM first」開発リポジトリとして設定されています。つまり、開発したコードはすべて module.xml に記述され、Docker イメージをビルドするたびに ZPM モジュールとしてインストールされます。つまり、開発者は毎回 iris.script の 次の行 からコーディングを開始します：

zpm "load /home/irisowner/irisbuild/ -v":1:1

そして、Embedded pythonのコードもZPMモジュールに記述され、FILECOPYを介してインストールされます：

この式は、リポジトリ内の /python フォルダにあるすべての python スクリプトをパッケージ化し、ターゲット IRIS インストールの libdir 内の python/ フォルダにインストールしたいことを意味します。python スクリプトが ${libdir}python/ フォルダにコピーされると、ターゲット IRIS マシンの ObjectScirpt または Python からのインポート コールに利用できるようになります。

注意：他のPythonコードを誤って上書きしないように、Pythonスクリプトのフォルダ名称は、ユニークなものにしてください。

このテンプレートがあなたのお役に立つことを願っています。フィードバック、特にプルリクエストは大歓迎です。

こんにちは、普段はスタジオを使っているのですが、サーバＣＳＰフォルダ内のＨＴＭＬファイルを編集する事があり、便利なのでたまにＶＳＣＯＤＥを利用しています。以前はＨＴＭＬファイルも表示していたと思うのですが、何をやらかしたのかCSP,CSS,MACのみになりました。int,html,jsなどの他のファイルを表示する設定をご存知の方いらっしゃいましたらご教授お願い致します。

InterSystems Language Serverv2.1.4　InterSystems ObjectScriptv2.2.0　InterSystems Server Managerv3.2.1
vscode
Version: 1.74.1 (user setup)
Commit: 1ad8d514439d5077d2b0b7ee64d2ce82a9308e5a
Date: 2022-12-14T10:30:51.966Z
Electron: 19.1.8
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Windows_NT x64 10.0.18363
Sandboxed: No

VSCode から直接 Web ターミナルにアクセスしたいと思いませんか？

原理と結果は同じですが、ユースケースは異なります。

VSCode から Web ターミナルを開きたいと仮定します（この優れたツールをまだあまり使用できない方は、作成者 @Nikita Savchenko 本人のこちらのホームページをご覧ください）。前の記事で説明したものに似たアプローチを使用できます。

もう一度その手順を説明します -

• ObjectScript 拡張機能の JSON 設定を開きます。
• 'conn' オブジェクトに 'links' オブジェクトを追加します。
• 'links' 内に以下の行を追加します。

以下のようになります。

これを行ったら、VSCode の下のステータスバーで［接続］をクリックすると、メニューに Web ターミナルが表示されます。

これは、こちらの VSCode ObjectScript の GitHub 課題ディスカッション（上記の URL で使用される ${...} 変数に関する内容）で @John Murray が提案したものです。

以下の GIF では、このプロセスを簡単に実演しています（標準のメニューから Web ターミナルを起動するオプションまで）。

Studio では、クラスを直接その名前で開くことができます。何度もクリックしながら目的のクラスに到達するまでパッケージツリー内を移動する必要はありません。

Ctrl + O（またはファイル -> 開く）を押せば、以下のようにクラス名を入力するだけです。

Enter を押すと、クラスが開きます。

VSCode ではこれをどのようにして行えるでしょうか？

以下に、例を示します。

このソリューションは、@Dmitry Maslennikov が GitHub 課題レポート（強化リクエストに指定）に提案したものです。「Open Class by Name from Server（サーバーから名前でクラスを開く）」というタイトルで、この種の機能に関するレポートが提出されていました。

以下は、この機能の GIF による簡単なデモです。

少し前に GitHub が導入されてから、そこにホストされているあらゆるリポジトリの VSCode をブラウザで非常に素早く実行できるようになりました。 リポジトリで . キーかプルリクエストを押すか、URL で .com を .dev に置き換えることで、ブラウザ内で VSCode 環境に直接移動することができます。

この VSCode はデスクトップバージョンのライトバージョンではありますが、完全にブラウザ内で動作します。 このため、このような動作を可能にする拡張機能には制限があります。 そこで、VSCode-ObjectScript 拡張機能の新しい 1.2.1 バージョンをご紹介します。ブラウザモードでの実行がサポートされています。

この新しい環境でリポジトリを開き、拡張機能に移動し、VSCode-ObjectScript 拡張機能を検索してインストールするだけで、使用することができます。 一旦インストールすればすべてのリポジトリで利用できるようになり、次を開きます。

これは同じ拡張機能ですが、今のところ基本的な機能しかありません。 構文のハイライト機能のみです。 確かに、実行中の IRIS にアクセスすることはできませんが、今後、オフラインで利用可能な機能が追加されるでしょう。

GitHub を使用しない

ブラウザで VSCode を実行したくても GitHub リポに関連付けられていない場合には、ローカルフォルダを開くだけのオプションもあります。 https://vscode.dev です。 VSCode-ObjectScript はそこでも利用可能になっています。

しばらく前、GitHubはGitHub Codespacesという新しい機能を発表しました。 ブラウザでVSCodeを実行する機能があります。マシンでローカルに実行するのとほぼ同じ性能がありますが、クラウドの能力も備わっているため、最大32CPU、64 GB RAMのマシンタイプを選択することが可能です。

素晴らしいことですね。 でも、このことは、InterSystems IRISで駆動するプロジェクトで作業する上で、どのように役立つのでしょうか。 それをどのように構成するのか見てみましょう。

あらゆるリポジトリに対応できる基本の出発点

この機能を使用すると、［Code］ボタンを押せば、クラウド内のあらゆるリポジトリを編集できるようになります。 この機能はまだベータ段階にあるため、すべての人が利用できるわけではないことに注意してください。ベータ期間が終了すれば、有料アカウントでのみ利用できるようになります。

このリポジトリは、VSCodeのみに準備されているだけであり、Codespaces用として特別に用意されたものではありません。 ［New codespace］ボタンを押すと、自分だけの環境を作成できます。

私の場合、以前のCodespacesの使用においてObjectScript拡張機能をインストールし、Codespacesからプロンプトでグローバルに有効にしています。 毎回インストールされるため、ObjectScriptコードはすでにハイライト表示されています。 しかし、IRISはまだ利用できないため、 まずはdocker-composeから始めましょう。

それが済むと、IRIS Terminalに接続し、コードをコンパイルできるようになります。

docker-composeのポートは自動的に認識され、ブラウザで開くことができるため、システム管理ポータルを開くことも可能です。

準備済みのリポジトリでの使用

VSCodeとIRISをクラウドで実行することはできましたが、準備段階で手動での作業がいくつかありました。 しかし、開始直後にリポジトリを開発できるようにすることもできます。

devcontainer.jsonを使うと可能です。 私の最近のプロジェクトの1つであるRealworldに基づく例を紹介します。 このプロジェクトは非常に複雑で、バックエンドとフロントエンドがあり、docker-composeを使用してすべてをまとめて起動します。 

devcontainerはdocker-composeも使用する可能性があるため、私の構成は次のようになりました。

{
  "name": "IRIS RealWorld example",
  "dockerComposeFile": "docker-compose.yml",
  "service": "server",
  "extensions": [
    "intersystems-community.vscode-objectscript"
  ],
  "forwardPorts": [
    80,
    52773
  ],
  "workspaceFolder": "/home/irisowner/conduit",
  "remoteUser": "irisowner",
  "postCreateCommand": "iris start iris",
  "settings": {
    "terminal.integrated.defaultProfile.linux": "bash",
    "terminal.integrated.profiles.linux": {
      "bash": {
        "path": "bash",
        "icon": "terminal-bash"
      },
      "iris": {
        "path": "iris",
        "args": ["session", "iris"]
      }
    },
    "intersystems.servers": {
      "/ignore": true
    },
    "objectscript.ignoreInstallServerManager": true,
    "objectscript.ignoreInstallLanguageServer": true,
    "objectscript.conn": {
      "active": true,
      "host": "localhost",
      "port": 52773,
      "ns": "CONDUIT",
      "username": "demo",
      "password": "demo",
      "links": {
        "Conduit APP": "http://localhost:80/",
        "Conduit API": "http://${host}:${port}/conduit/"
      }
    }
  }
}

ここでは多くの事項が構成されています。

• 主としてCodespacesのためのカスタムdocker-compose.ymlへのパス
• 開発が行われるメインサービスの名前 
• VSCodeにデフォルトでインストールされる拡張機能のリスト
• 公開する必要のあるポート。この場合はIRIS用とフロントエンド用のWebサーバーポート
• 作業ディレクトリへのパス
• コンテナ内のユーザー。IRISコンテナに入るときに、irisownerユーザーが必要です。 
• デフォルトのエントリポイントであるiris-mainを使用せずに、単に無限にスリープし、環境が起動した後に自分でIRISを起動するように構成されたdocker-compose内のIRISコンテナ
• 最後に、VSCodeの設定もここで構成可能です。これはマシンレベルの設定です。 必ず.vscode/settings.jsonでオーバーライドまたはアペンドできます。

このようなリポジトリ向けのCodespacesを起動するには、すべての必要なコンテナをビルドして開始する必要があるため、もう少し時間がかかります。 GitHubは、このようなイメージをリポジトリにプッシュした後にプリベイクして、起動を高速化することが可能だと述べています。

そして、それが開始すると、何の操作も必要なく、開発の準備が完了しています。

このプロジェクトには、用意されたPostmanテストを使用してREST APIをテストするオプションがあるため、IRISでバックエンドコンテナ内にnpmとnewmanをインストールしました。 そこでテストを実行することができます。 すべて合格です。よくできました。

そしてフロントエンド部分を使用できます。

GitHubでは、ローカルのVSCodeからでもCodespacesに接続できるようになっています。 隅にある緑色のCodespacesを押すと、VC Codeで開くことを選択できます（GitHub Codespaces 拡張機能がインストールされている必要があります）。

これは、ローカルのVSCodeで開いたプロジェクトですが、ifconfigの結果からわかるように、クラウドで実行されています。私は今、絶対にシンガポールにはいません。

GitHub Codespacesなしでブラウザーで実行

Codespaces機能にアクセスできない場合、またはこの方法では使用したくないが、ブラウザーでVSCodeを試してみたい場合は、どうすればよいでしょうか。

もう1つのプロジェクトであるcode-serverを使えば可能です。

このVSCodeを次のコマンドで実行するだけです。

docker run -it -p 8080:8080 codercom/code-server --auth=none

デフォルトバージョンのVSCodeが実行されます。フォルダがマッピングされていないため、任意のフォルダをマウントし、それをworkdirに設定すると、内部を見れるようになります。 

docker run -it -p 8080:8080 -v `pwd`:/opt/realworld -w /opt/realworld codercom/code-server --auth=none

これはデフォルトのVSCodeで、ObjectScript拡張機能はインストールされていません。 拡張機能の制限があり、元のVSCodeマーケットプレイスへのアクセスがありませんが、代わりにopen-vsx.orgという別のプレイスを使用しています。また、メインのObjectScript拡張機能もそこに提供されています。

このようなDockerfileを使用すると、そこに何でもインストールされ、一部の拡張機能もすでにインストールされた独自のCode Serverをベイクすることができます。

FROM codercom/code-server

USER root

RUN curl -fsSL https://deb.nodesource.com/setup_15.x | bash - && \
    apt-get install -y jq nodejs python3-pip python3-dev unixodbc-dev && \
    rm -rf /var/lib/apt/lists/* && \
    pip3 install pyodbc && \
    npm install -g yarn && \
  sudo chown -R 1000:1000 /home/coder

COPY extensions extensions

COPY settings.json /root/.local/share/code-server/User/settings.json

ENV SERVICE_URL=https://open-vsx.org/vscode/gallery
ENV ITEM_URL=https://open-vsx.org/vscode/item

RUN \
  code-server --install-extension ms-python.python && \
  code-server --install-extension intersystems-community.vscode-objectscript && \
  find extensions -type f -exec code-server --install-extension {} \;

WORKDIR /opt/intersystems

CMD [ "--auth=none", "--disable-telemetry" ]

一部のユーザーレベルのデフォルトのsettings.jsonを定義し、必要な拡張機能がopen-vsxにない場合は、手動でダウンロードして、Dockerfileの隣にあるextensionsフォルダに配置すれば、インストールできます。

これで、必要なすべての拡張機能がインストールされた新しいcode-serverを実行できるようになりました。

docker run -it -p 8080:8080 -v `pwd`:/opt/realworld -w /opt/realworld <strong>caretdev/code-server</strong> --auth=none

また、構文ハイライトもすでに存在しています。後はIRIS自体を実行するだけですが、拡張docker-composeを使って行えます。code-serverはIRISに並ぶ単なるもう1つのサービスとして扱われます。

*この動画は、2021年2月に開催された「InterSystems Japan Virtual Summit 2021」のアーカイブです。
 

VSCodeのObjectScript用エクステンションバージョン1.0がリリースされ、GitやDockerなどの標準技術とIRISを手軽に組み合わせて利用できるようになりました。 開発者コミュニティでは、IRISをもっと簡単に操作いただけるようコンテナ版IRISを利用した開発環境テンプレ―トやObjectScriptパッケージマネージャを公開しています。

この動画では「VSCodeからIRISに接続する方法」「開発環境テンプレートの使い方」「パッケージマネージャの使い方」をご紹介します。

この動画の講演資料（PDF)もご用意しました。
動画の中でご紹介している技術資料へのURLは、こちらの資料をご活用ください。

今回は、InterSystems IRIS に特有のことではなく、職場で Windows 10 Pro または Enterprise を搭載した PC またはノートパソコンがサーバーとして使用されている環境で Docker を使用する場合に重要と思われる点について触れたいと思います。

ご存知かと思いますが、コンテナテクノロジーは基本的に Linux の世界で生まれ、最近では Linux のホストで使用されており、その最大のポテンシャルを伺わせています。 Windows を普段から使用するユーザーの間では、Microsoft と Docker 両社によるここ数年の重大な試みにより、Windows のシステムで Linux イメージを基にコンテナを実行することがとても簡単になったと理解されています。しかし、生産システムでの使用がサポートされておらず、それが大きな問題となっています。特に、Windows と Linux のファイルシステムに大きな違いがあるため、安心してホストシステム内でコンテナの外に持続データを保管するということができないのです。 ついには、コンテナを実行するために、_Docker for Windows _自体で Linux の小さな仮想マシン (MobiLinux) が使用されるようになり、Windows ユーザーに対しては透過的に実行されます。また、先ほど述べたように、データベースの存続がコンテナよりも短くて構わないのであれば、パーフェクトに動作します。

では、何が言いたいかというと、問題を回避して処理を単純化するには、完全な Linux システムが必要になるが、Windows ベースのサーバーを使用していると、仮想マシンを使用する以外に方法がない場合が多い、ということです。 少なくとも、Windows の WSL2 がリリースされるまでの話ですが、それはまた別の機会に触れたいと思います。もちろん、十分堅牢に動作するまでは時間がかかるでしょう。

この記事では、必要に応じて、Windows サーバーの Ubuntu システムで Docker コンテナを使用できる環境をインストールする方法について分かりやすく説明します。 それでは、始めましょう。

1. Hyper-V を有効にする

まだ有効にしていない方は、Windows Featuresを追加し、Hyper-V を有効にしてください。 そして再起動します (現在の私のロケールにより、テキストはスペイン語になっています。 ドン・キホーテの言語をご存知ない方は手順を参照しながら「解明」できることを願っています 😉 ) 

2. Hyper-V 上で Ubuntu の仮想マシンを作成する

これ以上簡単に仮想マシン (VM) を作成する方法はないと思います。 Hyper-V Manager のウィンドウを開き、   Quick Create... オプション (画面一番上近く) を選択します。そして、画面に表示されている Ubuntu バージョンのいずれかを使って仮想マシンを作成します (どの Linux の場合でも、_iso _file をダウンロードすれば、別のディストリビューションの VM を作成できます)。 私は、使用可能な Ubuntu の最新リリース 19.10 を選択しました。 ここで表示されるものはすべて 18.04 に対応しています。 イメージのダウンロードにかかる時間によりますが、15～20 分ほどで新しい VM が作成され、使用を開始できます。

3. ローカルサブネットを作成する

仮想マシンを使用するときによく目にする問題の 1 つに、ネットワーク設定に関連して起こるものがあります。動作が不安定であったり、WiFi に接続しているときは動作してもケーブルだと駄目な場合があったり、もしくはその逆の場合もあります。また、Windows ホストで VPN を確立すると、VM のインターネットアクセスを失ったり、VM (Linux) とホスト (Windows) 間のコミュニケーションが遮断されたりすることもあり、はっきり言って大変なんです！  ノートパソコンで開発作業を行ったり、簡単なデモやプレゼン資料を作成したりするとき、つまりインターネットにアクセスできることよりも、自分のホストと VM が確実に通信できることの方が重要であるときに、自分の作業環境を信頼できなくなってしまいます。

アドホックのローカルサブネットを Windows ホストと仮想マシン間で共有すれば、それを解決できます。 相互に通信し合えるようにするには、そのサブネットを使用します。 ホストと VM に特定の IP を割り当てれば準備完了です。

その方法はいたって簡単。 まずは、Hyper-V Manager にある Virtual Switch Manager... に移動します。

そこで、_New Virtual Switch __ _オプションを選択します (VM の新しいネットワークカードとして機能します)。

内部ネットワーク  として定義し、好きな名前を選び、他のオプションはデフォルトのままにしておきます。

Windows Control Panel --> Network and Sharing Center と移動すれば、作成したばかりのスイッチが既に表示されています。

4. ホストと仮想マシン間で共有されるローカルサブネットを設定する

この時点で、新しいローカルネットワークの設定を完了します。 そのためには、Mi Nuevo Conmutador LOCAL にカーソルを合わせて、Properties をクリックし、それから IPv4 protocol へと移動して固定 IP アドレスを割り当てます。

5. 新しいローカルネットワークを設定し、仮想マシンにリンクする

ここで、 Hyper-V Manager に戻ります。 VM が実行中であれば、停止してください。 停止したら、その設定に移動し、新しい内部仮想スイッチを追加します。

_(注意: 画像には他のスイッチ Hyper-V Conmutador INTERNO が表示されています。 これは私のもう 1 つのサブネット用のもので、 この設定には必要ありません) _

「Add」をクリックしたら、 前回作成したスイッチを選択します。

これが済んだら、「Apply」、「Accept」と順にクリックして準備完了です！ 仮想マシンを起動し、もう一度ログインしてから内部接続の設定を完了します。 そうするには、VM が起動した後に画面右上のネットワークアイコンをクリックします。すると 2 つのネットワーク eth0 y eth1 が表示されます。  eth1 は、この時点では切断された状態で表示されます。

Ethernet (eht1) の設定に移動し、このローカルサブネットに固定 IP を割り当てます (例: IP 155.100.101.1、サブネットマスク _ 255.255.255.0_)。

これで完了です。 これで仮想マシンが出来上がり、ホストと同じサブネットを共有する IP 155.100.101.1 として識別されます。

7. 仮想マシンから Windows 10 へのアクセスを許可する

大抵の場合、Windows 10 のデフォルト設定では、他のサーバーからのアクセスが許可されていません。Windows システムについては、たった今作成した VM がまさにそのサーバー (外部の潜在的に危険なサーバー) に該当します。このため、こういった仮想マシンからホストに接続するには、ファイアウォールにルールを追加する必要があります。 どうするのかって？ いたって簡単です。Windows Control Panel の中から Windows Defender Firewall を見つけて、Advance Configuration に移動し、新規の Entry Rule を作成します。

1 つのポートまたは 1 つ以上の範囲を設定できます... (すべてのポートに対しルールを設定することもできます)...

ここで役に立つのが Allow Connection です。

_ネットワークのすべてのタイプ_オプションを選択し...

ルールに名前を付けます。

ここで重要なことがあります。上記の手順が終わったら、新しく作成したルールのプロパティをもう一度開き、ルールをローカルサブネット内の接続に対してのみ適用できるよう適用範囲を制限しておきます。

8. 準備。 Docker と他に使用するアプリケーションを新しい Ubuntu 仮想マシンにインストールする

インストールプロセスを完了し、新しい VM を最新の状態に整え、インターネットアクセスなども準備ができたら、 好きなアプリをインストールできます。 少なくとも、元々の目的である Docker、また会社のネットワークへの接続に必要であれば VPN クライアント、さらには VS Code、Eclipse+Atelier などのアプリもインストールできます。

具体的に、VM 内で Docker をインストールする場合は、こちらの手順に従ってください: https://docs.docker.com/install/linux/docker-ce/ubuntu/。

Docker ランタイムの動作確認、テストイメージのダウンロードなどが済んだら、準備完了です。

¡You're all set! が表示されたら、Ubuntu 仮想マシンでコンテナを (ハードウェアのキャパシティ内で) 制限なしに動作させることができます。同仮想マシンには、Windows 10 ホストやブラウザー、アプリなどから接続したり、またはその逆、Ubuntu VM から Windows 10 ホストに接続したりもできます。 このすべてに共有ローカルサブネット内で設定した IP アドレスが使用されるため、VPN を確立するしないに関わらず、またインターネットへのアクセスに Wi-Fi アダプターを使用するのか、イーサネットケーブルを使用するのかに関わらず、接続に失敗することはありません。

それから、アドバイスがもう 1 つだけあります。 Windows 10 と仮想マシンの間でファイルを交換する場合は、WinSCP を使用すると簡単で便利です。 無料ですし、とても良く機能します。

もちろん、使える設定は他にもありますが、私は一番確実な方法としてこれを使っています。 お役に立つことを期待しています。 皆さんの悩みの種を取り除くことができれば、この記事を書いた価値があったと言えるでしょう。

¡ハッピーコーディング! 

 Windows10 ホストで実行される Hyper-V Ubuntu 仮想マシンで Docker を使用できるように環境を設定する

今回は、InterSystems IRIS に特有のことではなく、職場で Windows 10 Pro または Enterprise を搭載した PC またはノートパソコンがサーバーとして使用されている環境で Docker を使用する場合に重要と思われる点について触れたいと思います。

ご存知かと思いますが、コンテナテクノロジーは基本的に Linux の世界で生まれ、最近では Linux のホストで使用されており、その最大のポテンシャルを伺わせています。 Windows を普段から使用するユーザーの間では、Microsoft と Docker 両社によるここ数年の重大な試みにより、Windows のシステムで Linux イメージを基にコンテナを実行することがとても簡単になったと理解されています。しかし、生産システムでの使用がサポートされておらず、それが大きな問題となっています。特に、Windows と Linux のファイルシステムに大きな違いがあるため、安心してホストシステム内でコンテナの外に持続データを保管するということができないのです。 ついには、コンテナを実行するために、_Docker for Windows _自体で Linux の小さな仮想マシン (MobiLinux) が使用されるようになり、Windows ユーザーに対しては透過的に実行されます。また、先ほど述べたように、データベースの存続がコンテナよりも短くて構わないのであれば、パーフェクトに動作します。

では、何が言いたいかというと、問題を回避して処理を単純化するには、完全な Linux システムが必要になるが、Windows ベースのサーバーを使用していると、仮想マシンを使用する以外に方法がない場合が多い、ということです。 少なくとも、Windows の WSL2 がリリースされるまでの話ですが、それはまた別の機会に触れたいと思います。もちろん、十分堅牢に動作するまでは時間がかかるでしょう。

この記事では、必要に応じて、Windows サーバーの Ubuntu システムで Docker コンテナを使用できる環境をインストールする方法について分かりやすく説明します。 それでは、始めましょう。

1. Hyper-V を有効にする

まだ有効にしていない方は、Windows Featuresを追加し、Hyper-V を有効にしてください。 そして再起動します (現在の私のロケールにより、テキストはスペイン語になっています。 ドン・キホーテの言語をご存知ない方は手順を参照しながら「解明」できることを願っています 😉 ) 

2. Hyper-V 上で Ubuntu の仮想マシンを作成する

これ以上簡単に仮想マシン (VM) を作成する方法はないと思います。 Hyper-V Manager のウィンドウを開き、   Quick Create... オプション (画面一番上近く) を選択します。そして、画面に表示されている Ubuntu バージョンのいずれかを使って仮想マシンを作成します (どの Linux の場合でも、_iso _file をダウンロードすれば、別のディストリビューションの VM を作成できます)。 私は、使用可能な Ubuntu の最新リリース 19.10 を選択しました。 ここで表示されるものはすべて 18.04 に対応しています。 イメージのダウンロードにかかる時間によりますが、15～20 分ほどで新しい VM が作成され、使用を開始できます。

3. ローカルサブネットを作成する

仮想マシンを使用するときによく目にする問題の 1 つに、ネットワーク設定に関連して起こるものがあります。動作が不安定であったり、WiFi に接続しているときは動作してもケーブルだと駄目な場合があったり、もしくはその逆の場合もあります。また、Windows ホストで VPN を確立すると、VM のインターネットアクセスを失ったり、VM (Linux) とホスト (Windows) 間のコミュニケーションが遮断されたりすることもあり、はっきり言って大変なんです！  ノートパソコンで開発作業を行ったり、簡単なデモやプレゼン資料を作成したりするとき、つまりインターネットにアクセスできることよりも、自分のホストと VM が確実に通信できることの方が重要であるときに、自分の作業環境を信頼できなくなってしまいます。

アドホックのローカルサブネットを Windows ホストと仮想マシン間で共有すれば、それを解決できます。 相互に通信し合えるようにするには、そのサブネットを使用します。 ホストと VM に特定の IP を割り当てれば準備完了です。

その方法はいたって簡単。 まずは、Hyper-V Manager にある Virtual Switch Manager... に移動します。

そこで、_New Virtual Switch __ _オプションを選択します (VM の新しいネットワークカードとして機能します)。

内部ネットワーク  として定義し、好きな名前を選び、他のオプションはデフォルトのままにしておきます。

Windows Control Panel --> Network and Sharing Center と移動すれば、作成したばかりのスイッチが既に表示されています。

4. ホストと仮想マシン間で共有されるローカルサブネットを設定する

この時点で、新しいローカルネットワークの設定を完了します。 そのためには、Mi Nuevo Conmutador LOCAL にカーソルを合わせて、Properties をクリックし、それから IPv4 protocol へと移動して固定 IP アドレスを割り当てます。

5. 新しいローカルネットワークを設定し、仮想マシンにリンクする

ここで、 Hyper-V Manager に戻ります。 VM が実行中であれば、停止してください。 停止したら、その設定に移動し、新しい内部仮想スイッチを追加します。

_(注意: 画像には他のスイッチ Hyper-V Conmutador INTERNO が表示されています。 これは私のもう 1 つのサブネット用のもので、 この設定には必要ありません) _

「Add」をクリックしたら、 前回作成したスイッチを選択します。

これが済んだら、「Apply」、「Accept」と順にクリックして準備完了です！ 仮想マシンを起動し、もう一度ログインしてから内部接続の設定を完了します。 そうするには、VM が起動した後に画面右上のネットワークアイコンをクリックします。すると 2 つのネットワーク eth0 y eth1 が表示されます。  eth1 は、この時点では切断された状態で表示されます。

Ethernet (eht1) の設定に移動し、このローカルサブネットに固定 IP を割り当てます (例: IP 155.100.101.1、サブネットマスク _ 255.255.255.0_)。

これで完了です。 これで仮想マシンが出来上がり、ホストと同じサブネットを共有する IP 155.100.101.1 として識別されます。

7. 仮想マシンから Windows 10 へのアクセスを許可する

大抵の場合、Windows 10 のデフォルト設定では、他のサーバーからのアクセスが許可されていません。Windows システムについては、たった今作成した VM がまさにそのサーバー (外部の潜在的に危険なサーバー) に該当します。このため、こういった仮想マシンからホストに接続するには、ファイアウォールにルールを追加する必要があります。 どうするのかって？ いたって簡単です。Windows Control Panel の中から Windows Defender Firewall を見つけて、Advance Configuration に移動し、新規の Entry Rule を作成します。

1 つのポートまたは 1 つ以上の範囲を設定できます... (すべてのポートに対しルールを設定することもできます)...

ここで役に立つのが Allow Connection です。

_ネットワークのすべてのタイプ_オプションを選択し...

ルールに名前を付けます。

ここで重要なことがあります。上記の手順が終わったら、新しく作成したルールのプロパティをもう一度開き、ルールをローカルサブネット内の接続に対してのみ適用できるよう適用範囲を制限しておきます。

8. 準備。 Docker と他に使用するアプリケーションを新しい Ubuntu 仮想マシンにインストールする

インストールプロセスを完了し、新しい VM を最新の状態に整え、インターネットアクセスなども準備ができたら、 好きなアプリをインストールできます。 少なくとも、元々の目的である Docker、また会社のネットワークへの接続に必要であれば VPN クライアント、さらには VS Code、Eclipse+Atelier などのアプリもインストールできます。

具体的に、VM 内で Docker をインストールする場合は、こちらの手順に従ってください: https://docs.docker.com/install/linux/docker-ce/ubuntu/。

Docker ランタイムの動作確認、テストイメージのダウンロードなどが済んだら、準備完了です。

¡You're all set! が表示されたら、Ubuntu 仮想マシンでコンテナを (ハードウェアのキャパシティ内で) 制限なしに動作させることができます。同仮想マシンには、Windows 10 ホストやブラウザー、アプリなどから接続したり、またはその逆、Ubuntu VM から Windows 10 ホストに接続したりもできます。 このすべてに共有ローカルサブネット内で設定した IP アドレスが使用されるため、VPN を確立するしないに関わらず、またインターネットへのアクセスに Wi-Fi アダプターを使用するのか、イーサネットケーブルを使用するのかに関わらず、接続に失敗することはありません。

それから、アドバイスがもう 1 つだけあります。 Windows 10 と仮想マシンの間でファイルを交換する場合は、WinSCP を使用すると簡単で便利です。 無料ですし、とても良く機能します。

もちろん、使える設定は他にもありますが、私は一番確実な方法としてこれを使っています。 お役に立つことを期待しています。 皆さんの悩みの種を取り除くことができれば、この記事を書いた価値があったと言えるでしょう。

¡ハッピーコーディング!