こんにちは。CData Software Japanリードエンジニアの杉本です。
今回は Power BI Connector でカスタムスキーマを利用する場合に遭遇する可能性があるエラーおよびその回避策について紹介したいと思います。
発生するエラーおよび条件について
まず、遭遇する可能性がある条件およびエラー内容について確認しておきましょう。
これはCData Power BI Connectorを使って、「カスタムスキーマ」を利用しており、かつ「オンプレミスデータゲートウェイ」を使ってPower BI Serviceにレポート・データセットをパブリッシュ、その後データセットを更新しようとした場合に発生します。
www.cdata.com
https://www.cdata.com/jp/blog/2019-02-14-112834
発生するエラーは主に2種類です。
以下のようにPower BI Service上でデータセットを更新しようとして、以下のようにアラートが出ます。
ここで「基になるエラー メッセージ テーブルに表示可能な列がなく、照会できません。」というエラー
もしくは「データ ソース エラーThe 'instock_changed(特定のカラム名になります)' column does not exist in the rowset.」というエラーです。
この問題で奇妙な点は「Power BI Desktop」では正常に読み取れてしまうというところです。
原因について
このエラーメッセージが発生する原因は内部的に生成しているカスタムスキーマファイルが読み取れない場合に発生します。
カスタムスキーマファイルは接続設定の「%APPDATA%\CData\MongoDB Data Provider\Schema」に生成・読み取りされるようになっており
以下のような拡張子が「.rsd」ファイル形式のXMLで定義されているものです。
<apiscript xmlnsapi="http://apiscript.com/ns?v1" xmlnsxs="http://www.w3.org/2001/XMLSchema" xmlnsother="http://apiscript.com/ns?v1">
<apiinfo title="fruits" desc="This rsd file is generated by MongoDB driver." othertabletype="TABLE">
name="_id" xstype="string" key = "true" columnsize = "2000" readonly = "false" isNullable = "false" otherdatasourcedatatype = "bson:ObjectId" otherbsonpath = "$._id"/>
name="code" xstype="string" columnsize = "2000" readonly = "false" isNullable = "true" otherdatasourcedatatype = "string" otherbsonpath = "$.code"/>
name="name" xstype="string" columnsize = "2000" readonly = "false" isNullable = "true" otherdatasourcedatatype = "string" otherbsonpath = "$.name"/>
name="price" xstype="int" columnsize = "4" precision = "10" readonly = "false" isNullable = "true" otherdatasourcedatatype = "integer" otherbsonpath = "$.price"/>
name="instock_changed" xstype="int" columnsize = "4" precision = "10" readonly = "false" isNullable = "true" otherdatasourcedatatype = "integer" otherbsonpath = "$.instock"/>
apiinfo>
<apiset attr="collection" value="fruits"/>
<apiset attr="schema" value="test"/>
apiscript>
そして、この「%APPDATA%\CData\MongoDB Data Provider\Schema」に含まれる「%APPDATA%」パスなのですが、これはPower BI Connectorの実行ユーザーによって動的に切り替わってしまいます。
Power BI DesktopでCData Power BI Connectorを利用する場合は、Power BI Desktopのユーザーが実行ユーザーとなるため、「C:\Users\{ユーザー名}\AppData\Roaming\CData\MongoDB Data Provider\Schema」を読み取るのですが
もし、以下のようにオンプレミスデータゲートウェイを使っている場合は、ゲートウェイサービスアカウントによって、実行されるため参照先のパスが変わってしまうのです。
ちなみに私の環境だと「C:\Windows\ServiceProfiles\PBIEgwService\AppData\Roaming\CData\MongoDB Data Provider\Schema」が参照されてしまいます。
これにより参照するべきカスタムスキーマファイルが読み取れずに、Power BI Service上だけでエラーが発生します。
回避策について
回避策はシンプルです。以下の「Location」パスを絶対値パス(ないし任意の絶対値パス)に切り替えることで対応できます。
例えば私の環境だと「C:\Users\sugim\AppData\Roaming\CData\MongoDB Data Provider\Schema」になります。
これで改めてPower BI Service上でデータセットを更新すると、正常にデータが反映されます。
カスタムスキーマについて
最後にちょっとだけカスタムスキーマというものについて解説しておこうと思います。
CData Power BI Connector のいくつかのデータソースでは「カスタムスキーマ」と呼ばれる独自のデータモデルを定義する機能が存在します。
これは例えば、「MongoDB」や「ElasticSearch」などNoSQL系のデータソースに接続する際によく利用されます。
www.cdata.com
通常NoSQL系のデータソースはCData Power BI Connectorがデータモデルとして扱いやすくするために、自動キーマ検出という機能を用いて、対象のNoSQLに外部からデータモデルを算出して当てはめます。
cdn.cdata.com
しかしながら、ネストが深いデータやスキャン対象のデータに含まれていない場合、カスタムで調整する必要が出てくるため、前述のようなカスタムスキーマファイルを利用するシチュエーションがあります。
このXMLファイルをカスタマイズすることで、表示したいカラムの追加やカラム名などの調整を柔軟に行うことができるようになっています。
おわりに
今回の事象の根幹は「%APPDATA%」パスが動的に変わるため発生する問題になっていました。
今回のようなケース以外にも異なるサービスがConnectorを利用する場合には類似の事象が発生する可能性があります。
もし気になるエラーなどが発生した場合には、どうぞお気軽にテクニカルサポートまで問い合わせしてみてください。
https://www.cdata.com/jp/support/submit.aspx
関連コンテンツ