In your generated (from wsdl) SOAP client class change the LOCATION class parameter with correct url including port number.

Another option is to set the Location property in your code when you use the client class, somthing like:

Set wsClient=##class(your.generated.SoapClient).%New()
Set wsClient.Location="https://path.to.server:NNNN/path.to.service"
Set client.SSLConfiguration ="SSLConfig"

I had a similar issues with IRIS 2021.2.

In one case a class with an object reference calculated property failed to compile.
The workaround was to add %JSONINCLUDE = "OUTPUTONLY" to the property.

The second case was a class that contains a property (not calculated) that is an array of %Stream.GlobalBinary (that was not supported) and despite I added %JSONINCLUDE = "NONE" the class did not compile.
For this I got a quick fix modifying a library class.

My suggestion is first to to reproduce the issue with a VERY SIMPLE test case and test it using latest IRIS version 2025.1 and, whatever the test result is, report it to WRC including the result of your test using the latest IRIS version.

Every routine, class or global that start with "%" is mapped to a system database, usually "%SYS".

In your case %Test.mac is (by default) mapped to the %SYS database.

It seems that you (the user you connect to IRIS) don't have permissions to write to the %SYS database.

Please note that during IRIS upgrade all routines starting with "%" are DELETED, unless they start with %z or %Z, so I suggest to use a different name or, better, create your code in other namespace/database with consistent naming (package name) and map it from your application namespaces. If you need your code in all namespaces, create a mapping for the %ALL (pseudo) namespace.

Hi Daniel 😊

can you elaborate "$p($view(-1,-3),"^",6)"? 😉

Your code gives the impression that to implement this solution requires knowledge that we "simple humans" don't have.

Fortunately this is not the case, instead of the cryptic, obscure, arcane and undocumented $p($view(-1,-3),"^",6) the simple $ZNAME special variable can be used. 😃

I'd implement a custom function, create a class like:

Class Community.CustomFunctions Extends Ens.Rule.FunctionSet
{

/// Returns Age in years from DOB in YYYYMMDD format
ClassMethod GetAge(DateOfBirth As %String) As %Integer
{
    Quit (($H-$ZDATETIMEH(DateOfBirth,8)) \ 365.25)
}
/// Returns Age in days from DOB in YYYYMMDD format
ClassMethod GetAgeDays(DateOfBirth As %String) As %Integer
{
	Quit ($H-$ZDATETIMEH(DateOfBirth,8))
}

}

Then from any Rule or DTL transformation you can use these two function as any other built in function.

Make sure DOB is not null ("") before calling the function.

You case is simpler, you do know the json structure and all you need is to iterate the "items" array and find all the portalUrl and pureID properties. Note that since there can be many "items", there may be many portalUrl and pureID.
 

	Set itr=responseData.items.%GetIterator()
	while itr.%GetNext(.key, .value) {
		Write value.portalUrl,!
		Write value.pureID,!
	}

P.S.: it's unlikely that the Response you get from a REST call is a %DynamicAbstractObject since, by definition, that's an abstract class and cannot be instantiated, what you actually get is a subclass of %DynamicAbstractObject, a %DynamicObject in this case or a %DynamicArray when the response is an array.