Thanks Ben, good start for a conversation in our team...
- Log in to post comments
Thanks Ben, good start for a conversation in our team...
Shamus, thanks, works perfectly. Much appreciated.
Thanks for suggestions so far.
One challenge is our organisation is very wary of installing any additional code (as Alex suggested) or hooking up something like VS Code, to the live server, which is passing patient information between the various hospital systems... The test system has a little more flexibility, but organisation is a bit twitchy!! Would a plausible path be to sort of follow Eduard's suggestion, but:
Thanks all for responding. Really only adding this message so I can try and mark the question as answered - since there are the two approaches (ompare and using git/repo tools), not wanting to mark one or other as the answer, since both have merits and may be helpful for different situations. I suspect we'll try the git/repo tools approach first, given our particular mix of platform and experience.
Thanks Cristiano. I'd found the page you linked to before, but its not very explicit about uninstallation!
Would I be correct in interpreting it as:
Thanks!
Thanks @Evgeny.Shvarov. Unfortunately can't use Iris yet - maybe at some point in the future - but a useful extra benefit when we do make the transition.
For completeness / in case others come across this, turned out the XML export file was being corrupted during transfer between the two systems. It was a CR/LF corruption - in our specific case CR/LF was getting converted to CR/CR/LF !!
Highlighted that DTL's specifically appear sensitive to CR/LF changes - we've subsequently come across the same #6301 error loading DTL's get CR/LF modified in another way (we're still tracking that one down, though suspicion currently is with git...)
Turns out it wasn't git's fault - though really helpful for us to clarify what git is doing, and ensure we have a decent set of default .gitattributes set...
We don't fully know what is going on, but ALL DTLs on one Ensemble instance throw this error, on load in Management Portal or compile via Studio or VS Code - can't even create a new DTL. So we are currently suspecting some kind of corruption/error on that server, rather than something related to the code we are bringing from git. But no idea what has gone wrong. Its a dev server - we may just scrub it and reinstall...
That looks ideal, thanks! Almost like it was designed to do the job we are looking for...! 🤣 Will investigate properly for our specific situation.
Is there documentation for this? I searched "package manager" in the documentation and didn't get anything in the results....
Thanks for suggestion, but we already know it affects all namespaces 😥
Thanks. Not sure how to do all the things you suggested (1 or 3), but tried (2) using the Scheduled Tasks page in management portal. Couldn't suspend or delete the problematic task - getting SQL errors about not being able to lock or access a table.
Thanks. Not sure how to do all the things you suggested (1 or 3), but tried (2) using the Scheduled Tasks page in management portal. Couldn't suspend or delete the problematic task - getting SQL errors about not being able to lock or access a table.
Thanks Alexander. Terminal Task Manager:
Re figuring our where system tasks are stored via journalling, I understand the principle of what you are saying but we are probably reckoning the effort in doing that at least as great as scrubbing and reinstalling - we lose some config (we've got it documented, but the developer who did it originally has left), but no important running code.
Alex, thanks. Yes, license is still valid. And no, not possible to suspend before changing problem item - getting databases locking errors when I try. No idea how we managed to corrupt this quite so thoroughly!!
For the sake of having an "accepted" answer on this post: we never got to the bottom of what was going on, and scrubbed and reinstalled Ensemble. Thanks for suggestions - some useful learning, even if we were never able to get to the bottom of what was going on.
Carmen, thanks, that's really helpful. If we need further information we'll reach out - as is so often the case, I'm doing some technical investigation for a development that may not ever be tackled, or may be tackled in a different way, or whose specifications will change wildly before we tackle it, or...!!!
I asked a related question a few months ago - I'll link to answers here. There is some overlap, eg Alex Woodhead's comparison tool, but hopefully helpful. Comparing code on running servers | InterSystems Developer Community |
Thanks, yes, this is what it needed to be - got there myself, as it happens, but thanks. Documentation wasn't very clear.
Keren, great, thanks - this has allowed me to see the content of the messages and I can dig further.
Thanks Ben, helpful answer. Another reason to try and kick our organisation towards upgrading to Iris 😉
Thanks @Ashok Kumar T , with a bit of tweaking that got us to where we needed to go. For clarity for anyone coming along and reading this later the steps would be:
Once all this is in place, you can call a BPL Business Process from a scheduled task.
Thanks for this. Yes, Schedule is there in Ensemble 2018.1 as an additional setting. We will investigate and see whether its a suitable/cleaner alternative to Ashok's suggestion.
Can I clarify: "Run at a scheduled time" could mean either:
We are interested in the second of these - we want a batch job to run at 0800, at 1300, and at 1600 each day. When it runs it will scoop all the current labs results out of the database table where they have been accumulating, and send them on to the downstream system.
Thanks, helpful to explore another potential option. If I'm reading https://docs.intersystems.com/iris20233/csp/docbook/DocBook.UI.Page.cls… correctly then we'd need to use the OnProductionStart method of the business process to run when the job is scheduled - and not sure that's obviously accessible in a BPL business process. There are otherwise no incoming messages to trigger action.
I'm interested in finding out more about the GitLab CI/CD pipeline options that might be available outside of the Cloud offering.
We are currently Ensemble 2018.1, though hopefully moving to Iris soon. Our development workflow is:
So we'd be really interested in the CI/CD options mentioned in the GitLab instance offered as part of the Iris/Health Connect Cloud - the dev, test and production deployment deployments. Is the stuff offered on the Cloud available on prem? Is there more information available somewhere about the CI/CD options in GitLab and integrating with Iris?
Thanks Eduard, that answered my question without me having to ask it!
Follow-up, as a quick and dirty check, I replaced the call to GetValueAt above with:
set step1 = $PIECE(message.RawContent,"OBR|")
set step2 = $PIECE(part1, "ORC|", *)
set ReportId = $PIECE(part2, "|", 3, 3)This works before calling the XML generation code when GetValueAt doesn't - so GetValueAt is definitely doing something to the contents of the HL7 message....
Follow-up/solution: we can do:
set message2 = message.%ConstructClone(1)
and then use message for the XML generation and message2 for calls to GetValueAt, and that works OK.
Still don't know why GetValueAt appears to change the content of the message...
Never mind, I'm an idiot. One of my colleagues found the issue - I thought I had, but I hadn't managed to add both:
I think I'd added one to TNHS.SOAPclassExtra, hadn't worked, tried the other, but somehow failed to check both together...🙄 Working now.