Projects:Store Server Process Requests\Technical Design
Contents |
Introduction
This design discusses the technical changes needed to allow an application admin to maintain process requests running on store servers in a multi-server environment.
The approach followed in this design is to do the maintenance of store-server process requests from the central server backoffice UI. Re-using and extending the current process request window and tabs.
Module
Preferably all the changes should be implemented in the Store Server Synchronization module.
Any changes in core should be validated with the platform team.
DataModel Changes
- A new table should be created, a child table of AD_Process_Request: Mobile Server Process Requests. It has the following columns:
- uuid/client/org/audit info
- process request: foreign key to process request, table-dir, parent column, mandatory, indexed
- mobile server: foreign key to Mobile Servers Table, parent column, indexed, mandatory, table-dir
- status: list-reference - Process Status, mandatory
- last status read was succesfull: yes/no, readonly
- status read timestamp: datetime, last time the status could be retrieved from the store server, readonly
- error information: text field, readonly
- The ad_process_run table should be extended with an indexed tabledir column pointing to mobile servers (parent column)
- A new view should be implemented ad_process_execution_store_v, a copy of the ad_process_execution_v only adding the new indexed tabledir column.
- OBMOBC_SERVER_DEFINITION table should be extended with a new column iscurrent: yes/no, readonly
- A new column should be added to ad_process_request table: "To be Schedule in" list-reference (Central, Store, All)
Window-Tab-Actions
The main additions are in the process request window:
New Subtabs in Process Request
This window should have two new subtabs:
- Mobile Server Process Requests. This tab shows the content of the 'Mobile Server Process Requests' table for the selected parent process request. Some other notes:
- insert/delete and update are supported
- all status-related/exceptions fields are read-only
- Process Request Store Server Monitor, it is the same as the Process Monitor tab, only adding the mobile server column as a filterable column.
The main process request tab should have this button:
- Import All Store Servers
- A new list "To be Schedule in" is created in process request window. Symmetric DS setup should be done for ad_process_request table when this new column is set with value "All" or "Central".
The mobile server process requests tab should have the following buttons (logic is described below):
- Unschedule on Store Server
- Schedule on Store Server
Import All Store Servers
- This button should be enabled only if one process request record is selected.
- This action will show a popup to let the user confirm.
- If the user confirms then the logic should create a new mobile server process request record for the selected process request record and for each mobile server which is a store server and for which there is no mobile server process request record yet.
Unschedule on Store Server
- This action is enabled if one or more mobile server process request records are selected. The selection is irrespective of the status of the mobile server process request record.
- It should ask for confirmation.
- If the user confirms then for each selected record a web-service call is done to the store server to unscheduled the process request. If the process request is already unscheduled on the store server then the request on that store server is ignored.
- The webservice request returns the new status of the store server process request. The logic should update this new status in the mobile server process request.
- Also the last-status-read-was-successfull field should be set to yes and the status read timestamp should be updated, the exception information column in the mobile server process request should be cleared.
- If the webservice fails for some reason then last-status-read-was-successfull should be set to no and the returned exception information should be placed in the exception information column.
- It would be nice to show a summary result in the popup window: Unscheduled xxx processes, xxx webservice calls have failied
Schedule on Store Server
- This action is enabled if one or more mobile server process request records are selected. The selection is irrespective of the status of the mobile server process request record.
- It should ask for confirmation.
- If the user confirms then for each selected record a web-service call is done to the store server to schedule the process request. If the process request is already scheduled on the store server then the request on that store server is ignored.
- The webservice request returns the new status of the store server process request. The logic should update this new status in the mobile server process request.
- Also the last-status-read-was-successfull field should be set to yes and the status read timestamp should be updated, the exception information column in the mobile server process request should be cleared.
- If the webservice fails for some reason then last-status-read-was-successfull should be set to no and the returned exception information should be placed in the exception information column.
- It would be nice to show a summary result in the popup window: Unscheduled xxx processes, xxx webservice calls have failied
New Read-Only window, Process Requests by Server
- A new window should be created: Process Requests by Server
- It is a read only view only to view process requests by a server
- The columns it should show are from the mobile-process-request table, all columns should be shown read-only
Process Request: Update Store Server Process Request Status
A new process request should be implemented:
- name: Update Store Server Process Request Status
- it runs on the central server
- it calls a webservice to each store server with records in mobile-server-process-requests
- each store server replies with a json with the process requests on its server which are defined there and their statuses
- update the mobile server process request record for the mobile server and process request. Ignore the ones for which the mobile server process request record does not exist for the mobile server and process request.
AD_Process_Run
- This design adds a new column to the ad_process_run table: mobile server. This column should be set when a new record ad_process_run record is created. The idea is that this can be done using a database trigger to set the mobile server id in the ad_process_run record.
- A new column should be add to OBMOBC_SERVER_DEFINITION table: iscurrent. This columns should be set by a Listener to know which is the current mobile server to set this id in the trigger.
- Symmetric DS setup should be done such that it replicates the ad_process_run table from the store server to central server.
Web Services
To call a web service on a store server there is an api which can be used.
(Un)Schedule Webservice
This webservice will handle both schedule and unschedule requests. The json it receives should contain the following information:
- ad_process_request id, command (schedule or unschedule)
The webservice should call the quartz scheduler (you can check how the current un-schedule re-schedule works) to perform the action.
The response should be a json with the new status of the process request on that server.
Retrieve Status Webservice
The retrieve status webservice calls the store server to retrieve the current status of the process requests running on the store server. To limit the number of webservice calls it should return the status of all the process requests in one json object. So only one webservice call per store server is needed.