In a healthcare setting we've an Ensemble namespace through which passes a key HL7 feed (the ADT feed from our PAS). It is split up, transformed and passed on to multiple downstream systems. We consider the feed going to each downstream system an interface. Each interface is developed as separately as possible - typically as a separate branch of our git repo (which we access via VS Code).
When I try to debug using the docker image intersystemsdc/iris-community it is failing. If I change to intersystemsdc/iris-community:2022.3.0.555.0-zpm, I have success.
Sorry, change to: intersystemsdc/iris-community:2022.1.0.209.0-zpm
A small reflection/question for today... it's true that new IRIS for Health (I4H) releases are more and more powerful each time regarding FHIR capabilities. Nowadays it allows us to consume FHIR resources with extrem easiness, we can connect with end-points in external FHIR servers very easily and make I4H act as passthrough or consume their resources... or, even more, we can define, configure and run a FHIR repository in, literally, less than 5 minutes.
We have a bunch of templates on OEX that provide a handy foundation for building a particular application with IRIS. And the basic principle of each and every template is that we take vanilla IRIS images, load code, and files into the image using Dockerfile, and create a new docker image as a solution. And then we develop running this image and rebuilding it when returning to development.
Some developers ask me why we need to build the docker image to work with the code. Indeed, if at the end of the day I need to develop a ZPM package and not a docker image why don't run the vanilla image and load the code and everything in it?
The problem I have with the building image approach is that often I can wait a lot to build an image and it fails on some Objectscript problem in the source that I cannot fix as the image is not building. and
I would like to watch a webseminar about debug objectscript techniques into vscode to rest api, productions and embedded python, specially using docker instances and remote servers.
Intersystems recently announced a partnership with unqork. I would like to know if someone already used this tool, or another tool, and how was the experience. Is there within the intersystems ecosystem (partners) any low-code tool that generates COS? Tks
The use of Source Code Control systems in development is important. And there are a few systems known in the world, like GIT, SVN (Subversion), Perforce, Mercurial. Where the most popular nowadays is the git. Using it is very useful in many cases, but mostly it depends on the code as text, which can be compared between commits, branches, or versions of releases and so on.
Hi, It can now be programmed with different development enviroments in Cache / Iris. The question arises which is the primary IDE Intersystems prefers when it comes to new features. We are working in a small team, should we use Atelier or VSCode in addition to Studio?
Is anyone in the fine community of developers who work with ISC technologies looking at Microsoft's Visual Studio Code offering?
One of Bill McCormick's recent posts about Atelier referred to Visual Studio being considered the best IDE. Granted, Code is far less of a tool than VS, and probably always will be. But it claims to be open source and cross-platform, i.e. Linux and OS X as well as Windows.
By update
