...
The OMS dynamic token refresh can be planned as background job with report /K3T/RU_OMS_TOKEN. The OMS Connection ID assignment to the system and MDLP Configuration ID shall be maintained in the transaction /K3T/RU_OMS_C.
4.11 Russia MDLP Analytics
MDLP analytics reports functionality is available, including ability to request following reports: Remaining medicines, Medicine disposal, SSCC Hierarchy, Pricing report.
To receive analytic reporting data from MDLP system the following steps are required:
Schedule report run - create analytic reporting request and task (according to MDLP API requirements) using transactions /K3T/RU_MAS_SCD_* (For example, /K3T/RU_MAR_SCD_MD - Task scheduler Medicine disposal)
Run task processor (program /K3T/RU_MAR_TASK_PROC) to create tasks at MDLP, receive task results and save as ZIP file into database table
Run task execution (program /K3T/RU_MAR_TASK_EXEC) to extract data from ZIP file and save data to database or send data to external database
Monitor task execution (transaction /K3T/RU_MAR_MONITOR)
4.11.1 Russia MDLP Analytics: Configuration transaction /K3T/RU_MAR_CONF
Transaction /K3T/RU_MAR_CONF allows configure processing after data retrieval from MDLP system specific for each report type based on customizing table.
Assign the processing function module for specific report under “Analytic Report”.
Field | Description, Values |
Report Type | MDLP Analytic Report type |
Sequence | Sequence |
Function Module | Execution function module |
Description | Description |
The 3Keys CRPT connector for MDLP provides the list of function modules for processing of analytic reporting data.
Function module | Description |
/K3T/RU_MAR_EXEC_SAVE | Function module parse the result zip file of analytic report and store extracted data in the tables |
/K3T/RU_MAR_EXEC_DB_DISTR | Function module transfer the data stored in the tables to the connected external database (transaction DBCO). The external database tables shall have correct structure (example structure /K3T/S_RU_MR_*_DAT_DB where * - report type specific substring) |
/K3T/RU_MAR_EXEC_STATUS | Function module set processing status. This function module shall be assigned as last in the sequence for the reporting type |
Maintain exclude fields under “Response Exclude fields” to exclude unnecessary data from report.
Field | Description, Values |
Report Type | MDLP Analytic Report type |
Field Name | Field name to be excluded from report result |
Description | Text |
4.11.2 Report /K3T/RU_MAR_TASK_PROC - Russia MDLP Analytics: Task processor
The report /K3T/RU_MAR_TASK_PROC shall be executed periodically as background job for sending requests to the MDLP and downloading results. The multiple background jobs can be planned for each MDLP Configuration ID to execute in parallel. The selection screen fields:
MDLP Configuration ID
Wait Time First Response: Default wait time in seconds between request and results download
Max Wait Time After Crt: maximum processing time after request was registered by MDLP system and response is expected. If no response is received task status will be set to error
Between Status Check (sec): wait time in seconds between task status check
Create new Log after seconds: create new SLG1 log after specified interval from report run to monitor program execution
Maximum runtime program (min): maximum program processing time before stop with error
Max Server Errors: maximum server errors series before stop with error
Queue processing method. Available values:
1 - “FIFO” (default value) means task will be processed in order task have been created
2 - “Create if slot is available” means program will create new task after each successful task result processing when free slot is available at MDLP side (to minimize wait time between task creation)
Retry after FAILED: repeat processing after first FAILED response from MDLP system
Delete unknown MDLP tasks: delete tasks from MDLP system queue (if task from MDLP queue with MDLP id and status “Send to MDLP” is not found):
before first task processing to delete existing entries in queue
after all task processing to delete entries after MDLP side server errors
on receiving server error series
Block “Available tasks operation retry option“
Retry after failure times: how much tries needs to be done after each failure
Delay after failure (sec): the initial delay in seconds after first negative response. Value must be greater than 0
Backoff: the factor by which the delay should be increased after each failure. Value must be greater than 1
Block “MDLP queue operation retry option“
Retry after failure times: how much tries needs to be done after each failure
Delay after failure (sec): the initial delay in seconds after first negative response. Value must be greater than 0
Backoff: the factor by which the delay should be increased after each failure. Value must be greater than 1
Block “Delete operation retry option“
Retry after failure times: how much tries needs to be done after each failure
Delay after failure (sec): the initial delay in seconds after first negative response. Value must be greater than 0
Backoff: the factor by which the delay should be increased after each failure. Value must be greater than 1
Block “Result operation retry option“
Retry after failure times: how much tries needs to be done after each failure
Delay after failure (sec): the initial delay in seconds after first negative response. Value must be greater than 0
Backoff: the factor by which the delay should be increased after each failure. Value must be greater than 1
Block “Create operation retry option“
Retry after failure times: how much tries needs to be done after each failure
Delay after failure (sec): the initial delay in seconds after first negative response. Value must be greater than 0
Backoff: the factor by which the delay should be increased after each failure. Value must be greater than 1
Block “Task response wait options”
Retry after max wait times: Each task created at MDLP system existing without final status (COMPLETED or ERROR) is checked for processing time (task creation time at MDLP + “Max wait time after creation (sec)” is less than time now). In case task processing time is more than “Max wait time after creation (sec)” seconds task processing is stopped by program and task is deleted from MDLP with error “Maximum response time reached. Setting error status”. For each task now new internal max wait time counter implemented to create new task at MDLP instead of stop task processing if counter value is less than “Retry after max wait times”.
Report read tasks ID and process tasks according to MDLP API requirements. In correct scenario task status is changed:
status 00-new to status 10-Sent to MDLP: task created at MDLP successfully
status 10-Sent to MDLP to status 20-Ready (results downloaded from MDLP): task data retrieval is completed and task deleted from MDLP
The task processing results stored as application log transaction SLG1, Object /STTP/, Sub object ANY, External ID /K3T/MR_TASK_PROCESSOR.
4.11.3 Report /K3T/RU_MAR_TASK_EXEC - Russia MDLP Analytics: Task execution
The report /K3T/RU_MAR_TASK_EXEC shall be executed periodically as background job for processing downloaded results. The function module shall be assigned in the transaction /K3T/RU_MAR_CONF.
The selection screen fields:
MDLP Configuration ID
MR Task Internal Identifier: run report for specified task ID
The task execution results stored as application log transaction SLG1, Object /STTP/, Sub object ANY, External ID /K3T/MR_TASK_EXEC.
5. Enhancements of the Solution
...