New post
AllAccepted answers
Stefan Schick · Jun 13

Hi Jeffrey,

thanks for checking! Glad to see that this might be fixed with our next update!

The cause of the problem appears to lie in the computed fields of the table, the macros used might not work in a different table/class. Other computed fields ("Name", "Identifier", "TypeVersion") don't work either.

Meanwhile I found a workaround:

Instead of using the computed field "Name" it's contents can be computed explicitely. It's not 100% the same, because some details, eg taking into accout the separator characters, are missing but it works for me!

CREATE TABLE UKEr.Test AS
SELECT REPLACE($EXTRACT($PIECE(m.RawContent,'|',9),1,7),'^','_') Name, h.Status
FROM EnsLib_HL7.Message m, Ens.MessageHeader h
WHERE h.MessageBodyClassName='EnsLib.HL7.Message' AND h.MessageBodyID = m.ID

Regards
Stefan

Stefan Schick · Jul 28, 2022

Hello Alexey,

thanks for pointing back to the manual! After re-reading this section I found the crucial sentence:

^JRNRESTO restores only to databases whose journal state is Yes at the time of the journal restore.

So, if journaling at database level is set to "no", no journal restore will be performed!

And as you said:  ^JRNRESTO itself provides an option to disable journaling - at the far end of the configuration process.

This might be the answer(s) to my initial question.

Stefan Schick · Jul 21, 2022

Hello Alexey,

Which manual does it say?  

I'm referring to this section of the manual: Restore Journal Files

It seems that you should not bother on the subject at all: during the database restore it can't be involved in any users' activity, so there would not exist any journal record on its change.

OK: to be safe there should be no activity (all productions stopped) on the entire instance during the restore process, even if only one database is affected.

Regards 
Stefan

Stefan Schick · Mar 29, 2022

Hi Scott,

when you send a message in synchronous mode (= wait for the response) to a routing engine,

either by not specifing Asynchronous In the call element of a graphic business process:

or programmatically: 
Set tSc = ..SendRequestSync(tTarget, tMsg)

There are several possibilities how/what the routing engine can respond (see help for Response From):

* means: return the first response the router has received to the sender

If you leave this field empty a "NULL" message will be returned.

Hope this will clarify it a bit.

Regards 
Stefan

Stefan Schick · Mar 25, 2022

Hi Scott,

we had a similar problem with orphaned response messages. They were shown in the visual message trace as type "NULL" instead of request or respose and the MessageBodyClassName in Ens.MessageHeader was empty.

We found two reasons for that:

1. business processes or operations where the pResponse parameter of the OnMessage() method was never used, e.g.

 Method OnMessage(pRequest As Ens.Request, Output pResponse As Ens.Response) As %Status

The fix was to add a line of code to instanciate the object:

 Set pResponse = ##class(Ens.Response).%New()

2. Routing rules that are called synchronous respond with a "NULL" message when the Response From parameter is empty.

The fix was to set the Response From parameter e.g. to "*" - the first response received will be the one returned
 

Regards
Stefan

Stefan Schick · Mar 25, 2022

Hi Scott,

1. I would stay away from Modifying the current EnsLib.HL7.SearchTable if at all necessary. Modifying the source code could lead to consequences down the road, especially when you upgrade it might get overwritten.  

Thanks for your answer!

First: we did not modify EnsLib.HL7.SearchTable directly, our searchtable class is a subclass of this class.

But defining a new searchtable as you suggest seems to make sense. On the other hand all config items using the "old" searchtable must be modified.

Regards

Stefan