I'm not a python expert, but I'd try with:

imptask = dbnative.classMethodValue('%SYS.Task','ImportTasks',"F:\\Zbackup\\LISBackupTask.xml","ck")

ImportTasks() method returns a %Status that probably contains the answer you are looking for.

I'd suggest to check that.

What kind of task? Does your task provide a return status?

If what you need is displayed in the Error column in the "Task History" page in Management Portal, then you can use the query:

select Error from %SYS_Task.History where Task = <YoutTaskID>

Do you want to use SSL/TLS for incoming connection to IRIS (Ensemble) or want to use SSL/TLS for outgoing connections from IRIS (Ensemble) to other systems, possibly using some HTTP/SOAP/etc. adapter?

Please provide some detail.

I agree, but that's not the scenario of the initial question!

I tried to address and provide a solution to the original question that it seems has some previous constraints imposed by the current design, not to argue of what it could have been done if....

So, this imply that the sample message published in the document "IHE Laboratory Technical Framework, Volume 2a (LAB TF-2a)" is actually an invalid message?

I've used Object Script to update linked tables projected as IRIS/Caché classes, like in your sample, since very long time and it works.

As the error says, your issue is that some property/column cannot be set/modified, I'm pretty sure the same issue arise if you use SQL to update/insert the same column.

Without the table definition it's impossible to guess what's the field and why that column cannot be set.
Maybe some of the fields are part of the primary key that includes other fields that are not set?
Make sure that the table is properly linked, the link table wizard sometime need "guidance" on properly linking tables, particularly in defining primary keys...

Anyway, if properly linked, you can definitely treat/manage/manipulate linked tables the same way as native IRIS/Caché  classes.classes. 

Another option is to use the %SYS.GlobalQuery_Size() class query documented here, it can be conveniently used from SQL like:

call %SYS.GlobalQuery_Size('c:\intersystems\iris\mgr\',,'*',1,,1)

It can be called from the portal SQL or any SQL odbc/jdbc client tool.

Ciao Pietro,

as said %DynamicAbstractObject has excellent performance and can handle easily very large JSON streams/files.
Depending on your system settings, for large JSON you may need to accommodate process memory, fortunately you can adjust it in your code at runtime so you can write robust code that does not depend on system configuration parameters.
Note that the default value of "Maximum Per-Process Memory" has changed during time, so a new installation and an upgraded installation have different values.

IMHO the real question here is: in what side of the JSON processing is your code?

Are you generating the JSON or are you receiving the JSON from a third party?

If you are receiving the JSON, then I don't think there is much you can do about, just load it and IRIS will handle it.
I'm pretty sure that any attempt to "split" the loading of the JSON stream/file will result in worst performance and consumed resources.
To split a large JSON you need to parse it anyway....

If you are generating the JSON, then depending on the project and specifications constraints, you may split you payload in chunks, for example in FHIR the server can choose to break a bundle it up into "pages".

I'm not sure if your question is about loading the JSON file/stream into a %DynamicAbstractObject or about processing the large %DynamicAbstractObject once it has been imported from JSON?

What's your problem and what's your goal?

Does the returned sc status contains the <INVALID OREF> error?

Add this line following the one I suggested:

if $$$ISERR(sc) $$$LOGERROR($system.Status.GetErrorText(sc)

Then check the event log after calling your component and post here what you find in the event log.

An integrity check also treats it as if it was a single file. This is only going to be more of an issue as the max size increses.

There is no other option for integrity check because in multi volume database a global can span across multiple volumes/files and a global structure must be fully scanned to check integrity.

If this is a concern, maybe splitting a global across multiple "small" (the concept of small may vary! 😁) database using subscript mapping can be an option.
Integrity check is performed at database/global level, not namespace/global level.

Evidently there is an issue where you reference MSH:9.2, without details of your rule definition is virtually impossible to guess where the problem is.

I'd suggest to check the returned %Status from the %FromFHIRJSON() method.

Instead of:

do ..FHIRAdapter.%FromFHIRJSON(pRequest.Payload.Read(),.pmReqFHIRobj,"HS.FHIR.Model.Resource.Bundle")

Use:

set sc=..FHIRAdapter.%FromFHIRJSON(pRequest.Payload.Read(),.pmReqFHIRobj,"HS.FHIR.Model.Resource.Bundle")

Then check the status.

There is also this recent announce from @Rob Tweed that mention support for legacy weblink applications:

mg_web for ObjectScript Developers
 

You may have the option of using Extended Global References and in particular Bracket Syntax with References to Databases.

In your code you need to change all your global references from:
^SYS("CommonConfig")
to
^[%dbConfig]SYS("CommonConfig")

Then, for normal situation where you want the %ALL mapping to apply, just use:
set %dbConfig=""
When you need to explicitly map it to a BARCONFIG database, then:
set %dbConfig="^^:ds:BARCONFIG"

This way you can switch from default %ALL mapping to "explicit reference" within your code.
In the example I used a % local variable (%dbConfig) to hold the "database name reference" because it has a global scope, you may use a different approach like a property in some of your classes, a macro with some reference (in a global?) or...whatever is appropriate for your environment.