改行ぐらいでしか編集のやり方がまだわかってなくて見づらいと思いますが、よろしくお願いいたします。
不明な点は以下のリンクからご確認お願いいたします。
タイマーを使用する。
1概要
1.1非同期、定期処理の実行（例：メール送信、バッチ、デプロイ後の初期構成）。
※非同期。
・ある処理を開始した後、その処理が完了するのを待たずに次の処理へと進む実行方式。
・処理はバックグラウンドで独立して進行。
・完了した時点で結果を通知したり、別途処理を実施。
1.2実行タイミング
・事前に設定されたスケジュールに従って独立して実行。
・例えば、ユーザーがブラウザで画面を操作している最中でも、タイマーは設定された時刻に自動で動き出す。
2仕組み（ODCの動作概要）
2.1コンテナインフラとそのジョブスケジューラ（cronジョブ）を使用したタイマーが実装されている。
2.1.1コンテナリース。
・ODCでタイマー機能を実行するために作成される専用の仮想リソースのこと。
・「リソース」とは、情報や機能を入れておく「器」のようなもので、
「タイマーの設計図と実行記録」を兼ねた存在で、タイマーが正しく動くための頭脳と記憶装置。
・このコンテナには、タイマーのスケジュールやタイプ（スケジュール型／オンデマンド型）、開始日などの情報が保存される。
2.1.2タイマーのトリーガ。
・スケジュール型のタイマーは、このコンテナインフラのcronジョブによって自動的にトリガーされる。
2.2初回パブリッシュ時に、ODCによってバックグラウンドジョブと各タイマー用のコンテナリソースが作成される。
コンテナリースによって状態が保存され、バックグラウンドジョブのトリガーがこうせいされる。
2.2.1コンテナに保存される情報。
・タイマーのスケジュール。
・タイマーのタイプ（スケジュールorオンデマンド）。
・開始日。
・その他の制御プロパティのステータス。
2.3タイマーマネージャーのコンテナサービス（タイマーマネージャーサービス）。
2.3.1「タイマーのタイプ」とその「スケジュール（オンデマンドまたはスケジュール）」を指定するタイマーリソースの作成を検出する。
※オンデマンドまたはスケジュール。
・実行トリガー（いつ実行されるか）の種類。
・On-demand。
‐必要に応じて、明示的に手動または他のロジックからトリガーされて実行されるタイマー。
‐手動トリガー。特定のイベントの発生時、ユーザーが指示した時など、不規則なタイミングで実行される。
・Scheduled。
‐事前に定義された日時や間隔で自動的に実行されるタイマー。
‐自動トリガー。アプリケーションやシステムが自動的に指定されたスケジュールに基づいてタイマーを起動。
※検出の目的。
・どのタイマーを、いつ、どのように実行すべきかを正確に把握
・把握済みのタイマーマネジャーサービスを適切なアクション（実行）に移るため。
2.3.2ジョブコンテナを起動し、タイマーで指定されたアプリのビジネスロジックをリモートで呼び出す。
※「リモートで呼び出す」とは。
・重い処理は分離されたジョブコンテナに任せるためで、直接的にアプリのビジネスロジックを実行するわけではないことを意味。
【手順】
‐タイマーマネージャーサービスが、新しいジョブコンテナを立ち上げるよう基盤のコンテナインフラに指示。
‐この新しく立ち上がったジョブコンテナの中に、
実際にタイマーで定義されたOutSystemsのビジネスロジックを実行するための環境が含まれている。
‐タイマーマネージャーサービスは、この別々の場所にあるジョブコンテナに対して、
ネットワークを通じて「このロジックを実行してくれ」と指示（リモート呼び出し）。
2.3.3ライフサイクルに沿って、タイマーリソースのステータスや制御プロパティの更新も実行。
2.4別々のタイマーを同時に実行することができるが、各タイマーのインスタンスは
タイマーマネージャーサービスによって、一度に1つのみ実行できるようになっている。
これにより、デッドロックなどの同時実行の問題を防ぐことができる。
※インスタンス
・特定のタイマーの「一回の実行」または「実行中のプロセスそのもの」
・例えば、「在庫更新タイマー」という名前のタイマーを作成したとする。
この「在庫更新タイマー」は、毎日午前3時に実行されるように設定されている。
午前3時になった瞬間に、タイマーマネージャーサービスによって「在庫更新タイマー」の処理が開始される。
この開始された「在庫更新タイマー」のプロセス自体が、そのタイマーの「1つのインスタンス」
※一度に１つのみ実行できるようになっている。
・特定の1つのタイマー（例：「在庫更新タイマー」）について、
同時に複数の「実行中のインスタンス」が存在しないように制御されているという意味
‐例えば、「在庫更新タイマー」が午前3時に実行を開始し、まだ処理が完了していないとする。
‐このとき、もし何らかの理由で
（例えば、処理が長引きすぎて次の実行スケジュール時刻が来てしまった、または手動で「Runnow」が押されたなど）
同じ「在庫更新タイマー」が再度トリガーされそうになっても、タイマーマネージャーサービスがそれを検出し、
2つ目のインスタンスの実行は許可しない、または実行待ちの状態にするということ。
※なぜこのような制御が必要か
①デッドロック
‐複数のインスタンスが同じデータベースのレコードやリソースにアクセスしようとし、
お互いの処理完了を待ってしまい、どのインスタンスも先に進めなくなる状態
②データの不整合
‐インスタンスAがデータを読み込み、更新しようとしている最中に、
インスタンスBも同じデータを読み込み、異なる更新を加えてしまう。
結果として、データが期待しない状態になる。
‐例えば、インスタンスAが在庫を１０個減らす処理をはじめ、
インスタンスBも同時に２０個減らす処理を始めると、
最終的な材工数が正しく-10個や-20個にならず鵜あがきされたり矛盾した状態になる。
2.5「コンテナインフラ」は、スケジュールタイプが「スケジュール」のバックグラウンドジョブをトリガー
「タイマーマネージャーサービス」は、スケジュールタイプが「オンデマンド」のジョブをトリガー
2.6ODCPortalでRunnowを使用すると、オンデマンドのタイマーを非同期的に起動できる。
これによって作成されたイベントを使用して、タイマーマネージャーがタイマージョブを開始する。
3TimeOutと再試行
3.1既定タイムアウト
・20分で、Timerの「TimeoutinMinutes」で変更可能。
・上限はODCプラットフォームの制限によって定義。
3.2タイムアウト時
・アクション中止＋エラーログ記録→自動再試行最大3回（回数は変更不可）
・タイマーの再試行回数は変更できない。
3.3タイマーの再試行のたびにタイムアウトの時間がリセットされるため、
タイマーの実行時間の合計が元のタイムアウトを超えることがある。
最悪の場合、タイマーは、最初の試行と3回の再試行を含めて定義されたタイムアウトの最大4倍まで実行される可能性があります。
※タイマー
・設定されたタイムアウト時間を監視
※タイムアウト時間
・特定のタスクやプロセスが完了するまでに許容される最大時間
3.4タイマーロジック内のクエリの場合は、「ServerRequestTimeout」プロパティに最大値が設定されている。