Recent posts:
Recent replies:
Julian Matthews · Feb 23, 2021
Julian Matthews · Feb 23, 2021
Hey Scott.
I think you can achieve this by setting the second parameter to a comma delimted list of the request names, and then pass each value afterwards (in the same order you have the names).
For example:
Method Sample(pReq As osuwmc.Page.DataStructures.Page, Output pResp As %Net.HttpResponse) As %Status { Set FormItems = "PNo,PMsg" set tSC = ..Adapter.Post(.tResponse,FormItems,pReq.PagerNumber,pReq.Message) if ('tSC) { $$$LOGERROR(tSC) } quit tSC }
Julian Matthews · Feb 18, 2021
Hey Mufsi, I had this happen to me and according to WRC this is a known issue fixed in 2020.1.1.
It is caused by an attempt to get an exclusive lock on a specific node for the mirrored database (which is read only) where the task is being scheduled.
There is an alternative workaround to the steps you took by using the ^TASKMGR interface from the %SYS namespace in a Terminal session as it doesn't try to perform any write operations on the read-only mirror databases.
Followers:
Following:
Julian has not followed anybody yet.
Global Masters badges:
Julian has no Global Masters badges yet.
Hey Scott.
If you were open to having a Service in your production which is what your function sends its two variables (and the service then passes it onto your Operation) you could have something like this:
and then you have a custom service that looks a little like this:
Then when you add the service to your production (remembering to match it to the name declared in the service code), you can select your target operation as a config item, and when the function is triggered it should go Function -->Service-->Operation.
Edit: my Service Class example had an error in the SETTINGS parameter, I have corrected it.