I suspect you have some inconsistency in the Character Encoding in your XML.

Is the XML Character Encoding declared? If yes, how?

i.e. does the first line contains something like "<?xml version="1.0" encoding="utf-8"?>" ?

How are you crating the %XML.XPATH.Document instance from your XML?

It would be helpful if you can post a tiny code to reproduce the issue.

Enrico

"I realized that the headers are being reseted, keeping just 3 basic headers for the redirection"

Sounds/looks like a bug to me.

Enrico

Out of curiosity, was the system upgraded from a Cahcé based product? (Ensemble, HealthShare etc.)

Enrico

Hi Yone,

it would be nice of you if you provide a feedback on the answers you receive.

Enrico 

Command pipes (CPIPE) or Named Pipes (NPIPE)??

Any little, as simple as possible, test code of what you tested?

Enrico

I'm not sure I understand your issue right, my understanding is that you receive an XML declared as UTF-8 that contains ISO-8859-1 characters.

If so, you can convert the encoding of the stream content using something like:

/// Convert the encoding of the content of a stream to UTF-8./// If OutStream is not passed (of any %Stream.* class), then a new %Stream.GlobalBinary is returned./// Note that OutStream IS NOT SAVED on exitClassMethod ConvertStreamToUTF8(InStream As%Stream.Object, ByRef OutStream As%Stream.Object = {##class(%Stream.GlobalBinary).%New()}) As%Status
{
	Set sc=$$$OKSet MaxRead=$$$MaxLocalLength\2; to be safeTry {
		While 'InStream.AtEnd {
			Set content=InStream.Read(MaxRead)
			Set sc=OutStream.Write($ZCONVERT(content,"O","UTF8"))
			If$$$ISERR(sc) Quit
		}
	} Catch CatchError {
		#dim CatchError as%Exception.SystemExceptionSet sc=CatchError.AsStatus()
	}
	Quit sc
}

If the problem is different, please provide more info/details, maybe a sample XML (not necessarily the original XML).

Enrico

I've no idea why it does not works, however, why do you use % classes now days?
Today there is (IMO) a better way to implement system wide accessible classes/code without "messing" with % classes (or code in general) stored in the IRISSYS database.

Create a new database & namespace (creating namespace is optional but convenient), say you call it JIULIB and put all your system wide accessible code there with proper (unique) package naming.
In this case you can call your sample class pylib.Utility instead of %Zpy.Utility and save&compile it in your JIULIB namespace.

Then create the ("virtual") namespace called %ALL and map the package pylib to your JIULIB database and voilà, your pylib package is accessible from ALL namespaces currently defined and new ones created afterwards.

In this way you have all your lib code properly divided in your own database (may simplify upgrades) and is a more "container friendly" configuration.

Bonus: your python test works! (just tested in my system)

Today there is no good reason to use/make %* classes/code, leave %* to InterSystems.

Relevant documentation is here.

Enrico

Have a look to the sample in this post.

Enrico

Purging every N days should keep the database size almost constant, assuming a constant number of messages.

Unless you have some other database classes that keep growing.

Are you purging message bodies too?

What kind of messages does your production use? HL7 only? Other messages?

You may have orphaned messages in your database.

Regarding moving a CACHE.DAT, can you stop the system for the time it takes to copy the file to a different filesystem/drive?

Enrico

From classreference:

Properties which can be modified for an already created database are:
    ReadOnly
    .......
So, after the creation of the database:

Set db=##Class(SYS.Database).%OpenId("/InterSystems/cachedb/mydatabase")
Set db.ReadOnly=0
Write db.%Save()

Enrico

Hi Yuri,

very interesting project.

Is there any particular reason for using Java to call a (relatively) simple REST API?

Calling a REST API can be easily implemented in IRIS directly without the "Java layer".

Enrico

Hi Michael,

in order for %JSONImport() method to work properly the class of "pResponse" (inheriting from %JSON.Adaptor) MUST match the structure of the JSON being imported.

From the error it seems this is not the case for your class and JSON.

Another option is to load/import the JSON stream into a dynamic object {} (%Library.DynamicObject) and then "manually" set your pResponse properties from the dynamic object properties.

Enrico