Child pages
  • Integration of RESTWS
Skip to end of metadata
Go to start of metadata

General Info

Topic: Integration of RESTWS

Type of Project (Spike, Sprint, Epic): Sprint

Lead (Product Owner): Roger Friedman

Developer Lead: Rafal Korytkowski

Known Developers Assigned (amount of effort in hrs dedicated to this work if possible): Andrea Patterson , Wyclif , 

Sprint Dashboard:

Source code at: (the sprint-201302 branch)


Date: 2/7/13

How to Participate

Add your name to the list on this wiki page (with any comments about your availability). If you want to join after the sprint has started just join the IRC channel mentioned above and say hello.

The general process:

  1. New to OpenMRS sprints? Want help getting started? Join the IRC channel and say "???": I'd like to participate in the sprint!"
  2. Checkout code:
    1. Fork 
    2. Clone your fork: git clone
    3. Add upstream: git remote add upstream
    4. Fetch all branches: git fetch --all
    5. Checkout the sprint branch: git checkout sprint-201302
  3. Compile code:
    1. Run: mvn clean install
  4. Setup OpenMRS. Get  the standalone:
    1. Unpack and start openmrs-standalone.jar. Choose the demo database.
    2. Go to http://localhost:8081/openmrs-standalone/admin/modules/module.list and upload a compiled omod, which you can find in
  5. Pick a ticket from the available tickets in the top-left of the sprint dashboard page (listed below). Make sure it does not depend on a ticket that is incomplete. If you have any questions about the ticket, ask on the group chat
  6. Create a local branch for your ticket (see also our HOWTO for git, use 'sprint-201302' instead of 'master')
    1. git checkout -b REPORT-123 sprint-201302
    2. git push origin REPORT-123
  7. Do the ticket.
    1. Stage changes: git add -i
    2. Commit: git commit -m "REPORT-123: ticket title"
    3. Push changes: git push -f
  8. Issue a pull request for the 'sprint-201302' branch (see github help) or if you have push rights: whatever works for you! If you don't like pull requests, don't send them. Commit and push directly to the upstream repo. If you do like pull requests, fork the repo and send pull requests, but merge them right after. My favorite way is to work on the repo, but create local branches (without pushing them to the repo). Merge branches locally to the sprint branch and push to the repo.
  9. If you push directly to the repo check if tests for the sprint branch in reporting are passing: (Favorite the branch to be notified about failures: Login into Bamboo, Choose Actions -> Favorite Branch)
  10. Join the daily scrum to share your updates


Unknown macro: {composition-setup} cloak.toggle.type=wiki


Unknown macro: {toggle-cloak}

Need to know more about Goals? Click here.

Unknown macro: {cloak}

Goals: Must Have, Should Have, Could Have and Won’t Have

Must Have means we must have this as part of the solution. It is a requirement or we should rethink doing this work.  This is what we will deliver before the end of the work period this also doubles as our DOD “Definition Of Done”

Should have means we would be embarrassed not to have it. We could technically produce the solution without it but people would be surprised.

Could have means anything else we could do.  But this does not always mean low priority.  But our selection of which could haves to include or exclude (or deliver later).  Also is considered low hanging fruit (if we are in this code already for x reason wecan deliver  y with little or no extra effort) or can be items or ideas for this module that can be packaged for a later spike or sprint.

Won’t Have means this will not happen.  It might be technically impossible, a taboo for our organization or out of scope. It does not mean “might happen or would be nice”. 

Unknown macro: {cloak}

Must Have:

  • Just one module for "core OpenMRS REST Web Services" (i.e. get rid of 19ext module)
  • the resources need to be separate from the framework (even if this just means that they're in different Java packages)
  • the resources defined against 1.8 should be in a different java package from the ones defined against 1.9, etc.
  • This is mostly done, but still need to create tickets about fixing tests, and fixing some resources
  • Need to have both 1.8 and 1.9 versions of the Concept resource, which support different functionality with regard to mappings
  • RESTWS-267

Should Have

  • Resources for all "new" 1.9.0 functionality (e.g. Visit, Provider, Concept mapping changes, etc. Some of this may already be done.)
  • Have design discussions about "things that are not just CRUD"** example: evaluating a "patient calculation"** example: moving a patient from one queue to another** example: sending an HL7 message

Could Have

  • RESTWS-311 - RESTWS should allow modules to add custom searches to existing resources** DJ: I see this as a Could, unless Roger provides a concrete example where this is needed now.** Roger: I think RESTWS-267 is an example of this. (DJ: But that's core...)** Roger: this needs "core design resources"** Decision => During the spring Rafal (or someone with equivalent knowledge and ownership of the RESTWS framework) will take this ticket.
  • Support for TestOrder, and new columns in Order, starting in 1.9.2.** Do an example of how to handle out-of-band data model change** Prove this doesn't break things

Won't Have


Unknown macro: {toggle-cloak}

What should go into a Design ?  Click here for more information

Unknown macro: {cloak}

There should be multiple design meetings.  The first starts off with a small group working with the leader to determine the high level scope of the project and then to break down into smaller pieces to eventually place as tickets.  Once those meetings havehappened use of the community design meeting time should be used to refine the tickets and if possible assign them to who will be doing the work.
Risks (these should be resolved prior to or during the design meetings):

Enter anything that is still questionable or worrisome that has not been answered: (open issues, potential concerns) Once a decision is made make sure that a summarized answer is included.

Example: Q. How will we handle issues with conflicting userID’s?  A. All ID’s will have an added identifier that is unique.

Effort Accounted For: (At the end of the design call all tickets should have an estimated effort and that total should be balanced against the known available effort of the developers assigned) (Yes/No)

 If not in balance in favor of success why and the action plan for remaining items
via IRC on the [#openmrs|IRC:Home] channel on freenode.

Use this channel for ALL debugging and random questions having to do with the sprint. Please avoid direct messaging to personal contacts. If you have a question, someone else most likely does too, and our geographically distributed community benefitsfrom public group discussion.

Sprint Break down: If tickets have not already been laid out or explained this is a good place for this.

Unknown macro: {cloak}

 Risks: ?

Enter anything that is still questionable or worrisome that has not been answered: ?

Effort Accounted For: ?

Sprint Break down: ?

Kickoff Meeting

Kickoff meeting Date: TBD

Kickoff meeting recording:

(Meeting setup with known developers after the final design meeting, but prior to the start date):

Unknown macro: {iframe}

During Project Notes

Unknown macro: {toggle-cloak}

Notes (Click here to expand to Etherpad)

Unknown macro: {cloak}

Unknown macro: {iframe}

Unknown macro: {cloak}

Post Project (Retrospective)

Unknown macro: {toggle-cloak}

Retrospective (Click here to expand to Etherpad)

Unknown macro: {cloak}

Unknown macro: {iframe}

Unknown macro: {cloak}


Additional Information:


Kickoff meeting recording: ??

1 Comment

  1. Update 23 Feb 13
    Some tickets have been added to sprint, they are marked with * below
    Rafal –
    I know that you are worried about getting everything done for the refactoring of the module, but I think we need to add at least some of these to the sprint. I think we actually have more resources than you're counting on. We can discuss this anytime before or during the sprint kickoff.
    1. Documentation we should produce during the sprint:
    a. Revise existing main page to explain changes in 2.0
    b. Revise existing developer step-by-step page title to show it being for <2.0; make sure sub-resources and subclass handlers are addressed directly (RESTWS-268)
    c.* Add new developer step-by-step page with title to show it being for 2.x; make sure sub-resources and subclass handlers are addressed directly (RESTWS-360)
    d. Add new migration step-by-step page as to how to convert an existing resource to a 2.0 resource
    e. Custom and named representations are undocumented
    f. Migration from old REST module (RESTWS-159)
    g. Fix hackyswingclient so it works (RESTWS-183)
    h.* RESTWS-206 only Darius' note part – while not strictly documentation, this would make output MUCH more readable
    j. RESTWS-282 show 1.9 resources (relies on catalog output)
    2. As I understand your e-mails, 2.0 and 1.x can't run side-by-side. So existing users must continue to run 1.x until all the resource-exposing modules on which they are dependent have been upgraded. This should be in the release notes and prominent on the main page. Also it should be clear that upgraded resources are supported under OMRS 1.8.
    3. Catalog should be improved as major part of documentation (backport?)
    a. RESTWS-266 Catalog entries are incorrect
    b. RESTWS-284 Limiting output from catalog
    c. RESTWS-225 Documentation of required, subclass fields; see also RESTWS-268 subclass handler
    d. RESTWS-223 Resource doesn't appear in catalog – is this still relevant in light of refactoring? Are changes to catalog display necessary due to RESTWS-311?
    e. RESTWS-203 Spurious catalog entry
    f. RESTWS-171 Update output format
    g.* RESTWS-283 Catalog does not work with 1.10
    4. Other tickets that relate to work already being done
    a. RESTWS-254 FindMethod and FindMethodOnResource appears to be related to RESTWS-311 (backport?)
    b. RESTWS-166 Web service resource scanning – appears to be superseded due to reimplementation
    c.* RESTWS-140 Representation of cohort/cohort member – related to RESTWS-318, -321 – can't really complete refactoring until this is done
    d.* RESTWS-300 Drug resource – this is part of exposing all resources; I think its complexity is low
    e.* RESTWS-307 Concatenating fields in display – since all resources are being touched, this could be done at same time
    f. RESTWS-315 Expose get all child locations – should be trivial once RESTWS-311 is done
    g. RESTWS-262 Add search by attribute value – another custom search, not so trivial
    5. RESTWS-251 Resource-per-class-hierarchy model – this is a basic deficiency that needs correction (backport)
    6. RESTWS-277 Authentication error is same – this is a flaw in error reporting which has a big user impact
    Saludos, Roger