Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
eServer System Monitor function
Does anyone have any experience with installing RDKs via the eServer System Monitor process, specifically Dictionary entries?
A bit of background, we have written a System Monitor procedure that runs with the eServer service every x minutes.
In our code there is 'manual schedule' (basically it only runs secific code during the certain windows we want those code segements to run).
One of the things it does is download an RDK file and processes it (basically a Live Update scenario).
This process works and is verifiable.
HOWEVER, it only works when the RDK doesn't contain dictionary entries!
As long as it is just procedures, forms, inserts, records, etc the process finishes quite happily.
I can have a deploy that contains just a single dictionary item and nothing else and the process still 'hangs'.
(The table that field is trying to deploy to 100% exists on the destination.)
I have traced through the code and basically it does this:
And this is where it hangs. It never passes RdkModuleInstall for a DICT entry.
I have a SYSOBJ $RdkModuleInstall entry but I can't step through that to debug any more (I dont think...)
(I have been reading https://blog.srpcs.com/pulling-the-rug-from-beneath-your-feet/ to see if that applies but got a little lost in doing so)
I have verified the RDKFolder path is correct and is a valid RDK
The RDK can be applied very happily via F12 System Monitor with a run rdkinstall.
This auto process works happily for non DICT RDKs
At first I thought it might be attached tables via the service (specifically the destination table not being attached at that point) but this function also processes other aspects of our data tables happily.
There is an eServer error: "Invalid request for input during phantom processing".
OpenInsight is 9.4.6 with Email & Relater patch
Our Frameworks is only 16.0.16 but we somehow have a local-only version of Update Services which, according to the documentation, only came out in 16.0.19.
I can only assume that SRP provded that to use individually once upon a time...
So, with all that, I would be most appreciative if anyone has any ideas to throw out. Even hail mary's.
Obviously I can't 'Auto Deploy' without dictionaries so its a showstopper on my very last hurdle!!
A bit of background, we have written a System Monitor procedure that runs with the eServer service every x minutes.
In our code there is 'manual schedule' (basically it only runs secific code during the certain windows we want those code segements to run).
One of the things it does is download an RDK file and processes it (basically a Live Update scenario).
This process works and is verifiable.
HOWEVER, it only works when the RDK doesn't contain dictionary entries!
As long as it is just procedures, forms, inserts, records, etc the process finishes quite happily.
I can have a deploy that contains just a single dictionary item and nothing else and the process still 'hangs'.
(The table that field is trying to deploy to 100% exists on the destination.)
I have traced through the code and basically it does this:
Update_Services("runRDKUpdate", RDKFolder) ===> RDKinstall(RDKFolder) ===> RdkModuleInstall(RDKFolder, installToDir)And this is where it hangs. It never passes RdkModuleInstall for a DICT entry.
I have a SYSOBJ $RdkModuleInstall entry but I can't step through that to debug any more (I dont think...)
(I have been reading https://blog.srpcs.com/pulling-the-rug-from-beneath-your-feet/ to see if that applies but got a little lost in doing so)
I have verified the RDKFolder path is correct and is a valid RDK
The RDK can be applied very happily via F12 System Monitor with a run rdkinstall.
This auto process works happily for non DICT RDKs
At first I thought it might be attached tables via the service (specifically the destination table not being attached at that point) but this function also processes other aspects of our data tables happily.
There is an eServer error: "Invalid request for input during phantom processing".
OpenInsight is 9.4.6 with Email & Relater patch
Our Frameworks is only 16.0.16 but we somehow have a local-only version of Update Services which, according to the documentation, only came out in 16.0.19.
I can only assume that SRP provded that to use individually once upon a time...
So, with all that, I would be most appreciative if anyone has any ideas to throw out. Even hail mary's.
Obviously I can't 'Auto Deploy' without dictionaries so its a showstopper on my very last hurdle!!
Comments
Did you get to a resolution for that one?
Yes, same error. Same System Monitor procedure. Different step.
Previous errors were resolved by a few things.
1. That particular process was the very final step run in the list and I ended up throwing it off with an immediate RTI_TASK_SUBMIT. I didnt really like the solution but it worked. If it wasnt the last step(like it is) and/or I required it to finish before proceding then that would have been a problem. As an aside, it is also why I recently noted about the buildup in the SYSTASKS table!
2. make sure everything was bulletproof for lack of a presentation layer. No debugs thrown due to unassigned variables, no MSG, no Utility, etc
3. I made sure that things were functions (based on a not Don posted at the end of one of the RTI_TASK wiki pages) and that everything downstream had return values.
Unfortunately that 'hack' (using RTI_TASK_SUBMIT) didn't work for this step. AT least I might understand that. Well maybe.
To be honest, even if it did I wouldn't want to use it because I would want this step to complete before continuing as it needs to be one of the first things run and I can't have it off doing its own thing while the rest of the routine continues (unlike my previous problem).
I deployed in from a 'clean' site RDKMODULEINSTALL. That didnt help.
I manually removed the %RUN% record from SYSUPGRADE for the deploy.
I stopped getting my phantom messages and the process then got through to completion!
Unfortunately it didnt actually bring in the new Field....
Progress perhaps....
Did you try your searches in Revelation Wiki it has all the forum posts in it's wiki.
That is much more user friendly......
I get that runnning an install it is supposed to be copied in from the SYSUPGRADE %RUN% record but what I am trying to do now is work out what %RUN% record comes from.
I have a super old system I stumbled accross that looks like it has a localised copy (renamed) of RDKModuleInstall source. Too old for me to trust it but enough to pique my curiosity.
The reason I ask is reading through some of the OLD posts on the Revelation Wiki (thanks Barry!), some people noted they recompiled the RDKMODULEINSTALL source to fix various problems they were having.
I copied in that RDKModuleInstall (like I said, dont trust it is current but better than nothing?). I routed my whole process to localised versions of everything (Update_Services, RDKINSTALL, RDKMODULEINSTALL) that I logged the heck out of everything!!!
Imagine my surprise, when I was adding logging to RDKMODULEINSTALL I noticed it already had logging. Courtesy of the insert I could see it wrote to UPGRADE.LOG.
Maybe I knew about that file but forgot? Regardless, never before have I had the need to investigate anything upgrade related so...
Upgrade_Status.txt correctly shows:
Installing DICT.ORDER_DISPATCH/WILL_TEST
Upgrade.LOG shows:
Invalid update row instruction in line 14231
{Which means it failed:
if count(Line, UPGRADE_DELIM$) = 1 and len(File) and len(Key) then}
Like I said. Progress!
Nevertheless my logs came through.
There is a line that actually writes the record to the Dcit file it has opened:
write Rec to f_File, Key else
I have a marker to show I processed the line before (successfully open the Dict to f_File)
I can see at this point the Rec variable has the correct info, as is the Key.
I rewrote the Write/Else to be a Write/Then/End Else and put a marker in both the success and fail.
neither hit.
So this is where it stops and gives the phantom input error. On the actual write.
I have LH_Verified the Dict and Data files. no issues. No permission issues on the file.
So, the journey continues!
Much of that source code is now dated and useful to understand mechanics but bereft of later fixes and enhancements. Just beware that if you create your own then you are also on your own and you might be trading off features you add for features that were already added.
Yeah, pretty much what I was worried about.
My compromise at the moment is I have localised things with custom names that ONLY get called in this one instance so nothing else should break.
Famous last words....
Would I be correct in assuming that the %RUN% record in the deploy is taken from the SYSOBJ $RDKMODULEINSTALL record of the source at the time of deploy compilation?
Also, from what I can tell, that record itself will get overwritten by any rdkinstall run against it?
(Not my choice to run a RDK back against what should be The Source of All Truth but I would honestly be surprised if it has never happened)
You would be correct.
Yes, which is why it is bad practice to install an RDK from an older version of OI into a newer version. Going the other direction can also be a problem, but the reverse is more likely to cause problems.
I have no idea when we last did a Clean install but it was long before my time and I have no 'Pristine' environments I can trust. Don helped us out with a project a couple of years back and we got anew environment out of it but I know it has been polluted with RDK installs.
Save me having to go to Rev to try and get an Auth code to install a clean 9.4.....
I think it might just be rdkinstall that is the issue. - but keep both anyway.
I will add that to my Toolbox!