ODCで、運用中に変更できるアプリケーションの設定値はSettingに持つ。
OutSystems11で言うと、Site Propertyにあたる（Site Propertyと違いプログラムから変更することはできない）。

Timerの実行を運用者が強制中断できるようにしたいと思い、以下のプログラムを用意して実験してみたら意外な結果になったのでメモ。

SettingにBoolean型の値を用意しておく
TimerからSwitchの値を参照し、ログに出力する

環境情報

ODC Studio(Version 1.5.8)

Timer実行中に変更されたSettingの値は、実行中には古い値しか見えない

動作確認イメージ

Boolean型のSettingを用意（デフォルトFalse）
Timerを2つ用意し、両方でこのSettingの値をLogMessageでODC Portal > Logsに出力
Timer実行中に行ったSettingの変更を確認するため、SettingをLogMessageで出力　→　(System)Sleepで90秒スリープ　→ Settingをもう一度LogMessageで出力というロジックにした
リトライ時の動作を確認するため、必ずタイムアウトが発生するように、TimerのTimeout in Minutesを短く設定する
Timer1を開始した後Settingの値をFalse → Trueに変更（図中の赤い線のタイミング）
Settingの値を変更後、Timer2を開始

確認結果

動作確認イメージの図に示した①〜④のタイミングで出力されたログを確認したところ以下の通り。

	Settingの値	タイミングの説明
①	False	Setting変更前
②	False	Timer実行開始してから、Settingを変更した後
③	False	Timerがタイムアウトにかかってリトライ
④	True	Settingの値を変更後に、（リトライでなく）新たに開始したTimer

以上から、以下の結果となった。1、2共に意外で、不都合のある動作。

Timer実行を開始した時点で、利用するSettingの値は固定され、実行中に変更された後の値は参照できない
リトライした場合でも、最初の実行開始時点のSettingの値を使う
リトライでなく、新たに開始したTimerは変更後の値を参照できる

本当はやりたかったができなくなること

Timerは長時間実行するが、強制的に実行を停止する方法がない。
さらにタイムアウトすると、勝手にリトライを行なってしまう。

そのため、Settingでスイッチを設け、実行を強制停止できるようにロジックを組んでおきたい。
OutSystems11の頃は安全策としてこういう実装を組む手もあった。

Data Actionの実行中に行ったSetting変更も、実行中には見えない

Timer以外の要素の場合はどうかと思って、Data Actionでも試してみた。
Server Request Timeoutを60秒に設定し、LogMessageでSettingの値を記録　→ 40秒Sleep → もう一度LogMessageでSettingの値を記録、と言うロジックを利用。
Sleep中にODC PortalからSettingの値を変更してみたが、2回のLogMessageは共に変更前の値をログに記録した。

つまり、Timerに限らず、ある要素の実行開始後に行われたSetting変更は、その実行中は見えない（古い設定値が見える）と言うことに見える。

これも若干意外な結果ではあるが、長時間実行を想定するTimerと違い、他の要素は次回実行時に変更後の設定値で動作すれば十分なことは多そうに思える。