Stream: subscriptions
Topic: argonaut-subscription-client-ui
Bradley Strecker (Sep 10 2019 at 13:48):
@Gino Canessa I'm trying to use your UI (running locally) to help drive my server side work. I'm able to get up to the point where it requests the subscription from my server, and I can see in my logs that it was created successfully, but the UI outputs the following
Request for Subscription (http://localhost:3000/beta/2c400054-42d8-4e74-87b7-80b5bd5fde9f/Subscription/) failed:
SyntaxError: Unexpected end of JSON input
What is it expecting for a response from the create? Typically for a POST only the HTTP Status, Location, and ETag are returned
Bradley Strecker (Sep 10 2019 at 13:50):
I am NOT running the Client Host locally, I'm pointing that to https://client.subscriptions.argo.run, could that be related?
Gino Canessa (Sep 10 2019 at 14:51):
Hi @Bradley Strecker , I had put in resource return so that it could be displayed and you're the first to bring it up. I will update the UI to allow for the different return types and post shortly.
Bradley Strecker (Sep 10 2019 at 14:54):
Cool. Was just trying to make sure I wasn't missing something. The argonaut scenario (https://github.com/argonautproject/subscriptions/tree/master/connectathon-scenarios-201909#scenario-1) does kind of imply the resource should be returned ("4. Server responds with status: requested"), but that does seem strange. Maybe a hold-over from the previous design?
Gino Canessa (Sep 10 2019 at 15:02):
I just implemented that by default instead of checking the Prefer header. For clarity I started with return=representation, and forgot to make a note to do the other ones. I've added a task to honor that header in the proxy properly so that future clients work as expected as well.
Bradley Strecker (Sep 10 2019 at 15:13):
One other thing I've noticed, that might (?) be easy to support would be to accept an Auth header that could be used by the client when talking to the FHIR server during the workflow. This is separate from the Auth header which can be captured as part of the Subscription body, but rather the Auth header used to tell the FHIR server that you are allowed access the FHIR server at all. We require authorization to perform any writes, so I've head to temporarily disable those checks for now
Gino Canessa (Sep 10 2019 at 15:14):
I like it, will be in shortly.
Gino Canessa (Sep 10 2019 at 22:00):
Hi @Bradley Strecker , just pushed a new version now (will take a few minutes to be live). It includes support for an Auth header for the FHIR server, as well as specifying the Prefer header. The UI will now check for not having the normal resource returned (e.g., minimal or OperationOutcome) and fetch the necessary resource based on the Location header.
Please let me know if you run into any issues or if there's anything else you need.
Bradley Strecker (Sep 11 2019 at 12:43):
Nice. I've pulled them down and verified that the changes work. It lets me do a little TODO cleanup in our server.
Bradley Strecker (Sep 11 2019 at 12:48):
Is the full workflow implemented for the Patient+REST scenario? I always get hung on the "Wait on Endpoint Handshake". We are successfully sending the handshake notification and updating the status to "active", so I know something is receiving the handshake, but the UI never progresses.
I've tried running the argonaut-subscription-client locally to see if I could identify anything, but not really familiar with .net :) None of the breakpoints that I think should be hitting are hitting
Brian Wright (Sep 11 2019 at 13:06):
Under the Patient+Rest tab, the sample topic resource has id = 1, and Title="admission". The sample subscription has topic.reference = "https://server.subscriptions.argo.run/Topic/admission". (Note the examples at build.fhir.org have Topic.id = "admission" and Subscription.topic.reference = "Topic/admission". Questions: 1) should the client UI subscription topic reference be to the topic id? (I am assuming yes) 2) Is the recommendation that if you have server side defined Topics, that the Topic id be human friendly?
Josh Mandel (Sep 11 2019 at 13:28):
For (1), indeed the Subscription should point to its Topic with standard FHIR references (generally, a URL relative server base).
Bradley Strecker (Sep 11 2019 at 13:28):
1) Since Subscription.topic is defined as a Reference(Topic) I would think it would have to be. FWIW, I've had my server using both "1" and "admission" as the topic id, and it the client UI subscription seems to honor that.
2) I switched from "Topic/1" to "Topic/admisson" simply because I think "Topic/1" looks goofy :). Plus as a human looking at these "Topic/admission" seems more immediately obvious as to what it is. If client defined topics ever become a thing then allowing custom names seems like it would quickly lead to collisions and would be disgouraged, but the server could probably distinguish between server (friendly names) and client (generated ids) defined topics (as your caveat alludes)
Bradley Strecker (Sep 11 2019 at 13:28):
Drat, beat me
Josh Mandel (Sep 11 2019 at 13:29):
We have not discussed (2), and I'm not sure I would make this recommendation in production, but it's very nice in a test environment.
Josh Mandel (Sep 11 2019 at 13:39):
And re (2), there's also Topic.url (which in my opinion should definitely be human-readable for any canonical URL). It doesn't show up the internal references, so it's not quite the same thing -- but figured I'd mention it as a place where human readability should also be considered.
Gino Canessa (Sep 11 2019 at 14:52):
Is the full workflow implemented for the Patient+REST scenario? I always get hung on the "Wait on Endpoint Handshake". We are successfully sending the handshake notification and updating the status to "active", so I know something is receiving the handshake, but the UI never progresses.
I've tried running the argonaut-subscription-client locally to see if I could identify anything, but not really familiar with .net :) None of the breakpoints that I think should be hitting are hitting
The UI checks to see if the subscription event count is zero in order to qualify it as a handshake. If you turn on console logging, you can see any events that the UI receives to figure out if the issue is there.
If you are looking to set an endpoint in the Client Host, the area you want would be in EndpointServiceController.cs depending on what the endpoint is you are looking for. I noticed that I have the endpoints set to only accept application/fhir+json right now, so if you are using a different content type that may be an issue. I am updating the client host now so that it will also accept application/json.
Gino Canessa (Sep 11 2019 at 14:58):
I also updated the flow in the UI so that it can start receiving notifications prior to the notification being created in the UI (in case they were coming in too quickly), but I'm guessing the other fix is more relevant.
Gino Canessa (Sep 11 2019 at 14:59):
As a test, you can also post the sample handshake notification to the endpoint (e.g., with PostMan) and it should show up in the UI. If it doesn't, we can track from there.
Gino Canessa (Sep 11 2019 at 15:12):
Under the Patient+Rest tab, the sample topic resource has id = 1, and Title="admission". The sample subscription has topic.reference = "https://server.subscriptions.argo.run/Topic/admission". (Note the examples at build.fhir.org have Topic.id = "admission" and Subscription.topic.reference = "Topic/admission". Questions: 1) should the client UI subscription topic reference be to the topic id? (I am assuming yes) 2) Is the recommendation that if you have server side defined Topics, that the Topic id be human friendly?
1) Yes that's an error. The proxy is allowing resolution based on the title, which I'm not quite sure what I was doing.
2) I don't think that's desired. It is that way in the examples for clarity, but in real-world scenarios I don't think we want the topic id to convey anything about the patient. If it does, then we need to exclude the topic id from payloads (e.g., if the ID was new-diagnosis-condition-x then even the empty payload fully conveys that a person has been diagnosed with 'x'.
Gino Canessa (Sep 11 2019 at 15:15):
The proxy is allowing resolution based on the title, which I'm not quite sure what I was doing.
Found it: the Topic/admission was hard coded because I didn't want to assume that the server had implemented Topic discovery. I will update it so that if you DO have topic discovery it will use the proper URL, otherwise it will default to that for demo purposes.
Gino Canessa (Sep 11 2019 at 15:45):
Ok, I just pushed a new version of the UI. It will use the URL for the proper topic if discovered, and for now will default to Topic/admission if topic discovery is not implemented or performed.
Made a note to refine this further to allow for the user to set the ID of the topic if discovery isn't implemented, but need to finish groups first.
Josh Mandel (Sep 11 2019 at 15:46):
BTW @Bradley Strecker just to confirm, does your implementation support Topic search (for the discovery step)? By find all, or by Topic.url?
Bradley Strecker (Sep 11 2019 at 15:50):
Find all works, by id should (but it looks like I managed to break it): https://fhir-open.stagingcerner.com/beta/0b8a0111-e8e6-4c26-a91c-5069cbc6b1ca/Topic?_format=json
Bradley Strecker (Sep 11 2019 at 15:52):
Currently I have the Topic.url for the admission topic set to "http://argonautproject.org/subscription-ig/Topic/admission", should it be that or pointing back to our own server?
Gino Canessa (Sep 11 2019 at 15:54):
It should be that (our working canonical). The UI now checks for a Topic with that URL, then grabs the ID of that Topic and uses that for the subscription (if you got the list of topics in step 1)
Josh Mandel (Sep 11 2019 at 16:00):
Thanks, that's perfect :)
Eric Haas (Sep 12 2019 at 08:27):
I think the whole canonical vs literal reference thing is confusing in general and for Subscription.topic in particular and we should probably document that is the literal ( relative or absolute reference to a resource and not the canonical.
Josh Mandel (Sep 12 2019 at 14:03):
You're saying we'd want to prohibit the use of canonical URLs in Subscription.topic.reference?
Josh Mandel (Sep 12 2019 at 14:07):
The core spec says for literal references, "The URL may contain a reference to a canonical URL" (https://www.hl7.org/fhir/references.html#literal). I kinda like this behavior, but I'm willing to be convinced otherwise. (Do you think it is a mistake for the court spec to allow this at all, or is Subscription.topic.reference a special case?)
Eric Haas (Sep 12 2019 at 14:29):
That reference makes it pretty clear and the part that I was unclear about. so I'm good.
Last updated: Apr 12 2022 at 19:14 UTC
