Details
-
Story
-
Status: Closed (View Workflow)
-
P3
-
Resolution: Done
-
None
-
-
CP: sprint 110, CP: sprint 111
-
5
-
Core: Platform
Description
Currently, the only way to "disable" an Okapi timer task or to change its run interval is to POST a modified module descriptor for the affected module with an updated _timer interface, POST a deployment descriptor to route the requests to the right module instance, and enable the modified module for the tenant (with ?invoke=false to avoid calling the _tenant interface). This is a little bit error-prone, and makes upgrades tricky, as well. It would be very convenient to have an API for managing tasks that are registered via the Okapi _timer system interface.
The API would probably need to define a new descriptor (a "timer descriptor"), and might be defined thus:
GET /_/proxy/tenants/{tenantId}/timers: get a list of all registered timer descriptors for the tenant
GET /_/proxy/tenants/{tenantId}/timers/{id}: get a registered timer descriptor
PUT /_/proxy/tenants/{tenantId}/timers/{id}: put an updated timer descriptor
One of the fields in the timer descriptor might be something like status with an enum of ["enabled","disabled"] to allow for temporarily disabling a timer.
I leave it up for discussion if the API should allow POST and DELETE. Also up for discussion is what should happen on module upgrade.
TestRail: Results
Attachments
Issue Links
- relates to
-
CIRC-1057 SPIKE: Aged to lost process needs to be able to be scheduled by the institution
-
- Closed
-
-
OKAPI-1009 Spurious ProxyTest.testTimer failure
-
- Closed
-
-
UXPROD-594 Scheduler
-
- Closed
-
-
CIRC-1144 Change age to lost processes back to Okapi timer
-
- Closed
-
-
OKAPI-1000 schedule facility (ala cron)
-
- Closed
-
-
OKAPI-1005 Timer management (remove timer entries for disabled modules)
-
- Closed
-