go to post Colin Brough · Nov 27 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.
go to post Colin Brough · Nov 23 Can I clarify: "Run at a scheduled time" could mean either: Run during a designated period of time, thus making the service / business process available to be triggered at anytime during that period but not outside that period, or Run once at a specific time, and never otherwise be triggered. 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.
go to post Colin Brough · Nov 22 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.
go to post Colin Brough · Nov 22 Thanks @Ashok Kumar , 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: Create the BPL Business Process you want to call - at least have something in place you can call Create the HL7Task.Test class in ObjectScript from the example above - renamed as appropriate. The argument to CreateBusinessService is the name in the Production of the Service you will be calling (created below). Also you need to set pInput as a class suitable for use as a request, such as Ens.Request or (we used for an example) Ens.StringContainer Create the HL7.Feed.TriggerService class in ObjectScript from the example above, renamed as appropriate. In the Production, create a new service (whose name is that used in step 2), and whose class is the one created in step 3. Set the TargetConfigName on the service to the name of the BPL. Set the Pool Size to zero. Create a new scheduled task - run it in the appropriate namespace, and pick the class name from step 2 in the Task Type dropdown - and schedule as appropriate. Once all this is in place, you can call a BPL Business Process from a scheduled task.
go to post Colin Brough · Nov 14 Thanks Ben, helpful answer. Another reason to try and kick our organisation towards upgrading to Iris 😉
go to post Colin Brough · Oct 18 Keren, great, thanks - this has allowed me to see the content of the messages and I can dig further.
go to post Colin Brough · Oct 12 Thanks, yes, this is what it needed to be - got there myself, as it happens, but thanks. Documentation wasn't very clear.
go to post Colin Brough · Oct 10 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 |
go to post Colin Brough · Aug 11 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...!!!
go to post Colin Brough · Jul 18 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.
go to post Colin Brough · Jun 12 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!!
go to post Colin Brough · Jun 7 Thanks Alexander. Terminal Task Manager: can delete other tasks, but trying to delete the "corrupted" one get: "ERROR #5803: Failed to acquire exclusive lock on instance of '%SYS.Task'" (same as when using Management Portal) 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.
go to post Colin Brough · Jun 7 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.
go to post Colin Brough · Jun 7 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.
go to post Colin Brough · Jun 7 Thanks for suggestion, but we already know it affects all namespaces 😥
go to post Colin Brough · Jun 6 Is there documentation for this? I searched "package manager" in the documentation and didn't get anything in the results....
go to post Colin Brough · May 29 That looks ideal, thanks! Almost like it was designed to do the job we are looking for...! 🤣 Will investigate properly for our specific situation.
go to post Colin Brough · May 25 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...
go to post Colin Brough · May 18 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...)
go to post Colin Brough · Apr 21 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.