Actually, reviewing more closely, it looks like your version string is for Unified Care Record / Patient Index. That has a different set of requirements than the basic IRIS migration. I'd recommend closely reviewing the HealthShare documentation - I'm not personally very familiar with the HealthShare side of things, but I'm fairly certain there is a version plateau for HealthShare to allow for the move to IRIS.

edit:

this doc page at least is relevant:

Unified Care Record Installation and Migration Guide > Preparing for an Upgrade Installation

https://docs.intersystems.com/hs20211/csp/docbook/DocBook.UI.Page.cls?KEY=HEINS_prep#HEINS_prep_considerations

"If you are upgrading from a Caché-based Unified Care Record or Information Exchange system earlier than version 2019.1, you must first upgrade to the plateau version 2019.1 before upgrading to this release."

Now that you mention it, I think you have not followed a supported migration path. You can find details in the IRIS migration guides available in the WRC distributions page's documents section, but the minimum version to migrate in-place from is 2016.2.x, and it can be used to go to IRIS 2019.1.1+ or 2020.1. It does not support migration directly to 2021.1.

Sai,

By folder, do you mean moving a class to a different package? It's okay if the class name overlaps, because the package will still differentiate the "full name" of the class.

ex, the following can coexist. 

package1.class

package2.class

You could also use subpackages such as package1.subpackage.class.

Some of the built in class divisions might be helpful for you to compare with - for example, on IRIS for Health, the following packages exist:

EnsLib.HL7.Operation

EnsLib.HL7.Service

etc., for each type of business component.

I certainly agree that having Git / source control set up is a good practice. You may also find the built-in production deployment functionality useful:
https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=EGDV_deploying

Hello Alicia,

I would recommend you reach out to your Athena representative for guidance on what version of IRIS to migrate to. I anticipate you will also need them to distribute to you the appropriate kit.

It also sounds like you are planning to go live with this change in the very near future. I would suggest testing this upgrade before attempting in your live environment.

edit: I may have misinterpreted your org. If you are licensed directly with InterSystems, I'd recommend reaching out to your InterSystems account rep. If you are licensed through somebody else, they can help you with the migration to IRIS.

That makes sense to me. As the docs explain, there is not really a "%ALL" namespace, it's more of an abstraction to represent a system-wide mapping.

Once you have set up a %ALL mapping, I would just directly try to verify that the functionality works as you expect. For example, make a AllMapping package and put your test code in there, then make an AllMapping package mapping for %ALL, then confirm that you can access that code in any namespace.

Vivek,

Your version of IRIS for Health doesn't have the SMP UI to create a FHIR server. That was added in 2020.2.

https://docs.intersystems.com/irisforhealthlatest/csp/docbook/DocBook.UI.Page.cls?KEY=HXIHRN_new#HXIHRN_new_serverui

I'd suggest you look at the 2019.1 docs for your version's instructions. That being said, IRIS' FHIR support is being actively developed so it is changing frequently. If you can upgrade to the latest version of IRIS for Health, you will get access to the most functionality (and quality of life improvements like the SMP option!)

Hello Muhammad,

Either documentation page explains the difference:

Embedded Language Development > ObjectScript > ObjectScript Reference > ObjectScript Functions > $INCREMENT

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=RCOS_fincrement#RCOS_fincrement_seq

"$SEQUENCE and $INCREMENT can be used as alternatives, or can be used in combination with each other. $SEQUENCE is intended specifically for integer increment operations involving multiple simultaneous processes. $INCREMENT is a more general increment/decrement function.

$SEQUENCE increments global variables. $INCREMENT increments local variables, global variables, or process-private globals.

$SEQUENCE increments an integer by 1. $INCREMENT increments or decrements any numeric value by any specified numeric value.

$SEQUENCE can allocate a range of increments to a process. $INCREMENT allocates only a single increment.

SET $SEQUENCE can be used to change or undefine (kill) a global. $INCREMENT cannot be used on the left side of the SET command."

Hope that helps!

Yakov,

I'm not sure I understand your comment. It sounds like the setting is working for the most part - when you add all the IPs (desired and undesired) you can see all messages flow. If you remove certain IPs from the list, you can see those IPs being rejected. There is a disconnect between that last sentence, and the behavior you are explaining where allowing IPs doesn't work.

Can you elaborate on this discrepancy?

Muhammad,

That "missing" class is shipped with the Health side of ISC products (ex. IRIS for Health, HealthShare UCR, Health Connect). The fact that it can't be found is somewhat worrisome, but you can narrow this down into 2 main possibilities.

1. the class actually doesn't exist on your instance. I would recommend finding out how that could have happened.

2. the class does exist, but can't be found by the process, potentially because of a namespace / mapping issue. I would take a look at your mappings to see why this class is not available.

Besides those 2 points, a few questions to ask would be: When did this start happening? What changed? Was this class able to be found before?

Hello Jennifer,

While ISC docs are down currently, here's a web archive link to the section that discusses VIPs in the cloud:

https://web.archive.org/web/20201026104034/https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GHA_mirror_set

"Typically, a VIP cannot be used in cloud environments. For a review of the options for configuring application redirection following failover in a cloud environment by an InterSystems Principal Technology Architect, please see Database Mirroring without a Virtual IP Address on InterSystems Developer Community."

Here are links to that and another potentially useful article on the community.

https://community.intersystems.com/post/database-mirroring-without-virtual-ip-address

https://community.intersystems.com/post/intersystems-example-reference-architecture-microsoft-azure-resource-manager-arm

Hello Guilherme,

Why do you ask? I can't say literally everything to your 2 questions but the vast majority of things are available across products and OSes. A few technologies have been deprecated/removed from IRIS so those won't be available, you can read about those in the IRIS migration guide available from the WRC distributions. Separately, I'm aware that there are at least a few OS-specifics that are documented as exceptions.

Do you have specific functionality that you are concerned about?

Your link is personalized to your login so I wasn't able to load it, but I found ISC1064 Building Custom Business Operations. I didn't see any references to enslib explicitly when I scanned; can you point to which module or what the instruction is asking you to do?

The exercises I see refer to the INTEROP namespace, which I see is preinstalled in the lab.

If you find something that doesn't look correct in a course, you can reach out to onlinetraining@intersystems.com for guidance/correction.

edit: once I registered for the course your link then worked and brought me to 2.2 the section on adapters, but I still didn't see a specific reference to Enslib.

Hello Michael,

I'll post this on Li's original post as well, but if this is on Windows I suspect this is an issue with using the default SYSTEM account. See the following doc:

Installing InterSystems IRIS on Microsoft Windows > Windows User Accounts

"When installing InterSystems IRIS, you must choose the Windows user account to run the InterSystems service. There are two options:

The default SYSTEM account (Windows Local System account). This is used in Minimal security installations.

A defined Windows user account.

Running the Windows InterSystems service under the default SYSTEM account is appropriate for many installations, but in some cases can cause issues relating to file permissions and network security access. If you anticipate potential problems in these areas for an InterSystems IRIS instance, for example due to your network configuration or security arrangements, specify an account for the Windows InterSystems service that has the needed privileges and/or access, such as a domain administrator account.

For instructions on how to change the service account after installation, see the Managing Windows User Access to the InterSystems IRIS Instance section."

Changing the InterSystems Service Account

<install-dir>\bin\IRISinstall.exe setserviceusername <instance-name> <username> <password>