ネットワークとスタンドアロンの２つのアプリケーションIDの存在理由とAPIでの使用方法について確認できる説明書はありませんか？

2021.07.09

質問

3.の質問への回答に対して追加質問があります。

＞サンプルでオフライン認証、または貸出の操作を行った場合、起動時認証画面は表示されません。
＞B-rite SDK には RestoreSession という関数があり、端末で管理されている認証情報(メールアドレス、パスワード、ライセンス形態、有効期限)を参照します。
＞このとき、オンライン認証または貸出に対しては、有効期限内ならば認証が有効と判定されます。
＞サンプルではこの関数を利用して、起動時認証画面の表示を不要にしています。

と書かれている RestoreSession ですが、この関数仕様を見るとネットワークライセンスアプリケーション ID とスタンドアロンラインセンスアプリケーション ID の二つのアプリケーションIDを指定することになっています。
このアプリケーションIDはサンプルでは

const wchar_t* CBriteClient::m_ApplicationId = L"7";
const wchar_t* CBriteClient::m_StandaloneApplicationId = L"7";

と同じ値になっていました。

私は、IJCAD の製品グレード LT/STD/PRO) 単位にアプリケーション ID を設定することを考えていましたが、RestoreSession 関数や LoginForm 関数では同一製品に対してネットワークとスタンドアロンの２つのアプリケーション ID を指定することになっています。

また、BriteSDK概要.xlsx に書かれた、C# の API には、Login 関数がありますが、C++ の API では、この関数がありません。
C#のLogin関数では、

LoginType loginType ログイン種類。以下のどちらかを指定する。 LoginType.Network ：ネットワークライセンス LoginType.Permanent：スタンドアロンライセンス

との引数仕様になっており、上記2つのアプリケーション ID の扱いとは異なるようです。
これら2つのアプリケーション ID の存在理由と API での使用方法について確認できる説明書はありませんか？

【参考記事】
■ オフライン認証 / 貸出の操作を行い対象アプリを起動した時に「起動時認証画面」は表示されますか？

回答

この部分には歴史的な経緯があります。

もともと B-rite 1 では、ネットワークライセンスのアプリ ID とスタンドアロンライセンスのアプリ ID が別々に定められていました。
先ほど、アプリ ID はプロセスを分ける識別子であると説明しましたが、B-rite 1 ではネットワークとスタンドアロンのアプリが、同じプロセスであるにも関わらず違うアプリ ID でした。
これは B-rite 1 の DB 上の設計ミスです。
原因は、アプリケーションの属性としてネットワーク、スタンドアロンを設定していたからです。
一つのアプリ ID につき、ネットワークかスタンドアロンのどちらかしか選択できない仕様でした。

問題があることは気づいてましたが、アプリケーションは B-rite DB の根本にあるテーブルのため、修正による影響範囲は大きいと思われました。それで辻褄合わせとして、SDK の方で二つのアプリ ID を指定する、ということをして回避していました。

これを B-rite 2 では解消しました。
ネットワークとスタンドアロンの属性は、アプリケーションからライセンスの方に移しました。
SDK は B-rite 1 の名残で、二つのアプリ ID を指定するようになっていますが、B-rite 2 では同じアプリ ID を指定してください。
ミスを誘発しないようにするために、将来的には関数の引数を一つにするかもしれません。

＞私は、IJCAD の製品グレード (LT/STD/PRO) 単位にアプリケーション ID を設定することを考えていました

B-rite 2 ではその設定で大丈夫だと思います。

返答

アプリケーション ID の扱い方については理解できました。
エラーの原因を認識するための詳細コードの案(基準)としては、GS 社から提示されている「glmcode.h」が参考になると思いますので、この対応については、CAD1 課と合同で検討しておいてください。
私の希望としては、Win32 API の GetLastError 関数のように、API 呼び出し結果が「失敗」の時に、別の関数を呼び出すことで詳細なエラーコードを参照できる関数を追加していただけると、既存の API の仕様を変えること無く実現できるのでありがたいです。