[Ken Smith]

As I look at it again, it appears the inbound db thread simply doesn’t accept an inbound message so barking up the wrong tree. The outbound db thread does

[Ken Smith]

Thanks but the problem is not getting fields/columns from the table but getting the db thread to accept a parameter that feeds into the WHERE clause. I want to filter on patient and can’t get the thread to run that query.

I did think about the db lookup table, but I will receive a variable number of rows which would return, I think, as a list into the outbound message. With the data I am hoping to return, the list would be extremely awkward.

[Ken Smith]

I take your point and it seems generally like a better approach. But in this case, the full URL with parameter worked if there was no authentication, and the authentication failed if it was provided. It seems to me that the full url wasn’t an issue until basic authentication was applied. So the question I’m wondering about is why does the authentication fail with the full URL?

[Ken Smith]

The interfaces and the API are very much part and parcel of the same project. Yes, they did very specifically asked if I could connect with https. Calling the API with http definitely works with basic user/pwd authentication. Adding the https was either gilding the lily or belt-and-braces, depending upon how you look at it.

I was of a similar mind, that https was never going to work on a rawclient without a cert. The failure of https w/o the cert was what I was expecting. I did want however to see if there was anything I’d overlooked. Thanks for your response, much appreciated.

[Ken Smith]

Thank you for that thought, it is very helpful.

The http-client allows a setting for anonymous mode when selecting https (with SSL protocol defaulted to All), and with no settings for certificate. I didn’t really notice it at the time as it was the default.

The java/ws-rawclient doesn’t seem to allow this same configuration, i.e., anonymous mode, or at least I can’t see how to enable it in the config options.

As regards the internal API, it is not using any certificate.

[Ken Smith]

The POST is being used to send data into a db via the API. The GET is being used to retrieve data from the db via the API.

I am able to use the http-client thread because the data is formatted in xml, which that thread handles gracefully. It doesn’t handle JSON at all.

As the data is supplied outbound (i.e., via GET) in JSON format, I can’t used the http-client but have to use the raw client instead.

[Ken Smith]

Thanks very much for your excellent advice. I had about reached the conclusion from examples and experiments that the rawclient would only work as the outbound thread, but couldn’t quite figure the rest.

[Ken Smith]

I’m not exactly sure in this context. The GET is called on the first thread in the process, the result message should get written to/passed to a second (file) thread. So in that sense it may be inbound. I’ve attached a screenshot.

Attachments:

You must be logged in to view attached files.

[Ken Smith]

Thanks, that works exactly as described. I had a faint recollection of being able to do what you describe but couldn’t find the right thread to grasp. Thanks very much.

[Ken Smith]

Just to round this off, I then had to pass the oauth / bearer token to the next endpoint, in this case an endpoint that used data in the message to update the database. I had to do this in fact for two different projects and the configuration was slightly different in each case. In both cases, I first extracted the token from the response message and stored it in a variable called “token”.

The basic approach is to set an authorization header and provide the token as the value, accounting for other headers also required, e.g.:

$ch configure -httpheader [ list “Content-Type: application/json” “Authorization: $token”]

(in this case, $ch is the handle to a curl session – see above responses/comments)

One site required the header to be interpreted as “Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9”

The other site required the header to be interpreted as:

“Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9”

So you’ll have to take the specifics of endpoint into account and set the token accordingly.

For me, the most obvious way to make this all is to put the call to the authorization endpoint and the call to any subsequent endpoint in a single tclscript. First you get the token, then you call an endpoint with the token. I’m sure those who have more experience with this have sounder methods, but this being the first time I’ve had to do things this way…

I found a related thread that recommended calling the tcl in the routing from Thread A to Thread B. This works for me. As the message is being logged along the way, and the tcl script is doing the sending, I am using a simple file thread for the destination. I have left the file settings blank, default behaviour with no output file defined is to simply throw the message away. However, you could try setting a file destination if you still want to log or archive the message.

Those who’ve done this more than me – this is the first set of projects where I’ve had to take this route – will no doubt have better ideas.

 

[Ken Smith]

Update: I have finally got this to work, the issue, to my mind, was pretty arcane, but maybe I should have seen it coming. I copied code from various responses/issues described, which copied into my Cloverleaf with quotation marks of the type “”, e.g., “Content-Type: $typ”]

However, I noticed, finally, in the script editor that quotation marks of “” were clearly preferred. I changed all of the quotation marks to “” from  “” , e.g. “Content-Type: $typ”, and the script executed properly.

Quotation marks, who knew? Well, probably I should have…

[Ken Smith]

While that works without error, I don’t get back the authentication token meant to be returned by the service. Browse output shows:

[tcl :out :INFO/0: fetchToken:03/12/2020 10:24:16] returnCode: 1
[tcl :out :INFO/0: fetchToken:03/12/2020 10:24:16] httpResponse: 0
[tcl :out :INFO/0: fetchToken:03/12/2020 10:24:16] oauth return message is:

I’m not seeing and perhaps not getting back the token, which will be a ridiculously long string of gibberish.

The call from the command line returns a token of the nature “A1L2lkZW50aXR5L2NsYWltcy9uYW1laWRlbnRpZmllciI6” (that’s not the full token but you get the idea).

[Ken Smith]

Thanks for your response. I’ve been working across the boundaries between Cloverleaf 6.2 and Cloverleaf 19.1, as we prepare to switch over to the latter. I’d been working initially with HL7 to VRL (comma delimited fields) and couldn’t get commas to work. When I was finally able to switch over to a proper JSON schema in Cloverleaf 19 and map from HL7 to JSON, the concatenation did work, so I am getting

“1 Leabridge Road,London, SE1 9BG”

in the output.

[Ken Smith]

Addendum: I’ve created a new thread from scratch based upon my trials and tribulations above and again used SoapUI to test it. The media defaulted to application/json without my noticing and the message passed through successfully. So I think now that the media type/setting was a red herring.

[Ken Smith]

Thanks very much for your help, I’ve managed to get this working. There were I think 3 changes required.

First, was changing KILL to CONTINUE, as above, in the bounceRaw tcl.

Second, in my raw handler, I changed the context path, from “/rawJSON” to simply “/”

Third, and I think this is a peculiarity of SoupUI 5.1.2, which I was using as a test harness, I needed to change the media. I was using application/json, then tried text/html and the multipart options. I stumbled across another media type by accident, not available in the drop down, “x-www-form-urlencoded”.

I now get the message logged in SMAT, either xml or JSON, and the message writes out to my test file thread.

[Author]

Replies