Proposal for a modification in the SOAP event-webservice

2»

Comments

  • kkrumliankkrumlian Posts: 25
    @toskrip ,

    I can explain this:
    I would be happy if somebody could explain me why we need new namespaces for ODM scheme:
    xmlns="http://www.cdisc.org/ns/odm/v1.3"
    xmlns:ns5="http://www.cdisc.org/ns/odm/v1.3-api"

    and also for OC ODM extensions scheme:
    xmlns:ns2="http://www.openclinica.org/ns/odm_ext_v130/v3.1"
    xmlns:ns6="http://www.openclinica.org/ns/odm_ext_v130/v3.1-api"

    We needed to expose the enketo URL in this service call. However we didn't want to add this new attribute to the main schema as we were not sure yet how far we were going to get with enketo. (Definitely need a better strategy on making this kind of changes in the future). Thoughts?

    Krikor
  • toskriptoskrip Posts: 243 ✭✭
    > namespaces

    yeah, but than why not to use the new namespace only for URL attribute? I mean, e.g. the ODM root element is unchanged (does not need a new namespace there). Imagine that somebody has implemented domain model based on ODM scheme, which is annotated to handle automatic marshaling/unmarshalling to/from CDISC ODM XML with OC extensions. Now when you introduce new namespaces for standard unchanged ODM elements you successfully force that developer to refactor the domain model to be able to process new ODM responses from web services. Even if that guy e.g. do not want to use new Url attribute....

    @kkrumlian let's move this discussion somewhere else (github?)... I would recommend to create a new repository where we can collaborate on API design (ideas) in implementation independent way (RAML?)

    T
  • kkrumliankkrumlian Posts: 25
    Point taken on namespaces. Will set something up for discussion on github.

    @jacob_rousseau where are you at wrt your immediate need?
    Krikor
  • JacobRousseauJacobRousseau Posts: 2
    Hi everybody,

    sorry for responding only now on the discussion I started last week. We are currently developing an application for automatic / unattended uploads. For this reason we need a way to retrieve the current status of all the events and CRF's. We are currently deliberating on solutions.

    For the moment we still want to carry on with SOAP and we'll also make provisions to switch to REST in our application. @toskrip had a very good suggestion: adjust the SOAP listAllByStudy call and add the missing required information. In that way you also maintain the ODM-like structure of the response. I'll dive into it this Thursday and come up with a list of missing information we need on the events.

    My example given in the original post was only a quick & dirty PoC to see if it was possible. It was a piece of cake thanks to the new services model being implemented!

    We certainly shall follow and contribute to the discussion on GitHub on REST.

    regards Jacob
  • jacob_rousseaujacob_rousseau Posts: 4
    Hi everybody,
    today I had a look at the suggestions you made. We still want to carry-on the SOAP route because we don't have knowlegde and resources available to setup OAuth for REST.

    Today I've made an implementation of the suggestion @toskrip made to change the listAllByStudy call. The modification adds the event status, the subject event status and the event ordinal to the response of the listAllByStudy method. These fields would provide the information we need for our client.

    @kkrumlian what way do you suggest to use to keep it backward compatible for clients? The fields could be made optional in the eventType XSD defintion or we can introduce a new operation to the WSDL.
    We are a bit concerned that the listAllByStudy method will perform slowly for large studies. How do you feel about adding a new operation which only returns subject- and event-information for a specific subject?

    regards, Jacob
  • kkrumliankkrumlian Posts: 25
    Hey @jacob_rousseau,

    If we get event-specific information for a specific subject then you still need a mechanism to get all study subject ids/oids.

    Perhaps implementing a pagination mechanism into listAllByStudy is a better approach.Github makes use of this approach - https://developer.github.com/v3/#pagination

    I think making the fields optional is a good implementation. I don't think adding new elements warrant a version change or a new operation.

    Krikor




  • jacob.rousseaujacob.rousseau Posts: 20
    Hi everybody,

    last Tuesday I've submitted a pull request - developed against the 3.6 branch - with a modification on the listAllByStudy. It returns per subject the available events, event-status, CRF's with CRF-status and versions. I've introduced a new type but the current plug-in point will break existing clients.

    However I believe the change can be plugged-in without breaking clients at the existing xsd:eventType with a maxOccurs of 0.

    If @Krikor Krumlian is this approach OK with you, I can create a new pull-request which does not break existing clients.

    regards, Jacob

Sign In or Register to comment.