- This topic has 10 replies, 4 voices, and was last updated 7 months, 1 week ago by
.
-
Topic
-
I have been asked to design and build a Web Service that will have a URL associated with it. The thread will deliver results after the client makes the connection. Each external connection will have to send in the proper user name and password. The issue that I can’t wrap my brain around is: how do I setup the thread so that it only sends the data out to the correct user name associated and not everything to every client.
TIA
Rob Lindsey
-
Replies
-
-
-
Well this is for results where many clients would be connecting. I was hoping to use the recovery DB within the site that the thread would be running in. I do not know exactly where the results are coming from as of yet but I was making the assumption that I would have them coming in on an inbound thread that would send them to a outbound thread that would listen for connections on the URL.
-
Is there anything in the Result message itself that identifies the intended recipient (not necessarily the User name and Password)?
If so, then perhaps a table with the relationship between the message identifiers and the client (User Name, etc.) can be used?
The question then (and maybe this is what is the essence of your question) is how to make sure only that client now properly identified receives the data and not anybody listening on that URL. The answer might lie in whatever Webservice envelope is wrapped around the payload upon delivery. I do not know the answer to that question.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
I wouldn’t know how to go about using the recovery database to queue messages for an inbound WS client. It seems counterintuitive, but it may be possible.
Also, is this going to be a stream of results for each client, or are they going to be querying based on placer ID or MRN? If it’s a stream of results, are you thinking of using a web service query that is something like “get next result” that the clients would call?
-
This is all speculation as this new thread (web service) is going to replace an existing service and I don’t know how that one works as of yet. I am hoping that I could use the standard recovery DB and just have the results waiting there and pick them out by certain values in the MSH segment. Of course, I don’t know how the current one works and wanted to know how others have setup their Web service threads that listen for connection and send information out after the connection. It does sounds like calling another service to get the results for the specific client might be the best option.
I don’t like it when I don’t know what I don’t know.
Rob
-
The recovery DB doesn’t have the type of functionality that you’re describing. It’s just used to queue messages on each state. For an outbound interface, it’s always going to give you the first message on the outbound queue. You can’t have a thread query the recovery db to give you a different message.
You could have an outbound thread that writes all the messages to a database (SQL Server, Mysql, Sqlite, take your pick) and then your web service thread could run queries against that database to build messages to send. That sounds more doable.
-
-
Hey Rob – the design or intended scope of the webservice will be good to know once you know more. In cloverleaf CAA/WS – you will get a basic framework for creating a webservice endpoint that will reference a SOAP or REST consumer.
The underlying consumer is where the actual service will live. You will need to decide if you are exposing a consumable WSDL for SOAP in order for clients to build the calls they will be making to your webservice, or examples on how to make REST calls to initiate whatever work the threads will be doing in order to give a payload response back to the client who made the call to your webservice.
You may need to do some heavy TCL and to David’s point, some SQL to get the job done in the engine.
When i expose endpoints to clients, depending on the use case, may use the ‘PATH’ trx ID(ie. the URL). Which allows me to only expose 1 endpoint, but give each client their own URL without creating multiple java/ws server threads.
Example:
https://hospitalorg.webservice.com:5000/getResults – is the main service, but i supply the orgs querying or posting to the webservice this:
https://hospitalorg.webservice.com:5000/getResults/OrthoSurgCenter/
https://hospitalorg.webservice.com:5000/getResults/PrimaryCareCenter/
Then you can use the TRXID to have some business logic to route or call different data lakes(most likely short – long term storage of results in a sql table). From there you can take the meta data stored in results to qualify the result against your criteria and post the full response back to the client with the result(s)
These design items will be the key to the build.
-
Thanks for this. Web service stuff is still a bit of a black box to my brain. I have found out more info. Web service inbound will need to receive orders. It will have to ACK those orders and then send them on. The outbound results will be two of them. 1) client calls web service to pick up results so I know that I will have to call some type of DB to get the results for the client that logs in. I need more details on how we will be getting that client login and password to the actual result. 2) a web service push – I will need a lot more information this one to design it properly.
As Johnny-5 would say…. “Need more input”
Rob
-
-
-
- You must be logged in to reply to this topic.
