This is a really interesting approach to try enable the ability to view the content of the https request being made, but it is worth noting that mitmproxy routinely triggers antivirus software, and therefore might not be a viable option for many.

I instead had to opt for throwing together a quick and dirty nodeJS app to get eyes on the output of the EnsLib.HL7.Operation.HTTPOperation to understand why I was hitting a snag with a supplier. Turns out the content-type from this operation is text/html and the supplier was expecting  text/plain...

Well, this has got me ordering the hardware already!

I can't wait to get my hands on the repo, and look forward to the inevitable battle with our security team (which, to be fair, would be within their rights to be concerned).

Hey Nezla, if you are looking to interact with an internal table, then using the outbound adapter for SQL is not what will work for you. This is because the adapter relies on the servers ODBC config to look for the specified table in the external database based on the DSN you've configured. 

You will instead want to swap your ObjectScript to something like:

Set tStatement = ##class(%SQL.Statement).%New()
Set tQuery = "SELECT * From Ens_Util.LookupTable WHERE TableName ='"_tTable_"'"
$$$THROWONERROR(tSC,tStatement.%Prepare(tQuery))

Set tResult = tStatement.%Execute()

While tResult.%Next(){

	//Do what you need to with the results here

	$$$TRACE("Result: "_tResult.KeyName_", "_tResult.DataValue)

}

Then, if you still need to also query for something in the external database based on the DSN configured, then you can interact with the external database using the ..Adapter.ExecuteQuery approach you had attempted.

Hey Gigi.

In the past I have had to create a custom HL7 HTTP Operation that heavily relies on the code used by the built in Operation. Doing so comes with some risk risk, but in my use case it was required (the response could only be read using %Parser.ParseIOStream and not %Parser.ParseFramedIOStream). My change was effectively a copy of the SendMessage Method, with a single line changed.

In your case, I think you will want to do similar, but instead I think the following will need to be your approach:

1. Create a new Operation that copies EnsLib.HL7.Operation.HTTPOperation.
2. Add in a new Method that follows the format of what the bot has shared for the Method "AuthorizeMe", but tweaked to reference the client setup for OAuth2 
3. At the start of the existing Method "SendMessage", as a line at the start that calls the "AuthorizeMe" Method. Something like:
   1. $$$QuitOnError(..AuthorizeMe())
4. Add a new line prior to the line that makes the HTTP Request which adds in the authorisation header. Something like:
   1. Set tSC = tHttpRequest.SetHeader("Authorization","Bearer "_AccessToken)

This should hopefully add in the OAuth2 bearer token to the Http request as you need.

You will still need to configure your instance to be able to generate the OAuth token to be able to then make use of this.

If this is your first time working with OAuth2 in IRIS, I would start with making sure you are able to set this up and generate a token. Once configured within the management portal, you can try testing this by manually running the calls being made in the "AuthorizeMe" method and seeing if you get a valid token back (or add it to an adhoc classmethod so you can call that on each test instead of needing to manually run the required lines).

What's the reason for not using the EnsLib.HL7 classes for your Ensemble interface?

The utility of Find In Files from Studio is one that is badly missed in VSCode, so I'm glad to see something in this space.

Is there an official recommendation from InterSystems regarding disabling content indexing for drives hosting database files (.dat), journals, and WIJ?

I'm fairly sure that the search indexing is disabled by default on Windows Server, so there's a good chance that it's not something that comes up frequently enough to make it into documentation as an official position.

However it does make sense to disable it for specific locations such as the location of the database and journals etc if you have indexing turned on for the server as a whole.

Depending on the issue I'm seeing, I tend to rely on these two links to help pin down the issue:

• https://www.i18nqa.com/debug/utf8-debug.html
  • For example with this, I would check to see if character like "Ñ" is as expected, or if it is changing to "Ñ" 

• https://www.i18nqa.com/debug/bug-iso8859-1-vs-windows-1252.html
  • For this example, I try passing the following either from the source system into the integration engine, or from the integration engine into the target system, and then make sure it worked as expected:

€‚ƒ„…†‡ˆ‰Š‹ŒŽ‘’“”•–—˜™š›œžŸ.

Hey Malaya.

If you're not already getting the status code of 5 for successfully frozen and 3 for failure, then there is ##Class(Backup.General).IsWDSuspendedExt() that can be called to see if the Write Daemon is suspended, which follows that same output of either 5 or 3 depending on it's status.

Hey John.

I'm happy to be corrected, but I didn't think that the Arbiter utilised TLS and that the minimal traffic between the mirror and the arbiter was rather lacking in any information about the environments that are being managed by the arbiter.

That said, it would make sense for it to move to using TLS even just for completeness.

How to get InterSystems IRIS Community Edition | InterSystems DC

I did post an example last year of how I traditionally would use #DIM, and it was (rightly) pointed out that the scenario was no longer required due to how VSCode behaves these days (well, the Language Server extension used in VSCode).

However today I have found a more common example where #DIM seems to be needed for code completion, based around using Business Services/Processes within an Interoperability Production.

Class Some.Business.Process Extends Ens.BusinessProcess
{

Property OnwardTarget As Ens.DataType.ConfigName;

Parameter SETTINGS = "OnwardTarget";

Method OnRequest(pRequest As Ens.Request, Output pResponse As Ens.Response) As %Status
{
    //Some code above
	
	Set someReqMsg = ##Class(Some.Req.Msg).%New()
	Set someReqMsg.abc = "123"
	Set tSC = ..SendRequestSync(..OnwardTarget,someReqMsg,.someRespMsg)
	#; No autocomplete on someRespMsg.xyz without #dim before ..SendRequestSync
	
	//Some code below
	
	Quit $$$OK
}

}

  Without the #dim in the above, there is no context for the IDE to know what someRespMsg returned from the ..SendRequestSync() call will be.

That said, its use is certainly dwindling compared to pre-VSCode times and it's continued usage can be more from habit than necessity a lot of times (I'm certainly guilty of this).