[Don Martin]

I’m not sure how you copied your message so I can say for sure, but it looks like the DRVCTL metadata didn’t get copied form the original reply message to the new copy of the message, so you’re missing your DTC context.  We use DTC threads a lot, and whenever we copy a message, which is a lot in DTC threads because you need to take replies and change them them to data messages, we do these two additional steps:

set drvctl [msgmetaget $replyMessageHandle DRIVERCTL]

# DTC needs the DRIVERCTL from the copied message
msgmetaset $dataMessageHandleCopy DRIVERCTL $drvctl

The entire snipped to copy a DTC reply and CONTINUE the data message looks like this:

# Reply messages need to be copied to data messages in DTC flow; data message is sent on in the DTC flow.
set mhData [msgcreate -type data [msgget $mh] ]
# DTC needs the DRIVERCTL from the copied message
msgmetaset $mhData DRIVERCTL $drvctl
# set the code for messages with length > 6 to DONE, else QUIT the message
set message [msgget $mhData]
if { [some condition used to determine next state } {
set xCode SOME_STATE
} else {
set xCode DONE

}
lappend dispList “DTCNEXT {{$mhData $xCode}}”
# Kill the reply message prevent leaked memory/handle
lappend dispList “KILL $mh”

[Don Martin]

Hi Lonnie,

Maybe you’ve already figured this out, but if not, hopefully the following info can be helpful.

We use a custom TCL proc in the Inbound Replies panel of the Outbound tab of the ws client thread.  We set Await replies to yes, and plug the custom TCL proc into the TPS Inbound Reply field.  Here’s an example of a proc that retries sending the message before ultimately sending the reply and original outbound message to the error DB.

#************************************************************************#
# Name: HTTP_Validate_Response
# Purpose: Verifies the response from a web service call,
# checking for a good http response code. If an error code is returned,
# this proc will retry $maxRetries number of times.
# After $maxRetries number of attempts, if an error code is still being
# returned, both the response message and the original outbound message triggering the
# error code are written to the error database.
#
# UPoC type: tps
# Args: tps keyedlist containing the following keys:
# MODE run mode (“start”, “run”, “time” or “shutdown”)
# MSGID message handle
# CONTEXT tps caller context
# ARGS user-supplied arguments:
#
# Returns: tps disposition list.
#
#
#************************************************************************#
proc HTTP_Validate_Response { args } {

global HciConnName sendCount maxRetries
keylget args MODE mode
set ctx “” ; keylget args CONTEXT ctx
set uargs {} ; keylget args ARGS uargs
set debug 0
catch {keylget uargs DEBUG debug}
set module “HTTP_Validate_Response/$HciConnName/$ctx”
set dispList {}

switch -exact — $mode {
start {
set maxRetries 1 ;# set the max number of retries.
set sendCount 0 ;# Init resend counter
return “”
}

run {

keylget args MSGID mh
keylget args OBMSGID obmh

# get the USERDATA from the response msg
set udata [msgmetaget $mh USERDATA]
set errorFlag 0

# get the HTTP response code.
if [catch {set httpRespCode [keylget udata httpResponseCode]}] {
puts “$module: No http response code in USERDATA object.”
set errorFlag 1
} else {
# check for success (status code 100-299)
if {($httpRespCode >= 100) && ($httpRespCode <= 299)} {
# Valid reponse code.
puts “$module: Valid RESPONSE CODE received in reply: $httpRespCode”
set errorFlag 0
} else {
# bad response code, send to error db
puts “$module: Bad http response code: $httpRespCode”
set errorFlag 1
}
}

if $errorFlag {
if {$sendCount >= $maxRetries } {
set sendCount 0
puts “$module: Max retries attempted. Outbound message and reply will be written to error DB!”
keylset udata FAILED_RETRY_ATTEMPTS “$module: OB Message Rejected after $maxRetries retries”
msgmetaset $obmh USERDATA $udata
set dispList “{ERROR $obmh} {ERROR $mh}”
} else {
incr sendCount
puts “$module: Resending outbound message with PROTO disposition, [expr $maxRetries – $sendCount + 1] retry attempt(s) remaining.”
after 2000 ;# wait 2 seconds before retrying the request.
set dispList “{PROTO $obmh} {KILLREPLY $mh}”
}
} else {
set sendCount 0
puts “$module: Reply message is being CONTINUEd.”
set dispList “{CONTINUE $mh}”
}
}

time {}
shutdown {}
default {
error “Unknown mode ‘$mode’ in HTTP_Validate_Response.”
}
}

return $dispList

}

[Don Martin]

As far as the API not using any certificate, that’s interesting.  Are you sure they require you to connect with https/SSL?  Have you tried calling to http://theAPI instead of https://theAPI?

I can’t imagine their API endpoint is going to work via https on a rawclient thread if they don’t have a cert installed.

[Don Martin]

What SSL configuration is set up in you http-client thread?  I believe it is possible to have these threads skip server authentication based on the properties you set on the thread, which might explain why you can post info to this API.

You mentioned this is an internal API… wondering if they are using a self-signed cert that your rawclient thread won’t trust unless you add it to the configuration of your conduit?

 

[Don Martin]

Your token should be retrievable from the USERDATA keyed list.  It looks like you’re getting this keyed list back:

userdata = {httpResponseInfo OK} {httpResponseHeaders {{Keep-Alive timeout=75} {transfer-encoding chunked} {Server {}} {X-Backside-Transport OK\ OK,FAIL\ FAIL} {connection keep-alive} {content-type application/soap+xml\;} {X-Global-Transaction-ID 23056659630fbec8165abce1} {Date Wed,\ 31\ Aug\ 2022\ 20:04:24\ GMT} {token eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJEUFY2MDEiLCJleHAiOjE2NjE5NzY1NjQuNzIsImF0b21pY3JvbGVfbW9kdWxlIjoiNDQzL0hIUy9BUEkvc2VydmljZS9ITDcvU3luZHJvbWljIiwiY2xpZW50X2lkIjoiVFVGVFNNRURDRVJUIn0.VQK2YD1zkCAConfjaXxnbTr3NwY-5GvVM8aanDMuHoCbm6KJcyORditQgA7edpEVawwMEh7TXEzxPvswmY3khYJX8Oh9Yh0aGjwSyuV2woBJNypv60saYv9YjNhdh2wAEZrD-myV9qTN4UVj-woNtj8Cr-eEHwDvW7DQgPjoMcc_jSkYI5-RteDubjqSs0HBrCT1fttDeIzHrQ5mO8gukUiXaleQhXu3Sc87eXO_OEvYD2rDMpDXQ4GwViSnukVL_-YLD3pCo_vfBkm-RLTbQfbrlNsV9tJ6mGqQzTQfhp-oByZ1dy5SkdXMBvzQ0M7ftCGuM_Z-wwZ-WjnEQsfgBQ}}} {httpResponseCode 200}

 

This matches what the clover docs says about the format of USERDATA for web service calls.  Here’s an example of the USERDATA keyed list for an outbound ws call:

{httpRequestHeaders {{Accept */*} {Cache-Control no-cache} {connection keep-alive} {Content-Length 1392} {content-type {application/soap+xml; charset=UTF-8}} {Host localhost:9003} {Pragma no-cache} {User-Agent {Apache CXF 2.4.2}}}} {httpRequestInfo {{method POST} {requestURL http://localhost:9003/xdsregistryb} {path /xdsregistryb}}}

So, to get the token in your ib reply, you would first get the USERDATA keyed list, then get the httpResponseHeaders keyed list, then get the token.  You can’t use keylget to directly get token without first working your way into the nested list.

 

Also, I see you have an error about no reply route defined for your ws call.  Not sure if that is just a benign issue for you or not.  We typically set up a reply route and extract the access token with some tcl code in the reply route.

 

[Don Martin]

Thanks Jeff.  Again, appreciate the info.  We’ll add to this once we get an upgraded version installed.  At this point we’re looking at trying to upgrade sometime around a month from now.

Don Martin

Sanford Health

[Don Martin]

Hi Jeff,

Thanks for the post on the PDF issues you’re experiencing.  We’re about to migrate from 6.2 to 20.1.1.3 on AIX, and we handle a lot of PDFs in a similar fashion to what you describe.  Currently we use PROTOCOL:pdl-tcpip PDL: mlp2_tcp.pdl and often send these messages across different sites.  We’ve will have occasional issues with being unable to allocate memory, especially for for PDFs larger than 40 MB in size, but overall we’re able to process PDFs without too many issues.

I’m very interested in hearing more about Infor’s resolution for this PDF issue, and how their solution is working for you.  We’ll add updates once we get 20.1.1.3 installed on a test server, and hope you’ll continue to do the same!

Thanks again,

Don Martin

Sanford Health

[Don Martin]

Using a rawclient to make an HTTP GET call would typically be used on an outbound thread, and need to be triggered by some sort of message.  If you want the HTTP GET call to be the start of some type of flow, you could use a UPOC timer as the inbound thread to initiate the flow and route some sort of dummy message to the outbound rawclient thread.  Make sure you have message logging turned on in the rawclient bus so you can see the outgoing call and incoming response in the logs.

[Don Martin]

For some reason, we seem to inherit these JVM Options in any new {{java protocol process}}.pni file on our cloverleaf site.  I’m not sure how that happened… maybe someone set it up in the Cloverleaf configuration before I got here.  I’m also not aware of any list of JVM Options to use in the process configuration, but maybe others on this forum will have some input.

Glad this worked for you!

[Don Martin]

If you add some or all of the following to the Additional JVM Options in the Java Driver tab of the process configuration, you should be able to see SSL handshake logging in your process log file.
<p style=”margin: 0in; font-family: Calibri; font-size: 11.0pt;”>-Djavax.net.debug=all -Djdk.tls.client.protocols= -Dhttps.protocols=TLSv1.2,TLSv1.1 -Ddeployment.security.SSLv2Hello=false -Ddeployment.security.SSLv3=false -Ddeployment.security.TLSv1=false -Ddeployment.security.TLSv1.1=true -Ddeployment.security.TLSv1.2=true</p>

[Don Martin]

Thanks Rob, appreciate the quick reply!

Don

[Don Martin]

Here is how we use the staging DB in a DTC flow:
keylget args MSGID mh
stagesetmsg $keyspace messageHandle $mh

keyspace is typically set to the something like DTC_{{transactionId}} You can get the transaction ID from from the message metadata under DRIVERCTL > DTCCTX > XID

Then we retrieve the message handle like this:
set mh [stagegetmsg $keyspace messageHandle]

If that doesn’t work, try posting your code to the forum.

Here are a couple of other things about DTC that I have seemed to notice. Maybe others don’t agree, or I’m overlooking something, but I’ll put it out there as it might be helpful.

Every time the DTC thread is saved, if a raw reply route doesn’t already exist for any threads that are being used with the DTCSEND disposition, a new raw route is created. That’s fine if you only intend to use raw reply routes for the replies sent back to the DTC thread, but if you are using an xlate reply route, this will cause a problem – you’ll need to manually delete the raw reply route from each thread using an xlate reply route every time you save changes to the DTC thread.

The staging DB API for stagegetkeys doesn’t work – doesn’t seem to exist in cloverleaf, however, stageremovekeyspace does work.

We typically enclose all of our .tcl code in a catch statement to handle looping issue/bug in DTC if thread is stopped during a transaction.

We try not use two DTC threads in the same flow or same process. We were getting some strange timing issues/race conditions when we did this. I can’t say for sure that it was due to DTC.

 

Hope that helps.

Don Martin

Sanford Health

[Don Martin]

Do you have the Message Logging Enabled check box selected in the java/ws-server properties?  This gives a nice clean way to read inbound and outbound http messages in the process log file.  Also, at least on the version we run, java/ws-server only receives xml in the message body.  Message bodies not wrapped in xml tags will error out.

[Don Martin]

Sounds like this isn’t what you’re looking for, but I’ll add it in case it helps others.

package require shmc_email

set subject “email subject”
set message “An error occured when trying to send some data…”
set email “me@someDomain.org”
if [catch {shmc_email::email $email $subject $message} err] {
puts “Error Calling SHMC_Email in $module — $err”
}

[Don Martin]

Thanks!  Found it.

[Author]

Replies