- このトピックには7件の返信、3人の参加者があり、最後に
により7年、 6ヶ月前に更新されました。
-
投稿
-
kintoneからの帳票出力のベストプラクティスとして、ReportsConnectの可能性を感じている者です。
「ReportsConnect for kintoneの使い方ブログ」では、あるアプリのデータの明細部分の出力方法について、kintoneのテーブルを使った場合の例が２通り（テーブル名を入れるやり方と、親JRXMLファイル名を入力するやり方）掲載されていますが、明細としてkintoneのテーブルを使うのではなく、明細部分が別アプリになっているような場合でも出力できるものかどうか伺わせてください。
親アプリがアプリAとして、そのレコードIDを親レコードIDとして記録したアプリBのレコード群があるようなイメージです。kintone上では「関連レコード一覧」でアプリAの詳細画面にアプリBの関連レコードを表示させることができますが、このようなものはReportsConnectで出力可能でしょうか？
Salesforce版の方のブログにある
http://kptech.cocolog-nifty.com/blog/2012/11/reports-conne-2.html
が、似たような話をしているのだと思いますが、kintoneの場合はどのようになるのか、確認したいと思っています。よろしくお願い致します。
実は、ご指摘の機能が実現できないかTryしてみたのですが、
このケースの場合、私の調べた限り、KintoneのアプリA側のデータから１対NのN件側のデータにREST APIでアクセスする方法がありません。
したがって、アプリAを対象とした場合、ReportsConnectからB側のデータを出すことはできません。しかし、逆に１対NのN件側のアプリから１側のデータをアクセスするのはルックアップを経由して可能なはずです。
このケースで帳票印刷するとすれば、アプリB側のルックアップからアプリA側の必要なフィールドをすべてルックアップのフィールドのコピーの機能を使用してB側で見られるようにしておけば、アプリBを対象とした帳票を作る事で実現できるとおもいますが、いかがでしょう？早速のご検討とアドバイス、ありがとうございます。
アプリB側のルックアップからアプリA側の必要なフィールドをすべてコピーしておいて、アプリBで帳票出力するというのはできそうですね！これは一つの解だと思います。
しかしここで「コピー」という言葉が使われている通り、kintoneのルックアップはいわゆる完全なリレーションではなくて、ルックアップ時にコピーするだけのものなので、その後一方の値が変わっても、他方の値は置いてきぼりなんですよね。。（使い勝手を優先したkintoneの緩さ＝良い面でもあるのですが）
ですので話は飛躍しますが、親子テーブルのようなことをkintoneで実現しようとした場合、ルックアップはあまり使わず、ある意味自前でレコードID同士を結びつけるようなことをやっています。
また、操作感として、親レコードを作っり、そこから子レコードを複数作っていくという流れの方が自然なケースがあるので、先の話とも合わせて、最近はアプリアクションというのをうまく使うようにしています。
アプリアクションでアプリAからアプリBの新規レコード作成をキックする時に、アプリAのレコードIDを、アプリBの親レコードIDフィールドにコピーするのです。こうすることで、割ときっちりしたリレーション関係をAとBの間で作ることができます。
このような構造だと、アプリA側に関連レコード一覧パーツを置いて、アプリA.レコード番号＝アプリB.親レコード番号という条件で、アプリBの関連レコードを表示させることもできます。
（しかしルックアップを使わないので、Bのルックアップフィールドのリンクをクリックして親のAレコードを開くというようなことは自前で作らない限りできなくなりますが。。）ということで、上記のような構造であれば、アプリAからアプリBのレコードをREST APIでも引っ張れるのではないかと妄想しているのですがいかがでしょうか？
しかし、kintoneの標準的な作り方ではないので、ReportsConnect自体に無理な改変が入るのもあまり好ましくないとも思っていたり。。>しかしここで「コピー」という言葉が使われている通り、kintoneのルックアップはいわゆる完全なリレーションではなくて、
>ルックアップ時にコピーするだけのものなので、その後一方の値が変わっても、他方の値は置いてきぼりなんですよね。これは、知りませんでした。しかし、マスタールックアップがきちんとできないというのは問題ですね。Kintoneはテーブル間Joinの機能がかなり弱いという印象です。
なにしろ、ルックアップを使用した場合、REST APIからは前述のアプリAからアプリBのデータにアクセスできないどころか、アプリBの外部キーに相当するルックアップのフィールドではアプリA側のアプリIDすらわからないのでほとんどお手上げです。おっしゃるとおり、自前の外部キーを作って、それでアプリ間を関連付けるのは一つの方法だと思います。REST APIで読むとすると、複数回APIを発行すれば読めるでしょう。
ただし、ReportsConnectで実現するには、そのJoinを表現するための自前のクエリーの文法を作るような事になってしまうでしょう。
今のところ、標準のAPIの文法の範囲で、１回のクエリー文で読めるものをデータソースとするという方針はSalesforceの方も含めて変更する予定はありません。（残念ですが）
Kintone側のAPIの進展を待ちたいと思います。また、その他の解決方法として、プログラムをある程度書く覚悟であれば、印刷に必要なデータ項目を揃えた印刷用のアプリを用意して、印刷時にあちこちのアプリからデータを読んでそこにセットしてやって、ReportsConnectにはその印刷用のアプリを読ませてやるという手はあると思います。ReportsConnect側のAPIで読み込む対象のアプリは自由に選択できるので。
（Salesforce側でそういう方法で対処しているという例を聞いた事があります）kintoneは込み入ったことをしようとすると逆に難しい、あるいはできないこともありますが、サービスをシンプルに保つというコンセプトもあるように思うので、今後APIレベルでも良いのでアプリ（テーブル）間連携を強化していただきたいものですね。
ReportsConnectの「標準のAPIの文法の範囲で、１回のクエリー文で読めるものをデータソースとするという方針」についても了解致しました。
また、印刷に特化したアプリを作るというのもなかなか斬新なアイデアですね。
諸々検討して、最適解を考えてみたいと思います。最初の話に戻ってしまいますが、なぜkintoneのテーブルではなく別アプリ（別テーブル）にしたいかというと、テーブルだと入力するところまでは非常に直感的でよろしいのですが、複数レコードにまたがるテーブルデータの集計や抽出ができないように思われるためです。（自前で作ればできる？）
かと言って、子レコード達の集計・抽出をやりたいが為に別アプリで子レコードを入力させようとすると、テーブルのような直感的な入力方法にはなりません。
あちらが立てばこちらが立たず状態ではありますが、要件を整理して、別アプリにしなければならないのか、あるいはテーブルで十分なのかを見極めた上で、帳票印刷のことも考えてみたいと思います。ありがとうございました。
いつもお世話になっております。株式会社アイティーフィットの高倉です。
すみません。他の方の話題なのですが、kintoneの機能拡張がなされていますので、
最近の状況をお教え頂けますでしょうか？
宜しくお願い致します。高倉さん、こんにちは。
kintoneの機能拡張で具体的に、応用できそうな例がありましたら、教えていただければ、検討してみたいと思いますが、いかがでしょうか。
で、答えたのですが、JSONICというライブラリをサーバーに追加して、パラメータをJSONでサブリポートに渡せるようにするというアイデアがあります。
これは近日中に可能になると思います。他には、複数のPDFファイルを1回のオペレーションで作成可能なオプション（有料オプションの予定）を現在開発中です。
でき次第公開する予定です。
- このトピックに返信するにはログインが必要です。