Ciao Ilenia,

what kind of single FHIR resource is so large so that you need to split it?

If there are multiple resources, then you can post them individually.

Are you running it from an elevated (administrator or equivalent) command prompt?

New variant that I like it better 😀

%SYS>Set ResultSet=##class(Config.Namespaces).ListFunc()
 
%SYS>While ResultSet.%Next() {  Write ResultSet.%Get("Namespace"),$c(9),ResultSet.%Get("Globals"),$c(9),ResultSet.%Get("Routines"),!}
%ALL%DEFAULTDB%DEFAULTDB%SYS    IRISSYS IRISSYS
USER    USER    USER
 
%SYS>

A Business Process can only be invoked/called from a Business Service within an Interoperability Production.

You can invoke/call a Business service from your code/application with:

Set sc = ##class(Ens.Director).CreateBusinessService("BusinessServiceName", .BService)
If$$$ISERR(sc) ; handle error hereSet sc = BService.ProcessInput(BSRequest,.BSResponse)

I'm not sure what "HL7 Reference Guide" exactly means for you, however, within "health enabled products" (IRIS for Health, Healthhare Connect, Healthshare UCR etc.) there are "HL7 Schemas" for all HL7 v2 variants up to 2.8.2.

Can be accessed from Management Portal Interoperability -> Interoperate -> HL7 v2.x -> HL7 v2.x Schema Structures.

There, for each version you can browse in detail the HL7 message structure, segments, field, subfields etc down to code tables associated to coded entries/fields.

If you don't have IRIS for Health, you can download IRIS for Health community edition that is free for non commercial/production use (check license for details).

This is interesting.

It is evident that when the class is compiled IRIS parse the <PropertyName>Computation() method(s) to find out what properties are actually used/referenced/passed to the cols.getfield() method(s), then it use this information to set the "fields" multidimensional property of %Library.PropertyHelper class before calling the <PropertyName>Computation() method.
This way only the used properties are set in the "fields" multidimensional property of %Library.PropertyHelper class.
This optimization improves performance in case of a class with many properties, possibly "complex" properties (calculated, references etc.) and I believe this is why has been implemented.

The "parser" is...simple, very simple.

To prove this assumption I wrote a little sample:

Class Community.Computation Extends%Persistent
{

Property FirstName As%String;Property LastName As%String;Property FullName As%String [ SqlComputed ];ClassMethod FullNameComputation(cols As%Library.PropertyHelper) As%String
{
    ; cols.getfield("FirstName"); cols.getfield("LastName")return..FullNameComputationSub(cols,"FirstName","LastName")
}

ClassMethod FullNameComputationSub(cols As%Library.PropertyHelper, p1 As%String, p2 As%String) As%String
{
    return cols.getfield(p1)_" "_cols.getfield(p2)
}

/// do ##class(Community.Computation).test()ClassMethod test()
{
    set obj=..%New()
    set obj.FirstName="Enrico"set obj.LastName="Parisi"write obj.FullName,!
}

}

If I run test() I get:
 

do ##class(Community.Computation).test()
Enrico Parisi

If I remove the commented line "; cols.getfield("FirstName")" and run test() again:

do ##class(Community.Computation).test()
 Parisi

If you look at your error:

"set cols.fields("ropert")={ropert}'"

That's the parser that found "cols.getfield(property)" and assuming a string was passed removed the first and last characters (assuming were double quotes), so it got "ropert".

Bottom line, cols.fields() can only be used passing a string constant with a property name.

Thinking of this, in fact I really believe it's not possible to implement setter/getter methods in datatype classes because datatype methods are, by design, classmethods and getter/setter methods are and must be instance methods.