Grow with AppMaster Grow with AppMaster.
Become our partner arrow ico

AppMasterでタスクスケジューラーを使う

AppMasterでタスクスケジューラーを使う

AppMasterアプリケーションのバックエンドにあるTask Schedulerは、バックエンドの古典的なケースと同様に、繰り返しのシナリオを作成します。例えば、スケジュールに沿って特定のアクションを実行する必要がある場合です。このようなタスクの古典的な例としては、サーバ上の一時ファイルのクリーンアップ、週次バックアップ、与えられたアルゴリズムに従ったレポート生成などの例が挙げられる。

AppMasterアプリケーションバックエンドでタスクスケジューラを使用する例を考えてみよう。毎朝9:00にユーザーの携帯電話番号に天気を送信するプロセスを構築したいとする。

このように、タスクはいくつかの論理的なステージに分けられる。

  • モバイルメッセージを送信するためのモジュールのインストールと設定
  • 外部リクエストAPIプロセスの作成と設定
  • アプリケーションのバックエンドにスケジューラをセットアップすること

1.Nexmoモジュールを使用すると、選択した番号にSMSメッセージを送信する機能をAppMasterアプリケーションに統合することができます。

Nexmo module

  • API Key- Nexmoアカウント(https://dashboard.nexmo.com/settings)で取得できるAPIキーです。
  • APIシークレット- APIキーと一緒に使用され、ユーザーを識別するためのプライベートキーです。Nexmoアカウント(https://dashboard.nexmo.com/settings)でも取得できます。
  • From番号- Nexmoアカウントで登録時に指定した番号。

以下のビジネスプロセスは、モジュールのインストールと同時に自動的にインストールされます。

  • Nexmo.Send SMS- Nexmoモジュールを通して指定された番号にメッセージを送信することができます。

Nexmo.SMS-指定された番号にNexmoモジュールを通してメッセージを送ることができます。

  • 電話番号 [電話] - メッセージの送信先となる電話番号。
  • 内容[文字列] - テキストメッセージ。

Nexmo Send SMS

2.気象データソースとして、無料のOpenWeather APIウェブリソースを使用します(https://openweathermap.org/api)。最初のステップは、外部リクエストAPIテンプレートを作成することです。APIリクエストテンプレートは、「外部APIリクエスト」タブの「ビジネスプロセス」セクションに表示されます。新しいテンプレートを作成するには、「Create API request」をクリックします。

Create API request AppMaster

リクエストの種類GET

リクエストアドレス: https://api.openweathermap.org/data/2.5/weather

クエリパラム

  • Lat [文字列] - 緯度
  • Lon [string] - 経度
  • Appid [string] - OpenWeather API キー

このタスクの一部として、我々はメイン(https://openweathermap.org/api/one-call-3)のレスポンスボディのいくつかのフィールドにのみ興味があります。

  • Temp [float] - 温度
  • Temp_min [float] - 最低気温
  • Temp_max [float]・・・最高温度
  • Pressure [float](圧力) - 圧力
  • 湿度 [float](フロート)- 湿度

Request GET AppMaster

3.タスクスケジューラーを設定する前に、API経由で気象情報を受信するビジネスプロセスを作成する必要があります。ビジネスプロセスは以下のようになります。

Business Process no-code AppMaster

  • Make Weather Query Model In - 仮想のリクエスト・パラメーター・モデルを作成します。Lon, lat - 希望する場所の座標、appid - OpenWeather サービスの API キー。
  • API リクエスト。Weather - OpenWeather API との対話を担当するビジネスプロセス。
  • Weatherを展開する。Body Model Out - Body レスポンスモデルをデプロイするために必要です。

Business Process AppMaster

  • Weather を展開する。Body Model Out_main - 温度 (temp) を取得するために、リクエスト・レスポンス Body のメインモデルを展開する。
  • To String - tempフィールドの値を文字列型に変換します。
  • Nexmo:SMS送信 - 指定された電話番号(Phone)に温度(Content)に関する情報を含むメッセージを送信します。

スケジューラタブのビジネスプロセスセクションでスケジューラを設定します。

Scheduleタブのスケジューラ設定は、その種類によって異なります。

それぞれについて詳しく考えてみましょう

1.毎日 - 毎日のスケジュールを設定できます。

Scheduler settings AppMaster

  • 時間 - スケジューラーが選択したBPを開始する時間をUTC+0で定義します。
  • 曜日 - スケジューラが動作する曜日を定義します。
  • Automatically start - Trueに設定すると、前のBPが完了していない場合、新しいBPは開始されない。デフォルト値。False
  • 自動的に再試行 - 処理が中断された/正常に開始されなかった場合、自動的に再試行します。

Retry failed items processing - プロセスの再試行を何回行うか。

Wait before each retry attempt - プロセスの再起動を試みるまでの遅延時間です。

  • 強制終了 - 数秒以内に処理が完了しない場合、強制的に終了させます。デフォルトではTrue。完了までの秒数は、デフォルトでは3秒です。

2.Monthly - 毎月のプランナー

scheduler monthly planner

  • Time - スケジューラーが選択したBPを開始する時刻をUTC+0で定義する。
  • 曜日 - 2つの設定で構成されます。

繰り返しの頻度。

  • 一回ごと
  • 2回目以降
  • 3回ごと
  • 4回ごと
  • この日

Day of the week - 曜日を指定します。

  • 月 - 月が決定されます
  • Auto Start - Trueに設定すると、すぐに完了しない限り、新しいPSUは開始されません。デフォルトの値です。Falseに設定されています。
  • 自動再試行 - 処理が中断された/開始されなかった場合、自動的に再試行します。

Retry processing failed items - プロセスを再試行する回数です。

Wait before each retry - プロセスの再起動を試みる前に、それぞれ遅延時間を設定します。

  • Force Quit - 数秒以内に完了しない場合、プロセスを終了させます。デフォルトではTrue。完了までの秒数は、デフォルトでは3秒です。

3.Periodically - スケジューラの実行頻度を柔軟に設定できます。

scheduler periodically no code

  • Every - N秒/分/時間/日ごとに繰り返しを設定する機能です。デフォルト:1時間ごと
  • Automatically start - Trueに設定すると、前のBPが終了していない場合、新しいBPは開始されません。デフォルトの値です。False
  • 自動的に再試行 - 処理が中断された場合/正常に開始されなかった場合に、自動的に処理を再開します。

Retry failed items processing - 処理を再開するための試行回数です。

Wait before each retry attempt - 再試行するまでの時間を指定します。

  • 強制終了 - 数秒以内に完了しない場合、プロセスを強制的に終了します。デフォルトではTrue。完了までの秒数は、デフォルトでは3秒です。

4.4. アプリ起動後 - シングルタイムタスクプランナー

scheduler after Starting App

  • Delay - アプリケーション起動後の遅延時間を定義します。デフォルト - 0秒
  • 自動的に再試行 - 処理が中断された場合/正常に開始されなかった場合に自動的に再試行します。

Retry failed items processing - プロセスの再試行を何回行うかを指定します。

Wait before each retry attempt - プロセスの再起動を試みる前に、それぞれ遅延時間を設定します。

  • 強制終了 - 数秒以内に完了しない場合、プロセスを強制的に終了します。デフォルトではTrue。完了までの秒数は、デフォルトでは3秒です。

5.Before finishing the app - アプリケーションが終了するたびにスケジューラを実行します。

scheduler no code

  • 6.自動的に再試行する - 処理が中断された/正常に開始されなかった場合に自動的に再試行する

失敗した項目の処理を再試行する - 処理を再開する試行回数を指定します。

Wait before each retry attempt - プロセスの再起動を試行するまでの時間を指定します。

  • 強制終了 - 数秒以内に完了しない場合、プロセスを強制的に終了させます。デフォルトではTrue。完了までの秒数は、デフォルトでは3秒です。

スケジューラ設定の「Params」タブでは、スケジューラによる起動時にBP入力にパラメータを渡すことも可能です。

Params no-code

この例では、スケジューラの設定は次のようになっています。

  • メッセージは毎日午前9時(UTC+0)に送信される。
  • プロセスがすぐに開始されなかった場合、自動的に3回再起動を試み、その間に10分の遅延を設ける。
  • プロセスが3秒以内に完了しない場合、プロセスを強制的に終了する。

scheduler no-code

私たちのアプリケーションはバックエンドで動作しているので、動作させるためには公開すれば十分です。

関連記事

遠隔医療プラットフォームが診療収益を増大させる方法
遠隔医療プラットフォームが診療収益を増大させる方法
遠隔医療プラットフォームが、患者へのアクセスを強化し、運用コストを削減し、ケアを改善することで、診療収益をどのように高めることができるかをご覧ください。
オンライン教育における LMS の役割: e ラーニングの変革
オンライン教育における LMS の役割: e ラーニングの変革
学習管理システム (LMS) がアクセシビリティ、エンゲージメント、教育効果を高めることでオンライン教育をどのように変革しているかを探ります。
遠隔医療プラットフォームを選択する際に注目すべき主な機能
遠隔医療プラットフォームを選択する際に注目すべき主な機能
セキュリティから統合まで、遠隔医療プラットフォームの重要な機能を確認し、シームレスで効率的な遠隔医療の提供を実現します。
無料で始めましょう
これを自分で試してみませんか?

AppMaster の能力を理解する最善の方法は、自分の目で確かめることです。無料サブスクリプションで数分で独自のアプリケーションを作成

あなたのアイデアを生き生きとさせる