@Ashok Kumar 
So, I tried...

 set tSC = ..Adapter.SendFormDataArray(.tHTTPResposne,"POST",tHTTPRequest,,,tURL)
 set pResponse = ##class(User.REST.Epic.Msg.GetPatientLocationResponse).%New()
 set dynObject = {}.%FromJSON(tHTTPResposne.Data)
 do pResponse.%JSONImport(dynObject)
 
and tried..
set tSC = ..Adapter.SendFormDataArray(.tHTTPResposne,"POST",tHTTPRequest,,,tURL)
set pResponse = ##class(User.REST.Epic.Msg.GetPatientLocationResponse).%New()
do pResponse.%JSONImport(tHTTPResposne.Data)
But within the trace viewer GetPatientLocationResponse comes up blank

Not sure I follow... I do all the SetHeader lines, then call  Do tHTTPRequest.EntityBody.Write() is that not writting the headers to tHTTPRequest?

    do tHTTPRequest.EntityBody.Write()
    do tHTTPRequest.OutputHeaders()
    set tURL= "/../../../../"  //..Adapter.URL
    set jsonRequest = {"........."}
    SET tSC = tHTTPRequest.EntityBody.Write(jsonRequest.%ToJSON())
    set tHTTPResposne = ##class(%Net.HttpResponse).%New()
    do tHTTPRequest.OutputParams()
    set tSC = ..Adapter.SendFormDataArray(.tHTTPResposne,"POST",,,tHTTPRequest)

The issue was with the code that I was using in my Business Operation that was not calling the SSL Configuration. I have since reverted my Business Operation code back to the more standard code that is described in the Documentation, however I am still running into issues making sure the correct format of the Header is being sent in the REST API call, and how to interpret the JSON that is being returned by the REST API.

According to WRC there is a memory leak with the way the Class Path of the driver is being handled. The reason for this issue was that I had the Class Path defined within the SQL Gateway. I thought this was only due to the jTDS driver we were using, but it is an overall issue with any Java Gateway Service. So I updated the Java Gateway service I was using for the Microsoft JDBC Connection for that Database to now have the Class Path of the driver, and I have not seen issues since.

I have tried that but still unable to see the Request or Response being sent...

Class User.REST.Epic.EpicOperation Extends (EnsLib.REST.Operation, Ens.Util.JSON)

{

Parameter DEBUG As %Integer = 2;

Parameter INVOCATION = "Queue";

Method getPatientLocationRequest(pRequest As User.REST.Epic.Msg.GetPatientLocationRequest, Output pResponse As EnsLib.HTTP.GenericMessage) As %Status

{

    set tSC = $$$OK

    try{

      set tHTTPRequest = ##class(%Net.HttpRequest).%New()

      do tHTTPRequest.SetHeader("Epic-Client-ID","ed7ca30e-c16a-4053-9233-bff4f5661bb4")

      $$$TRACE("HttpRequest: "_tHTTPRequest) <this returns me just a pointer 8@%Net.HttpRequest>

      set tRequest = ##class(%DynamicObject).%New()

      set tRequest.PatientID = pRequest.PatientID

      set tRequest.PatientIDType = pRequest.PatientIDType

      set tRequest.ContactID = pRequest.ContactID

      set tRequest.ContactIDType = pRequest.ContactIDType

      set tRequest.UserID = pRequest.UserID

      set tRequest.UserIDType = pRequest.UserIDType

      set reqMsg = tHTTPRequest.EntityBody.Write(tRequest)

      $$$TRACE("reqMsg: "_reqMsg)

      set tSC = tHTTPRequest.EntityBody.Write(tRequest.%ToJSON())

      set tURL = ..Adapter.URL

      set tSC = ..Adapter.Post(tURL)

      set stream = "".....

For others I figured out the issue. Had to use the Base64 formatted Certificate Chain (p7b) from Windows ADCS (Active Directory Certificate Service).

  1. Download Base64 p7b to /etc/pki/ca-trust/source/anchors/ in RedHat
  2. Change ownership group to include irisusr
  3. Change permissions to Read (666)
  4. Convert p7b to pem
  • sudo openssl pkcs7 -in xxxxx.p7b -print_certs -out xxxxx.pem

When I went through testing the request I got the following...

DEVCLIN>set request=##class(%Net.HttpRequest).%New()

DEVCLIN>set request.Server = "xxxxxxxxxxxx"

DEVCLIN>set request.Port=443

DEVCLIN>set request.SSLConfiguration="OSUWMC"

DEVCLIN>set request.Https=1

DEVCLIN>set tSC=request.Get("/",2)
HTTP/1.1 200 OK
ACCEPT-RANGES: bytes
CACHE-CONTROL: private
CONTENT-ENCODING: gzip
CONTENT-LENGTH: 467
CONTENT-TYPE: text/html
DATE: Thu, 20 Jul 2023 20:08:54 GMT
ETAG: "b072b0f23afdd01:0"
LAST-MODIFIED: Fri, 02 Oct 2015 17:51:21 GMT
NTCOENT-LENGTH: 701
SERVER: Microsoft-IIS/8.5
X-POWERED-BY: ASP.NET

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>IIS Windows Server</title>
<style type="text/css">
<!--
body {
        color:#000000;
        background-color:#0072C6;
        margin:0;
}

#container {
        margin-left:auto;
        margin-right:auto;
        text-align:center;
        }

a img {
        border:none;
}

-->
</style>
</head>
<body>
<div id="container">
<a href="http://go.microsoft.com/fwlink/?linkid=66138&amp;clcid=0x409"><img src="iis-85.png" alt="IIS" width="960" height="600" /></a>
</div>
</body>
</html
>

I am not sure I understand... I was using the example that was provided in the documentation.

https://docs.intersystems.com/healthconnectlatest/csp/docbook/DocBook.UI.Page.cls?KEY=EREST_operation#EREST_operation_json

If I have to have a Custom Header do I not have to define in this case the Client ID as part of the %DynamicObject?

    set tRequest = ##class(%DynamicAbstractObject).%New()

    set tRequest.clientID = "Epic-Client-ID = xxxxxxxx"

if I am using a Request Class Structure (osuwmc.Epic.Access.Request.GetPatientLocationByVisit2JsonRequest) isn't the set tRequest.payload = pRequest line correct?

Thanks, we tried taking an existing connection that was using the Local Interface Address of the VIP (ens192:1) and tracing it through the firewall to see what IP address it was associated with.

When we changed the port on the existing connection even though the Local Interface was set to the VIP, it started to send the other IP address assocated with ens192.

But if we changed the port back to the original port with the Local Interface set to the VIP it reverted back to sending the VIP in the packet header. 

I am questioning if we truly stop/started the object after making the change, but that is here nor there. 

I did open a ticket with WRC to get more information on how to troubleshoot the Local Interface setting, and the TCP Adapters definitions.

Lookup tables are useful for 1 to 1 mapping that may need to change based on the system you are sending too. They are also helpful in filtering data. In many cases we use Lookup tables to filter down the data based on location or etc. from going to the endpoint system. In those cases, we have actually given those system users access to their own tables to maintain them without Integration's involvement.