Netanel Frankel

Hi Michel,

Are you using DICOM interfaces?

I believe the proper way to do this is not by editing the Production class XData, but rather by using the icon/button you can see in the image above, with the small light-blue arrow:

When hovering over this icon you can see the text: "Select settings defaults".

See details of how to use this here from the Docs.

In your case you would there check the checkbox fro the "try" setting, press the "Restore Defaults" button on the bottom of the dialog, and then press Apply on the Settings tab.

If, as you mention the purpose of this logging is debugging, then I would recommend going with $$$TRACE vs. $$$LOGINFO. This will allow you to turn on and off tracing without making code changes. Whereas if you go with $$$LOGINFO it's always there unless you remove it (or comment it out), then you need to compile, and then if you need it once more...

See also this related article.

Regarding your question on the *.impl generated class -

if you already added code to this class and later update the swagger and consume it again - indeed the code you added will remain.

If you review the video recording of the Global Summit Solution Developer Conference session I mentioned above - you can see a live demonstration of this specific case. [I recommend you see all of it, but this particular part starts at about 33:30]

Looks great David! 

I think for the "background" part this Global Summit presentation - "API Design for REST" (by @Michael Smart) could be helpful.

See also using the ^SECURITY utility (for manual export vs. programmatic which is possible via the Security package classes API).

For example:

 
%SYS>do ^SECURITY
 
 
1) User setup
2) Role setup
3) Service setup
4) Resource setup
5) Application setup
6) Auditing setup
7) Domain setup
8) SSL configuration setup
9) Mobile phone service provider setup
10) OpenAM Identity Services setup
11) Encryption key setup
12) System parameter setup
13) X509 User setup
15) Exit
 
Option? 2
 
1) Create role
2) Edit role
3) List roles
4) Detailed list roles
5) Delete role
6) Export roles
7) Import roles
8) Exit
 
Option? 6
 
Export which roles? * =>

If I understood the question correctly I think there might be some confusion...

Indeed internally Ensemble stores the Message Header times (TimeCreated & TimeProcessed) in a UTC time (per the considerations Robert mentioned) but when these times are displayed in the Message Viewer they go through conversion and are displayed in local time.

So if you would open the object via code, or run an SQL query directly, you would be dependent on running the relevant LogicalToDisplay() or LogicalToOdbc() methods for objects, or using the ODBC or Display runtime modes, but on the default Message Viewer web page these times should appear local.

You can examine this by doing a simple select on the Message Header table and you can see the difference between the Logical and Display modes.

For example, for a certain message, the Logical (internal UTC) time is 10:42 -

And now the same time using Display mode, the time is 13:42 -

And compare this with what you see in the Message Viewer, you see 13:42 -

and -

Note if you take a look at the Ens.DataType.UTC data-type class you can see it's conversion methods.

For example the LogicalToDisplay() method.

Here's an example of what it looks like when it's code runs.

In the following code I show my current local time (using $H, taking into account Time Zone and Daylight Saving), then I show the current general time (using $ZTS, per GMT and no Daylight Saving), and then applying the code run by the method, calling the method, and explicitly.

TEST>set currentLocalTime = $ZDateTime($Horolog,3,,3) 

TEST>set currentGeneralTime = $ZDateTime($ZTimeStamp,3,,3) 

TEST>write currentLocalTime
2018-09-20 10:46:07.000 

TEST>write currentGeneralTime 
2018-09-20 07:46:15.107 

TEST>write $zdatetime($zdTH($zdatetimeh(currentGeneralTime,3,,,,,,,,0),-3),3,,3) 
2018-09-20 10:46:15.107 

TEST>write ##class(Ens.DataType.UTC).LogicalToDisplay(currentGeneralTime) 
2018-09-20 10:46:15.107

See the -3 argument in the $ZDTH function call, from the docs this does the following -

$ZDATETIMEH takes a datetime value specified in $ZTIMESTAMP internal format, converts that value from UTC Universal time to local time, and returns the resulting value in the same internal format

Hi Dmitry,

Recommending your very cool and useful utility to someone I realized I did not find installation instructions, not here in this article, nor in the GitHub readme.

Could you please point me to them, or in case they indeed do not exist currently can you please provide them, for the benefit not only of the person I'm sharing this with, but with other Community members who will want to use this in the future. 

Tx!

What is the class name of your Web Service?

Is it also a Business Service? If so - what is the name of the BS component in the Production?

What URL are you using to access this WebService?

I have encountered this error when trying to call the WebService in a way that did not allow Ensemble to understand what is the name of the business service class it needs to use (for example by using the CfgItem URL parameter).