Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

registering service with HIS central #196

Open
miguelcleon opened this issue Oct 10, 2017 · 49 comments
Open

registering service with HIS central #196

miguelcleon opened this issue Oct 10, 2017 · 49 comments

Comments

@miguelcleon
Copy link
Member

I'm trying to register a WOFpy service with the QA version of HIS central and the ‘Get Site info’ seems to be erroring out:

http://qa-hiscentral.cuahsi.org/testpage.aspx?n=5629

The service should be viewable here (http://qa-hiswebclient.azurewebsites.net/ ) but it is not.

@valentinedwv
Copy link
Member

There was a bit of debugging of this try an issue filter with:
is:issue is:closed his

@miguelcleon
Copy link
Member Author

@emiliom
Copy link
Member

emiliom commented Oct 10, 2017

hmm.. it seems like getsites works but getsiteinfo info is not working:

This rings a bell, as something we ran into some time ago (a problem that happened in some circumstances only) and fixed. From the notes on the current release, it looks like those bug fixes are in the current release (v2.2.0).

Based on the version number at the bottom of http://odm2admin.cuahsi.org/wofpy/odm2timeseries/, it looks like you are using the latest release.

Thanks for testing with https://github.com/ODM2/WOFpy/blob/master/docs/WOFpy_ODM2_SOAPandREST_Tests.ipynb We'll look into it.

@emiliom
Copy link
Member

emiliom commented Oct 10, 2017

BTW, before you register the service with WDC/HIS Central (once we get these errors figured out), I strongly advice you to pick a more meaningful network code. You're using the default, generic "odm2timeseries" network code, which is kind of useless in the context of the WDC catalog. Pick something like "lczots", "LCZO", "luquilloczo", etc.

@miguelcleon
Copy link
Member Author

Ok yes, thank you for pointing that out

@emiliom
Copy link
Member

emiliom commented Oct 11, 2017

@miguelcleon, you have an important error in your test notebook. In cell 15:

# replace
networkcodes = ['wofpy/odm2timeseries']
# with
networkcodes = ['odm2timeseries']

I'm not saying this will fix things. But at least the errors will be more helpful.

Also, can we get access to your postgresql database, to examine values to help us debug? You can send us connection info offline.

@miguelcleon
Copy link
Member Author

@emiliom actually when I use:
networkcodes = ['odm2timeseries']
this URL is tested:

http://odm2admin.cuahsi.org/odm2timeseries/soap/cuahsi_1_1/.wsdl

but that gives a 404 error, but when I use
networkcodes = ['wofpy/odm2timeseries']
it tests http://odm2admin.cuahsi.org/wofpy/odm2timeseries/soap/cuahsi_1_1/.wsdl which is a valid URL.

Yes, I'll provide DB access.

@miguelcleon
Copy link
Member Author

@emiliom @lsetiawan I sent you guys a link via google drive to download a backup of the database, does that work?

@emiliom
Copy link
Member

emiliom commented Oct 11, 2017

Ok, here's what worked for the test notebook (I didn't actually test it, previously):

server_base_url = 'http://odm2admin.cuahsi.org/wofpy/'        
networkcodes = ['odm2timeseries']

Note the slash at the end of server_base_url. The need for that has to do with the behavior of urljoin.

I ran this, and I got some successful requests and some errors (more successes than errors), matching what I found manually by clicking on the REST 1.1 examples on your end point. But at least the errors now are real errors ;)

@lsetiawan
Copy link
Member

@miguelcleon Is the database backup that you sent us similar to ODM2LCZO database in your AZURE system used to test ODM2-Admin? If it is then that would help me save a huge amount of time, trying to spin up the database and then restoring it. Thanks.

@miguelcleon
Copy link
Member Author

@lsetiawan rest seems to work but I'm still having problems with soap
http://qa-hiscentral.cuahsi.org/testpage.aspx?n=5629
This is still erroring, @emiliom if you run the notebook again you should see the same thing.

@miguelcleon
Copy link
Member Author

@lsetiawan yes, it is the same database, just a more recent copy.

@miguelcleon
Copy link
Member Author

I've updated the results of my test notebook

@lsetiawan
Copy link
Member

@lsetiawan yes, it is the same database, just a more recent copy.

If I work with this older database, will I see the same error do you think?

@miguelcleon
Copy link
Member Author

latest stack trace from apache error log:

[Wed Oct 11 20:23:45.693054 2017] [wsgi:error] [pid 51654:tid 140228789536512] ERROR:spyne.application:Fault(Server: "'NoneType' object has no attribute 'SiteName'")
[Wed Oct 11 20:23:45.693080 2017] [wsgi:error] [pid 51654:tid 140228789536512] Traceback (most recent call last):
[Wed Oct 11 20:23:45.693082 2017] [wsgi:error] [pid 51654:tid 140228789536512]   File "/home/azureadmin/miniconda2/envs/wofpy/lib/python2.7/site-packages/spyne/application.py", line 151, in process_request
[Wed Oct 11 20:23:45.693085 2017] [wsgi:error] [pid 51654:tid 140228789536512]     ctx.out_object = self.call_wrapper(ctx)
[Wed Oct 11 20:23:45.693087 2017] [wsgi:error] [pid 51654:tid 140228789536512]   File "/home/azureadmin/miniconda2/envs/wofpy/lib/python2.7/site-packages/spyne/application.py", line 235, in call_wrapper
[Wed Oct 11 20:23:45.693090 2017] [wsgi:error] [pid 51654:tid 140228789536512]     retval = ctx.descriptor.service_class.call_wrapper(ctx)
[Wed Oct 11 20:23:45.693092 2017] [wsgi:error] [pid 51654:tid 140228789536512]   File "/home/azureadmin/miniconda2/envs/wofpy/lib/python2.7/site-packages/spyne/service.py", line 209, in call_wrapper
[Wed Oct 11 20:23:45.693094 2017] [wsgi:error] [pid 51654:tid 140228789536512]     return ctx.function(ctx, *args)
[Wed Oct 11 20:23:45.693096 2017] [wsgi:error] [pid 51654:tid 140228789536512]   File "/home/azureadmin/miniconda2/envs/wofpy/lib/python2.7/site-packages/wof/apps/spyned_1_1.py", line 100, in GetSiteInfo
[Wed Oct 11 20:23:45.693098 2017] [wsgi:error] [pid 51654:tid 140228789536512]     siteinfoResult = WOFService.GetSiteInfoObject(ctx, site, authToken)
[Wed Oct 11 20:23:45.693100 2017] [wsgi:error] [pid 51654:tid 140228789536512]   File "/home/azureadmin/miniconda2/envs/wofpy/lib/python2.7/site-packages/wof/apps/spyned_1_1.py", line 96, in GetSiteInfoObject
[Wed Oct 11 20:23:45.693102 2017] [wsgi:error] [pid 51654:tid 140228789536512]     raise Fault(faultstring=str(inst))
[Wed Oct 11 20:23:45.693104 2017] [wsgi:error] [pid 51654:tid 140228789536512] Fault: Fault(Server: "'NoneType' object has no attribute 'SiteName'")

@miguelcleon
Copy link
Member Author

I don't think the older database has sites associated with sampling features, which was a problem I fixed.

@lsetiawan
Copy link
Member

Oh okay. I'll just spin up your backup then. Thanks! Stay tuned! Let's see if I can find and remove the 🐛

@miguelcleon
Copy link
Member Author

Any luck? I'm supposed to go see blade runner tonight and I need to leave soon.

@lsetiawan
Copy link
Member

Just finished spinning up your db on the cloud, probably won't finish till tomorrow. Thanks.

@miguelcleon
Copy link
Member Author

Ok, ttyl

@miguelcleon
Copy link
Member Author

miguelcleon commented Oct 11, 2017

@lsetiawan I didn't end up going to the movie after all

SOAP looks like it is working based on the results of the test notebook 😃

The hiscentral qa system is still generating errors though, I tested the same site that the notebook tests so that isn't it. I'll probably have to ask CUAHSI tomorrow.

http://qa-hiscentral.cuahsi.org/testpage.aspx?n=5629

  at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall) at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters) at CUAHSI.WaterOneFlow1.GetSiteInfo(String site, String authToken) in c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\3ba7eddc\53004b84\App_WebReferences.w6j-0nv1.0.cs:line 5354 at testpage.getSiteInfo(String id) in c:\inetpub\QA-hiscentral.cuahsi.org\testpage.aspx.cs:line 410

@emiliom
Copy link
Member

emiliom commented Oct 11, 2017

I didn't end up going to the movie after all

You don't have your priorities straight! BTW, I haven't seen it yet, but I intend to.

The hiscentral qa system is still generating errors though, I tested the same site that the notebook tests so that isn't it. I'll probably have to ask CUAHSI tomorrow.

http://qa-hiscentral.cuahsi.org/testpage.aspx?n=5629

I wasn't aware of that test page until you mentioned it yesterday. Admittedly, the tests on our notebook are limited, but the fact that ulmo can consume the services at the WOFpy endpoint is a strong test in my book. Still, it'd be interesting to test one of our sample WOFpy endpoints with that CUAHSI tool. I'll try to do that tomorrow (Don doesn't work on my projects on Thursdays). But it'll be great to get more details from CUAHSI about the error that tool is running into.

@emiliom
Copy link
Member

emiliom commented Oct 13, 2017

@miguelcleon, did you make any progress on this on Thursday, learning what exact errors the CUAHSI test tool is running into? I may try to register one of our test WOFpy endpoints tomorrow, just to see what happens. Of course, I won't make it live.

@miguelcleon
Copy link
Member Author

miguelcleon commented Oct 13, 2017

@emiliom I emailed Martin at CUAHSI, yesterday morning but I haven't heard back from him. I tried changing the site in your test script to see if another one worked and it did. Yeah it would be good if you tried that.

I just tried seeing if there is maybe some unicode in the sites or method records, that the CUAHSI test page might be choking on but I'm not seeing anything.

Maybe it is expecting a method name returned from siteInfo, but I only see a method code in the response:
http://odm2admin.cuahsi.org/wofpy/odm2timeseries/rest/1_1/GetSiteInfo?site=odm2timeseries:Rio%20Icacos%20Trib-IO

@lsetiawan
Copy link
Member

Maybe it is expecting a method name returned from siteInfo, but I only see a method code in the response

In the example that is in the WaterML 1.1 Documentation Pg 68. Method Name is doesn't seem to be shown. So I think it should be fine if it's not returned.

<method methodID="4">
<methodDescription>
Battery voltage measured by Campbell 
Scientific CR206 datalogger.
</methodDescription>
</method>

@miguelcleon
Copy link
Member Author

Yeah, I don't know we need to hear from them.

@emiliom
Copy link
Member

emiliom commented Oct 13, 2017

I tried changing the site in your test script to see if another one worked and it did. Yeah it would be good if you tried that.

Are you saying you tried a different site in the CUAHSI test system, and it worked? Or just in our test notebook? If I remember correctly the original Rio Icacos Trib-IO site was now working fine on our test notebook. But if you meant the former, that you successfully tested a different site in the CUAHSI test system, please send us the site code so we can see if there are any differences in the GetSiteInfo response.

(BTW, your endpoint http://odm2admin.cuahsi.org/wofpy/odm2timeseries/ seems to be down right now)

@miguelcleon
Copy link
Member Author

Ok I got the below message from Martin, I changed the name of my site name and service name to odm2lczo and it worked! The new test service page is http://qa-hiscentral.cuahsi.org/testpage.aspx?n=5631

I spent some time on figuring out the problem and what I see is that the testpage creates a request with this header:

LCZO ODM2 Test:El Verde Soil Transect-5-31-Upper Slope

Where the site is a composite of the “registered service name” : “sitename”
This call fails!

If I use this call:

odm2timeseries:El Verde Soil Transect-5-31-Upper Slope

This call succeeds.
So it seems internally the name of the service is “odm2timeseries”
You probably need to account for the new service name given when registering the service.
I also noticed that the sites that return have a incorrect format as they repeat the sitename and don’t have a servicename.
Hope this helps. I’m also available for a call if we need to do additional debugging.

@lsetiawan
Copy link
Member

Woo hoo! That's awesome! I'm glad it was an easy fix. 😄

@emiliom
Copy link
Member

emiliom commented Oct 13, 2017

Awesome! I think I get what he's saying, but probably not 100%.

I think it'd be helpful if we set up a conference call with you, Martin, Don and me, next week, if there's still some confusion.

Also, I'm seeing many sites in your endpoint that have a site code that's the same or about the same as the site name. That's not a good practice. The site code should be a much more compact string, ideally (but not required) w/o blank spaces.

FYI, I went to the CUAHSI test system for the link you sent us, and picked the Icacos site. That worked. Then I picked the water temperature variable, and that worked. Selected a small time range (1-2 months), and that worked too!

@emiliom
Copy link
Member

emiliom commented Oct 13, 2017

To be clear: your new endpoint url is http://odm2admin.cuahsi.org/wofpy/odm2lczo/

@miguelcleon
Copy link
Member Author

@emiliom, yes, that is the new endpoint. Now I'm trying to see if they can populate their test hydroclient (http://qa-hiswebclient.azurewebsites.net/) with the data from the endpoint. It looks like they need to harvest the endpoint into hydroclient.

We can setup a call. Hopefully you can test out your own endpoint to see what questions you may have for them.

@emiliom
Copy link
Member

emiliom commented Oct 13, 2017

BTW, I noticed earlier this week that some of your sites don't have a valid lat-lon! At least one of them has (0.0, 0.0). You'll want to address that before going live as a public service 😉

Since things to be working on the CUAHSI end, maybe a call isn't needed. We can decide on Monday, after more tests, and specially if by then you've been able to test on the test hydroclient.

@miguelcleon
Copy link
Member Author

Ok, I'll take a look at those lat-lons, thanks for that.

@emiliom
Copy link
Member

emiliom commented Oct 16, 2017

@miguelcleon, we can close this issue, right? Or are we waiting to get confirmation that the service works with their test HydroClient?

I know you're also going to address sites/sampling features with (0,0) lat-lons, but that's not a WOFpy issue 😉

Also, just to reiterate, before you go live with the service registration:

I'm seeing many sites in your endpoint that have a site code that's the same or about the same as the site name. That's not a good practice. The site code should be a much more compact string, ideally (but not required) w/o blank spaces.

I would encourage you to use this opportunity to come up with short, computer-friendly site codes. But I realize you may have some dependencies on the current codes, that could cause some transition pain. If you DON'T have such dependencies, this really is a great time to create better site codes! You'll be grateful later.

Still, that's not a WOFpy issue either. Just a good data management and "CUAHSI HIS/WOF/ODM1/ODM2" practice.

@miguelcleon
Copy link
Member Author

@emiliom I'd like to keep this open until we can confirm that this is working on their test HydroClient. The new Luquillo CZO ODM2 service now shows up but I can't seem to make the filters work, so it seems like something went wrong. I emailed Martin about this.

Yes, one problem I have with the lat-lons is I don't know some of them. They have related features where the related feature they are part of have lat-lons. Many of these are soil pits spread across multiple catenas where only 1 GPS measurement was recorded. I could make up some offsets but they wouldn't be correct. I thought about just having the single GPS measurement apply for all of them but that isn't really right either. Any thoughts?

@emiliom
Copy link
Member

emiliom commented Oct 16, 2017

Sounds good, we'll keep it open.

The new Luquillo CZO ODM2 service now shows up but I can't seem to make the filters work, so it seems like something went wrong. I emailed Martin about this.

Let us know via this issue what you learn from Martin.

Yes, one problem I have with the lat-lons is I don't know some of them. They have related features where the related feature they are part of have lat-lons. Many of these are soil pits spread across multiple catenas where only 1 GPS measurement was recorded. I could make up some offsets but they wouldn't be correct. I thought about just having the single GPS measurement apply for all of them but that isn't really right either. Any thoughts?

Well, my first gut instinct is to filter out those complex sites so they're not served at all via WOFpy. They're an awkward fit for ODM1/CUAHSI HIS. We could filter them out now (via the DAO code, probably -- but we can discuss that), and then we'd have time to discuss options among ourselves, with the CUAHSI gang, and with Jeff.

You can also ask Martin and Tony about this now, to see what they think.

Personally I think it's a bad idea to include data subsets in a service if users will face a lot of ambiguity about how to interpret the data obtained via that service.

@emiliom
Copy link
Member

emiliom commented Oct 20, 2017

@miguelcleon, any progress on HydroClient testing:

The new Luquillo CZO ODM2 service now shows up but I can't seem to make the filters work, so it seems like something went wrong. I emailed Martin about this.

@miguelcleon
Copy link
Member Author

Martin got back to me this morning with:

We were able to harvest the service into QA but have trouble downloading the data in the QA Hydroclient, also many metadata fields are set to unknown could you check and see how to populate them and validate the seriescount, valuecount, etc.?

I followed up asking if he could let me know which metadata fields are missing. It doesn't seem that 'unkown' is present in the WaterML so I asked if he meant they are blank. I know valuecounts aren't updated, I had some code to update them, but it's not working and it wasn't a priority. I don't see something called seriescount anywhere.

Seems like I might have to fix my value counts but I'm not sure what else needs to be done at this point.

@emiliom
Copy link
Member

emiliom commented Oct 20, 2017

Thanks for the update. Let's reconnect on Monday. But yes, it would be really helpful if we got from Martin et al a complete report of problems.

I'll keep @lsetiawan out of this on Monday, though. He'll be offline the whole week except Monday, so he'll have other, more burning priorities on Monday 😸

@horsburgh
Copy link
Member

@emiliom, @lsetiawan, and @miguelcleon - that I know of, there is no such thing as "seriescount" in WaterML. It's been a while for me and so I could just be spacing it. But, you should probably follow up and ask Martin for more information about what the harvester is expecting (which I'm sure you were planning on doing anyway).

@emiliom
Copy link
Member

emiliom commented Oct 21, 2017

Thanks, @horsburgh. So, I think we've passed the first test phase, which is the CUAHSI service registration tests (that's what led to the last batch of fixes). Now Miguel is on the second (and last?) phase, confirming that everything works on HydroClient. Most things are working, some are not. We're waiting on feedback from Martin on specific errors.

Actually, it didn't occur to me to ask Martin "what the harvester is expecting"; I guess I was being naive? Anyway, that's a good idea. But you've also inspired me to do something we hadn't done, which is to validate the WOFpy responses against the WaterML 1.1 XML schema (.xsd) file. I just tested the GetSiteInfo response, and it validated. I'll test the rest next week.

@emiliom
Copy link
Member

emiliom commented Oct 27, 2017

@miguelcleon, any progress in hearing back from CUAHSI about the errors?

Also, while I examining your WaterML 1.1 responses (to test XML Schema validation on my end), I noticed that in your sample GetValues response, you have a positive time offset of +4; the magnitude seems right for Puerto Rico, but the sign should be negative (vs UTC).

@emiliom
Copy link
Member

emiliom commented Nov 7, 2017

@miguelcleon, I assume there's no new info from CUAHSI about the problems you were running into with your service registration and HydroClient?

FYI, we're wrapping up the last updates to WOFpy before issuing a new release (see #201); no more bug fixes or changes will be accepted. I plan to stamp a new release tomorrow morning, and a new conda package will be generated very soon after.

@miguelcleon
Copy link
Member Author

@emiliom unfortunately no. I've been stuck in proposal and annual report writing mode for the past week.

@emiliom
Copy link
Member

emiliom commented Nov 7, 2017

Oh well. Good luck!

@lsetiawan
Copy link
Member

Based on conversation with Martin, The problem seems to lie on tags not being closed properly for empty attributes. For example <qualityControlLevelCode/> should be <qualityControlLevelCode></qualityControlLevelCode> for the xml to be validated. Thanks.

@emiliom
Copy link
Member

emiliom commented Nov 16, 2017

Thanks @lsetiawan. I spoke with Martin a bit about this. What we're doing is not wrong (ie, <qualityControlLevelCode/> is not incorrect, as demonstrated by our schema validation), but it sounds like there's a client parsing expectation on their end. Let's make sure to follow up tomorrow or next week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants