I have two local instances:

• IRIS for Windows (x86-64) 2018.1.2 (Build 626_3U) Wed Jun 12 2019 19:07:59 EDT
• IRIS for Windows (x86-64) 2019.1 (Build 510U) Thu Mar 14 2019 14:13:37 EDT

I'm using Java Gateway to talk to external system.

Both instances are using the same:

• jar
• generated class
• java version

They are calling the same method with this java signature:

My newest app includes a java routine to read data from Excel 95, 97, 2000, XP, and 2003 workbooks and write the data into IRIS globals using Java Native API library.

If you have Git and Docker installed, clone/git pull the repo into any local directory

$ git clone https://github.com/oliverwilms/excel-java-iris.git

Open the terminal in this directory and run:

$ docker-compose up -d

Execute java class IRISNative

Hi folks.
I'm having trouble using the native iris API in an environment running wildfly 16. Here's a piece of my java class and stackTrack, I'm using jdk 8.

Consider a Natural Key with an Identity (Serial) field.

I cannot seem to acquire the generated value after persisting my entity. That is, the returned entity by Spring Data's "save" does not have the generated value.

The value is generated by the database, and I can query it after repository.save(entity).

I have done some testing and created a Github repo with it...

This is the first follow up after the post about headstarting SAPJCo3 with Ensemble and HealthShare ( https://community.intersystems.com/post/headstart-connect-sap-using-sapjco3-ensemble-and-healthshare).

We are planning to build a REST API with the Java Quarkus Framework.

• There'll be a connection pool;
• The DataSource instance will be automatically injected from the connection pool;
• We will use JDBI to do SQL instructions and this will give us automatic Connection and Statement management;

This Caché instance already have COS applications running and consuming connections and licenses.

After doing this, we will migrate to IRIS.

Many times it is necessary copy or send files to your docker container instance.

In my case was with IRIS JDBC driver.

Docker has this recipe for this (credits to https://docs.docker.com/engine/reference/commandline/cp/):

docker cp [OPTIONS] CONTAINER:SRC_PATH DEST_PATH|-
docker cp [OPTIONS] SRC_PATH|- CONTAINER:DEST_PATH

But to copy you need your container name. Write this command for this:

docker ps

In my, my-iris is the container name.

Problems encountered with Java Gateway

I am writing a framework for use on the Java Gateway. The role of the framework is:

1. Import the framework jar file into ensemble studio (test completed);
2. In the framework jar, handle the related functions of the remaining jar files (the rest of the jar files are written by colleagues).

The general idea is as follows:

Send: Ensemble Java Gateway -> Framework Jar -> Plugin Jar (colleagues write, processing data).
Returns: Plugin Jar (processed return data) ->Framework Jar->Ensemble Java Gateway.

Based on the successful solution for my 2nd contribution to the Contest
I used an adapted version for this package. And have some findings I'd like to share.

Multiple communication steps over CPIPE may take time.
You won't recognize it on a fast machine. But a slower box with
Windows + Docker Desktop + your browser (and more) is neither
"Speedy Gonzales" nor a "Road Runner". 🙂

Is there a way problematically to see what Operations/Services are attached to a EnsLib.JavaGateway.Service and if there are issues with the EnsLib.JavaGateway.Service to stop/start those Services/Operations that might be attached to it?

Thanks

Recently I started moving some of our JDBC Gateway configurations over to using the Microsoft JDBC Gateway driver instead of using the jTDS open source driver. I have noticed since then that those Objects that are using Microsoft JDBC Driver are throwing a lot more errors than the jTDS driver ever did, which I can understand however I am puzzled that I keep running into an issue with the Java Gateway Service within the Interoperability engine.

Presenter: Maxim Vershinin
Task: Easily extend your solution’s range of interoperability
Approach: Build Java-only business services and business operations that exploit open-source Java libraries

Problem: The title states the problem Open source java libraries exist for hundreds of protocols and formats. This session explains how you can easily build java only Business Services and Business Operations to that exploit these libraries to extend the range of interoperability.

Content related to this session, including slides, video and additional learning content can be found here.

Starting with 2016.2 the Java XEP binding will no longer support the in-memory connection mode. The in-memory mode was deprecated in earlier versions and applications should switch to the TCP/IP connection mode instead.

The TCP/IP connection mode has bridged the gap in performance to a large extent over the past couple of years and enables the Java client to run on a remote machine.

Let me know if you have any questions or concerns.

This is a FYI for anyone who has experienced the following error after upgrading an existing instance to any product based on Caché 2017.2.2. In our case, the products are HealthShare HealthConnect for Redhat x64 and for Windows x86-64 but I believe it would be a common problem for any InterSystems product on any platform, if based on Caché 2017.2.2. After upgrading our development instance from 2016.2.2 to 2017.2.2, we experienced the following errors when attempting to start a pre-existing Java Object Gateway that was defined prior to the upgrade: