Notifications
Clear all
Topic starter
We have a ticket open with GE for this, but I figured I should ask here too. It looks like our Quality Measures channel in CQR is cranking out data just as it should. But our Functional Measures channel is nothing but errors. And all the errors look like this:
CustomReceiver error (consecutive errors=1): javax.script.ScriptException: sun.org.mozilla.javascript.internal.WrappedException: Wrapped com.qvera.qie.exception.NoResultsException: Error calling Web Service 'Common Event Model': java.net.SocketTimeoutException: Read timed out (<Unknown Source>#68) in <Unknown Source> at line number 68
at (...snip...)
Caused by: sun.org.mozilla.javascript.internal.WrappedException: Wrapped com.qvera.qie.exception.NoResultsException: Error calling Web Service 'Common Event Model': java.net.SocketTimeoutException: Read timed out (<Unknown Source>#68)
at (...snip)
Caused by: com.qvera.qie.exception.NoResultsException: Error calling Web Service 'Common Event Model': java.net.SocketTimeoutException: Read timed out
at (...snip...)
Our understanding of how QIE works is very limited, and certainly doesn't extend far enough to be able to troubleshoot something like this. Does anyone have a clue what this might indicate?
Posted : January 20, 2015 5:39 am
Hi Ron,
Do you have any contact at GE or QIE specific for the CQR? That is a Qvera error, basically the common event model that is pulled in Qvera is missing some piece of data. We saw this when our password expired in GE and we hadn't updated it in Qvera yet (for the Qvera user). Your other channel is fine though and they both call the common event model so I do not think that is it. Unfortunately you will need some help from Qvera or a technical CQR contact at GE.
Has it ever worked for you? One thing you can do is open up Qvera, go to the CQR zone and look at the two channels. If you click on the green node and then the script configuration and/or channel cache just make sure the common event model is called exactly the same in both places (capitals, spacing etc all matter).
My last tip is you can take one of those error messages (it'll show in the error tab on this same screen) and double click on it to open the message. Once the message is open click the Test button and step through the channel. This will at least help you determine the "step" that it is failing and may help point you to what is wrong.
My Qvera knowledge is not robust but let me know if I can help any more. My email is [email protected] .
Thanks
Mike
Posted : January 20, 2015 7:40 am
Topic starter
Do you have any contact at GE or QIE specific for the CQR?
We have a ticket open, but it sounds like we're going to need to establish a direct relationship with someone specific to CQR for future reference.
Has it ever worked for you?
That's hard to say. It hasn't been running very long, and we've had our share of troubles with it, but honestly I don't have enough training on the interface to be able to say whether or not it has ever worked. I didn't even know there were two channels until this morning. I logged into the interface after GE asked me if the channel was working and said, "oh, there are a bunch of zeroes here, and some errors, that's probably bad." That's pretty much the extent of my knowledge on this system. (We're in the process of trying to get me some training, as the documentation we have is completely opaque to me.)
One thing you can do is open up Qvera, go to the CQR zone and look at the two channels. If you click on the green node and then the script configuration and/or channel cache just make sure the common event model is called exactly the same in both places (capitals, spacing etc all matter).
As far as I can tell, that all appears to be the same between the two, with the exception of the Subscription Name, which I assume should be different.
My last tip is you can take one of those error messages (it’ll show in the error tab on this same screen) and double click on it to open the message. Once the message is open click the Test button and step through the channel. This will at least help you determine the “step” that it is failing and may help point you to what is wrong.
All I get is the error text itself, no message. So I think it's failing before that point, whatever that point is.
Thanks for the guidance; hopefully GE will come up with something very soon.
Posted : January 20, 2015 8:00 am
Hi Ron,
If you don't hear anything from GE let me know and maybe I can lend some form of assistance via webex. At the very least I can look at my channels and your channels and see if I notice anything different. If you think that will be of help let me know otherwise hopefully GE gets back to you quickly!
Thanks,
Mike
Posted : January 20, 2015 8:50 am
Topic starter
Thanks Mike, that's very kind of you. I'll let you know.
Posted : January 21, 2015 6:20 am
Topic starter
I've gotten farther into this, and found the documentation on what to do about my particular error:
Root Cause: Subscription configuration file contains invalid or no finalDate value for subscription processing.
Solution: In the .xml subscription configuration file, set finalDate value to 12/31/2099.
Only problem is, I have no idea how to set that. I know where the script configuration is (at least I think I do, in the QIE) but I don't see any reference to finalDate, either in the channel that isn't working or the one that is. If someone can point me to that, I could be pretty close to resolving this.
Posted : January 22, 2015 2:52 am
Topic starter
Reading further on page 14 of the "Monitoring Meaningful Use Data Flow" document:
Functional Measures subscription: There is no way to resubmit a failed Functional Measure output using the Inquiries module. To resubmit, delete the subscription, then recreate the subscription with a start date that covers the failed event, and run the subscription.
There's no way we feel comfortable doing this ourselves, given the available documentation. So we'll have to get GE involved one way or another. If only I could get them to call me back.
Posted : January 22, 2015 6:05 am
Hi Ron,
I think that is the actual subscription file itself. When you loaded your subscriptions into the interop area of the EMR settings (under the config folder) did you save that file off? If you have it you could at least look at the script and see if that field is missing. From seeing your posts here I imagine you'll understand the language it uses (looks like sql to me but I am a tech novice). It would be the file called mu_reporting_standard_subscriptions_version(#).xml (mine is version 4). I know I had to edit this with a GE person once a few months ago to extend the data-pull window to speed up the initial load. We hadn't configured it in Live at that time yet but they did say I would have had to delete and reload it if it had been.
Unfortunately it sounds like you need GE to give better insight. We are seeing a different type of error in Qvera that they are investigating for us - I will post more information if/when I hear back and maybe it will lend some help to you. At the very least it will be good if anyone else experiences my error in the future.
On a side note the CQR technical guides (or lack there of) is getting beyond frustrating; the release notes from this weekends update are not even available! Release notes should be before an update, in my humble opinion...
Thanks,
Mike
Posted : January 26, 2015 7:29 am
