カスタム関数とAPIの使用方法の最適化に関するガイドライン

カスタム関数とAPIの使用方法の最適化に関するガイドライン

 アプリケーションにおける処理の実行速度や処理負荷は、コードの書き方によって大きく変わります。Zoho Deskには、カスタマイズや他サービスとの連携に役立つカスタム関数やAPIの機能が用意されていますが、これらを使用するためのコードを書く際には、以下の点を参考にすることでコードの内容や処理をより効率的にできます。  

カスタム関数内のコードの最適化

カスタム関数内のコードにおいて何らかのデータを取得して実行する処理が記述されている場合、データが重複して取得されるようなコードになっていないかどうかを確認することが重要です。また、何らかの値を参照する場合、該当の値が適切に取得されているかどうかを確認することも有効です。そうすることで、コードの内容を適切に実行し、エラーを回避することが可能です。具体的なポイントは以下のとおりです。

項目の値が空(null)でないかどうかを確認する

カスタム関数やAPIを通じて何らかのデータ項目の値を取得する場合、値が空(null)になっていないかどうかを確認しましょう。該当の項目に関する処理を行う場合、値が適切に入っているかどうかを確認しておくことで、以降の処理においてエラーを発生させずに実行を完了させることができます。
たとえば、Zoho Deskのカスタム項目の値を取得して使用する場合、該当のカスタム項目に値が入っているかどうかを確認することで、以降の処理を適切に進めることが可能です。なお、Zoho Deskのカスタム項目を取得する際には、「cf_category」から始まるラベルを使用します。以下が具体例で、1つ目の画像は不十分なコード、2つ目の画像は適切なコードの例です。



取得しようとしている値が同じコード内で取得済みでないかどうかを確認する

 カスタム関数やAPIを通じて何らかのデータ項目の値を取得する場合、その前までの処理において値をすでに取得できている可能性がないかどうかを確認しましょう。 
たとえば、Zoho Deskの問い合わせの一覧を取得するためのAPI(ticketList)を実行するとします。また、各問い合わせのデータを参照して、データID(パラメーター名:ticketId )を取得するとします。その後の処理で、データIDとは別に問い合わせ番号を使用したい場合、あらためてAPIを実行するのではなく、取得済みのデータの中から問い合わせ番号の項目(パラメーター名:ticketNumber)を参照することで、APIを再実行しなくても必要な値を取得できます。以下の画像は、不十分なコードと適切なコードの例です。


APIを実行する際に1回の実行で必要な値をすべて取得しておくようにする

ある処理の中で、問い合わせの担当者のID(パラメーター名:assigneeId)と担当者の姓(パラメーター名:lastName)を参照したいとします。通常、問い合わせの詳細を取得するためのAPIでは担当者のIDしか取得できないため、そのIDをもとに担当者の詳細を取得するためのAPIを別途実行し、姓の情報を取得する必要があります。ここで、最初のAPIを実行する際に、「include」というパラメーターを追加することで、担当者の詳細情報もあわせて取得しておくことが可能です。これにより、問い合わせの詳細と担当者の詳細を別々に取得してAPIを2回実行する必要がなくなり、1回実行するだけで必要な情報をまとめて取得できます。APIにおける「include」パラメーターの詳細はこちら


値を更新しようとする際にすでにその値になっていないかどうかを確認する

何らかの項目の値を更新しようとする際に、場合によってはすでにその値になっていて、同じ値に更新してしまうことがあります。更新処理をする前に値の内容を検証することで、不要な処理を避けることができます。
たとえば、条件に当てはまった問い合わせのステータスを「完了」に変更しようとしたいとします。この時、対象の問い合わせのステータスがすでに「完了」になっていないことを検証することで、その場合は処理をスキップできます。

問い合わせへの返信としてのメール送信の処理には返信用の関数を使用する

メール送信の上限は1日あたり2,500通ですが、この上限が適用されるかどうかは使用する関数によって異なります。カスタム関数でメールを送信するために、通常のメール送信用の関数(sendmail)を使用した場合、該当のメールは問い合わせの一連のやりとり(スレッド)には追加されません。また、上限の対象数にも算入されます。一方、返信用の関数(sendReply)を使用した場合、該当のメールは問い合わせの一連のやりとり(スレッド)に追加されます。また、上限の対象数には算入されません(制限なく送信できます)。以下は、メール送信用の関数(sendmail)と返信用の関数(sendReply)を使用した場合の関数の例です。



不必要な自動処理は実行しないようにする

特定の項目の値の追加や更新をきっかけとして処理を自動的に実行するようにワークフローを設定している場合があります。このような場合に該当の項目の値を追加/更新すると、設定された処理が自動的に実行されますが、運用としてはこの処理を実行する必要がない場合もあります。このような場合、自動処理の実行有無を制御するためのパラメーター(featureFlag)を用いることで、不要な処理を回避できます。

項目値が必要な場合にAPIを通じてではなく関数への入力値(引数)として取得する

何らかの項目の値が必要になった場合に、APIを実行して該当の項目の値を取得することもできますが、関数への入力値(引数)として設定して取得することも可能です。これにより、APIの実行回数を減らすことができます。
たとえば、カスタム関数を通じて問い合わせの項目値を取得して処理を行うとします。この時、関数内にコードを記述し、対象の問い合わせのデータIDをもとにAPIを実行して各項目の値を取得することもできますが、その代わりに関数への入力値(引数)として必要な項目の値を設定し、そこから値を直接参照することが可能です。


APIの実行方法の最適化

 複数のデータに対する処理を行う場合、そのためのAPIをデータごとに実行するのではなく、1回だけ実行してまとめて処理すると効率的です。

複数の問い合わせデータを更新する際に専用のAPI(updateMany)を使用する

複数の問い合わせデータを更新する処理については、専用のAPI(updateMany)が用意されています。このAPIを使用すると、更新用のAPIをデータごとに毎回実行する必要がなくなります。コードも見やすくなり、よりスピーディに処理を完了できます。
たとえば、10件の問い合わせのデータを更新したいとします。この時、通常の更新用APIを使用すると、APIを10回実行する必要がありますが、複数データの更新用API(updateMany)を使用すると、1回のみの実行で済みます。
        
                      

1回のAPIで複数の項目値をまとめて更新する

データ更新用のAPIでは、1件の項目のみではなく、複数の項目の値をまとめて更新することが可能です。 
たとえば、ある問い合わせのステータスと担当者を変更したいとします。この時、ステータスの更新と担当者の更新でそれぞれ(計2回)APIを実行するのではなく、1回のAPIで両方の項目を更新できます。
     
      

                 

最新のやりとり(スレッド)を取得したい場合に専用のAPI(latestThread)を使用する

問い合わせに関する顧客とのやりとり(スレッド)において、最新の内容を取得したい場合には、専用のAPI(latestThread)が用意されています。やりとり全体を取得してその中から最新の内容を抽出しなくても、必要なデータを直接的に取得できます。