I'm having problems understanding what you are trying to achieve. The "Send workorder" button is something that you click on rare scenarios when the QlikView Distribution Service is not synchronised with the QlikView Management Service, because of communication issues. https://community.qlik.com/t5/QlikView-App-Dev/Workorder/m-p/185953/highlight/true#M50266
Is there any particular reason why you need to run this via a API call? If needed, than can be achieved via this call. (please note, this is for May 2022. Check the Management Service API reference page to verify which IQMS interface is right for your version of QlikView).
If, instead, you mean to run single tasks via the call, you can use this.
Daniele - Principal Technical Support Engineer & SaaS Support Coordinator at Qlik If a post helps to resolve your issue, please accept it as a Solution.
The reason why I need to test this is that we have multiple tasks triggered using EDX API. The script has a 1 min delay communication to know the status of the task, and communicates back with a third party external program: control-m.
Sometimes, the CPU server peaks over 95%, and communication breaks for few seconds (or minutes); which sends the wrong status back to third party program: failed. Since we have critical tasks (and a 24 / 7 support), we must have QMC tasks running without failure, and communicate back to control-m with the actual status.
Furthermore, we have dummy task that runs frequently to test API communication within control-m ~ QMS. When this task fails, it triggers a command to restarts QMS service...
...I have noticed that this approach sometimes helps to reestablish the communication, and sometimes does not. However, when we have forced "Send Work Order", system is able to refresh all queued tasks (sent by API, and also triggered internally in QMC) without restarting service.
As a test solution, we will update the dummy job, so if it fails, it will refresh the work order, and then rerun a second dummy job (second instance). If it fails again, we might conclude there is something else blocking interface within application, and therefore we need to login to investigate further.
I'm having problems understanding what you are trying to achieve. The "Send workorder" button is something that you click on rare scenarios when the QlikView Distribution Service is not synchronised with the QlikView Management Service, because of communication issues. https://community.qlik.com/t5/QlikView-App-Dev/Workorder/m-p/185953/highlight/true#M50266
Is there any particular reason why you need to run this via a API call? If needed, than can be achieved via this call. (please note, this is for May 2022. Check the Management Service API reference page to verify which IQMS interface is right for your version of QlikView).
If, instead, you mean to run single tasks via the call, you can use this.
Daniele - Principal Technical Support Engineer & SaaS Support Coordinator at Qlik If a post helps to resolve your issue, please accept it as a Solution.
The reason why I need to test this is that we have multiple tasks triggered using EDX API. The script has a 1 min delay communication to know the status of the task, and communicates back with a third party external program: control-m.
Sometimes, the CPU server peaks over 95%, and communication breaks for few seconds (or minutes); which sends the wrong status back to third party program: failed. Since we have critical tasks (and a 24 / 7 support), we must have QMC tasks running without failure, and communicate back to control-m with the actual status.
Furthermore, we have dummy task that runs frequently to test API communication within control-m ~ QMS. When this task fails, it triggers a command to restarts QMS service...
...I have noticed that this approach sometimes helps to reestablish the communication, and sometimes does not. However, when we have forced "Send Work Order", system is able to refresh all queued tasks (sent by API, and also triggered internally in QMC) without restarting service.
As a test solution, we will update the dummy job, so if it fails, it will refresh the work order, and then rerun a second dummy job (second instance). If it fails again, we might conclude there is something else blocking interface within application, and therefore we need to login to investigate further.
