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.

I tried the URL and when I went to test the connection I got an error about "authenticationScheme=NTLM" being invalid. Once I removed attribute, I am now getting "Driver can not be loaded" at least from the Management Portal. If I try it manually via Terminal to test connection it fails with a -1. When I look at the JDBC Gateway log I am seeing the following..

.%Net.Remote.Gateway..%WriteOutput.....May 16, 2023 1:48:05 PM com.microsoft.sqlserver.jdbc.AuthenticationJNI <clinit>.WARNING: Failed to load the sqljdbc_auth.dll cause : no sqljdbc_auth in java.library.path.
 

  • Driver name: com.microsoft.sqlserver.jdbc.SQLServerDriver
  • URL: jdbc:sqlserver://CPDDB.osumc.edu:1739;database=CPD;trustServerCertificate=true;integratedSecurity=true;domain=osumc;authentication=NotSpecified
  • Class path: 
     

We were using a Local Windows Authentication account with a Hardcoded user name and password for our jobs to connect to MS SQL for the longest time, but it was frowned upon as everyone knew the user and password to sign into the database. So we were asked to make a Service Account on the Domain through Active Directory. In our AIX/Linux world we had not use Active Directory authentication so it became an issue to try to figure out how to make it work. That's when I discovered jTDS. I am going to try what @Jeff Morgan pointed out below to see if I can make it work as I could never find the correct connection string to make the Microsoft Driver to work for us.

We are using the  jTDS (jtds-1.3.1.jar) driver because we are using Domain Service Accounts to access the databases. We are doing this because I could not get the Microsoft JDBC drivers to authenticate properly using the Domain Service Accounts in Active Directory being on Unix/Linux. 

:>java -version
openjdk version "1.8.0_362"
OpenJDK Runtime Environment (build 1.8.0_362-b09)
OpenJDK 64-Bit Server VM (build 25.362-b09, mixed mode)