Job Runnerを使うと、アプリの全レコードに対し、フィールドに値をセットするカスタマイズを実現できます。

この記事では具体的な例として、全レコード一括で検索用文字列を作成し、セットするカスタマイズについてお伝えします。

はじめに

・レコード内のフィールドの値によって個別に処理を行いたい

・レコード内のテーブルを扱いたい

・レコード内の関連レコード一覧に表示されたレコードの集計を行いたい

といった様に、取得したレコードに対して1レコードずつ個別の処理を行いたい場合は、条件「レコード１行が準備できた時」を使用します。

次の例は、「顧客マスタ」アプリの「顧客名」フィールドの値をもとに、全レコード一括で検索用文字列を作成し、「顧客名検索用」フィールドにセットするカスタマイズです。

今回のカスタマイズで用いるアプリ

注：この記事で用いるアプリは、カスタマインの歩き方　カスタマイズお試し用ファイルダウンロード の Job Runner 編にアプリテンプレート、サンプルデータがありますので、そちらをご利用頂く事もできます。

手でアプリを作成したい場合は次に記載するようにアプリを作成してください。

『顧客マスタ』アプリに下記のようなレコードが登録されている場合を例にとります。

今回のカスタマイズを実行するために必要な、kintone アプリの API トークン の権限は次のようになります。

※「レコード閲覧」、「レコード編集」権限を設定

アプリの設定

アプリは次のように設定してください。

※フィールド名とフィールドコードは同じものを指定します

カスタマイズ

接続設定を行う

まず、kintoneへの接続設定を行います。

やること「kintone 接続設定を行う」、条件「実行予定時刻になった時」を用います。

全レコードを取得する

次に、顧客マスタアプリの全レコードを取得します。

やること「全レコードを取得する」を用い、顧客マスタアプリの全レコードを取得します。

1レコード毎に検索用文字列を作成し、セットする

1レコードが準備できる毎に、検索用文字列を作成し、セットまで行います。

ここでは、やること「検索用文字列を作成する」、条件「レコード１行が準備できた時」を用います。

なお、条件「レコード１行が準備できた時」は、パラメーター「レコード取得アクション」に指定したアクション（やること「全レコードを取得する」などの、レコードを取得するやることが指定されたアクション番号を指定します）で取得したレコードの中から、1レコードが準備できる度に発生します。

　そのため、アクション 3のやること「検索用文字列を作成する」 は、レコードの数だけ実行されることになり、なおかつ常に 1レコードだけを扱う事ができます。

この時、他のレコードの事は見えない動きとなるため、条件「レコード１行が準備できた時」は集計や絞り込みには使えません。

その代わり、条件「レコード１行が準備できた時」は取得した1レコードを1つずつ扱う事ができ、レコードごとの処理を行えます。

今回は、取得したレコード内のフィールドの値を元に、検索用文字列を作成し、フィールドにセットしました。ジョブを実行すると、次のような結果が得られます。

条件「レコード1行が準備できた時」を使用した実例は、次の記事を参考にしてください。

Job Runnerで1レコード・全レコードの処理を組み合わせ、月毎の集計を実現する

コラム : どちらの条件でも処理が可能なやること

やることによっては条件「レコード１行が準備できた時」でも条件「レコード全行が準備できた時」でもどちらを使っても処理が可能なものも存在します。その場合、特に全行をまとめて処理したい理由がなければ条件「レコード１行が準備できた時」を使用する方がおすすめです。

　理由は、レコードを取得するアクションで取得したレコードの数が多い場合に、条件「レコード全行が準備できた時」の方が比較的メモリエラーが発生しやすいためです。メモリエラーは、Job Runner のシステム上のメモリに収まりきらないほどの大量のレコードを処理しようとした際に起きるエラーで、下記のようなメッセージが表示されます。

ジョブは強制終了しました。メモリを使い切った可能性があります。The job has crashed. Probably out of memory.

条件「レコード全行が準備できた時」 は、取得したすべてのレコードをまとめて扱うため、このメモリエラーが起きやすいのです。

条件「レコード１行が準備できた時」は、1行準備できたら処理、1行準備できたら処理……というように、全てのレコードが取得されるのを待たずに、準備できたレコードから1レコードずつ取得され、処理が実行されます。そのため、メモリに大量のレコードが存在する状況になりにくく、比較的メモリエラーが起きづらくなります。

　※あくまで比較的メモリエラーになりにくいだけで、ならないわけではありません。

参考までに、条件「レコード１行が準備できた時」でも条件「レコード全行が準備できた時」でもどちらを使っても処理可能である代表的なやることとしては、やること「年齢を計算する」や、今回例でも使用した やること「検索用文字列を作成する」のような、処理結果をセットするフィールドをパラメーターとして持つやることが挙げられます。

おわりに

この記事では具体的な例として、全レコード一括で検索用文字列を作成し、セットするカスタマイズについてお伝えしました。

検索用文字列を一括で作成しセットする動作を、ご確認いただけたかと思います。

レコードの更新は簡単にできる分、思いもよらない大量のレコードを、意図しない内容で更新したりすることもできてしまうものです。

実際にカスタマイズを作成される際には、Job Runnerテスト実行 を使ってテストするか、テストアプリとテストデータでよくテストを行った上で、実際のアプリ・運用に適用していくことをおすすめします。

ご不明な点がございましたら、チャットでお問い合わせください。