You can change the port from 57772 to 80 in System Managment Portal: System Administrtion -> Configuration -> Additional Settings -> Startup -> WebServerPort

Or cache.cpf configurtion file:

WebServerPort=57772  to WebServerPort=80

Better, proper and suggested solution: install a properly configured web server using port 80, don't use the little web server installed by Ensemble.

Enrico

If you use custom port there is no session, that's expected/by design.

A session (%session) is a %CSP.Session object that is available only when the SOAP service uses a standard request via a properly configured web server (apache, IIS, other), to configure it check the "EnableStandardRequests" setting in the Business Service, configure the Web Application and the web server (or use default namespace Web Application), then invoke the service via the web server port.

In my experience I prefer to use standard request via web server, in general there is no need or valid reason (I can think of) to use custom port, unless you need something very specific, for example you don't have a web server (so...no SMP, something very unusual...).

Enrico

Sorry but I don't understand the problem/issue, starting from 2023 a web server is a prerequisite for IRIS, I's say that is almost mandatory unless you have some very particular use case.

What's the difficulty of installing Apache or IIS in windows?

Providing that IRIS installation properly configure the WEB Server (IIS or Apache), I don't see the difficulty. Or I'm missing something?

Use Microsoft Windows to install IIS.
Once installed you can install InterSystems IRIS, which will ask the user if IIS should be configured.

Unfortunately, as of latest IRIS and any previous IRIS/Caché, after default/standard configuration by install kit the SMP won't work properly without additional manual configuration of IIS.

I suggest ISC to fix this before removing PWS.

Try enabling the log in the Java Gateway. In Management Portal:

System Administration > Configuration > Connectivity > External Language Servers > Edit External Language Server

Edit the "%Java Server" (you may need to stop it, if started) and in Advanced Settings specify a Log File.

Then reproduce the problem and check the log file.

The log file (in some case) can grow significantly, you may want to disable it when done.

Enrico

Frankly I cannot see any advantage in using the sample you posted, it makes things more complicated with no advantage and no, it's not faster than just use a plain simple property.

There are cases when those "tricks" (calculated properties, Set/Get methods) can be useful, but that's not the case of the code in your sample.

Regarding VALUELIST, it makes it easy and simple to define a (typically small) set of valid values for a property, then, if necessary, you can optionally provide a "user friendly" representation of those value. If you don't find it useful or don't need it, well....don't use it.

Enrico

The solution in simple....if you know it:

 set addressArray=netGate.new("remote.test.Address[2]")
 do addressArray.%set(0, home)
 do addressArray.%set(1, home2)  set person = netGate.new("remote.test.Person")
 do person.setAddressArray(addressArray)
 set addressArray2=person.getAddressArray()
 for i=0:1:1 {
      set addr = addressArray2.%get(i)
      !, addr.city
 }
 

In addition to %set() and %get() method for arrays there are also %setall(), %getall() methods.

Hopefully these methods will be documented sometime in the future.

Enrico

I realized the problem using "Recast", the gateway needs to be instantiated using the new gateway.

I had to fix a couple of things related to how the datatypes are casted and now it works.

However, this is not exactly what I was looking for, as mentioned my goal is to convert existing code that use the no longer documented "legacy gateway" to "new code" using the current (poorly) documented $system.external.

My goal is to move "forward" my code for current and future releases of IRIS.
Removing the need of the imported proxy classes also simplify the IRIS upgrade process.

Thank you again and enjoy your vacation!

Enrico
 

Hi Stuart,

thank you so much for your answer and effort, I feel sorry for your vacation!!

As mentioned, to keep things simple in my test instead of using my "real stuff" (somewhat more complex) I'm using the "old" test code %Net.Remote.DotNet.Test and corresponding .NET project that I have compiled with .NET Framework 4.5, this provides a simple testbed to test basic functionality.

Using the now undocumented legacy gateway the test works fine

Then, when I:

set ^%SYS("Gateway","Remote","Recast",namespace)=1

and reimport proxy classes, I can see that the generated proxy classes are different, so the "recast" had some effect.

Unfortunately running the test code....fail in the very first line:

USER>do ##class(%Net.Remote.DotNet.Test).Test(58555)
 
Errore #5023: Errore del gateway di Java: <ZJGTW>%dispatch+17^%Net.Remote.Base.1

It fails in the line (the first call to .NET class):

Set student=##class(remote.test.Student).%New(gateway,29,"976-01-6712")

So...neither this approach works...at all.

Thank you again,

Enrico