Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

Main Page

Table of Contents
outlinetrue
indent20px
stylenone
printablefalse

Serializer

MetadataSerializer is responsible for serializing and deserializing OpenmrsObjects. It is build upon XStream library and uses XML format. It is able to produce a list of metadata with all related items and a package header that contains information such as name, description, creation date, OpenMRS version. They are stored in two separate files called metadata.xml and header.xml and packaged in a zip file.

You can implement the writeReplace/readResolve methods in your shareable class if you want to provide a custom serialization. It needs to conform standard rules specified in the Java documentation. You can use it to provide extra dependencies for your object which you need to export together with your object. Typically it is not needed since all fields of your object will be examined and references to other objects resolved and serialized as well. However, you will need to define an extra field for dependencies and initialize it in the writeReplace method, if you reference objects in xmls or other text formats.

...

Handler is an interface that can be implemented to support different kinds of metadata. A custom handler can be registered in HandlerFactory. There is ConceptHandler that provides support for org.openmrs.Concept. Apart from that there are OpenmrsMetadataHandler and OpenmrsObjectHandler. They provide with just a basic support for classes implementing OpenmrsMetadata and OpenmrsObject. OpenmrsMetadataHandler in particular determines at runtime a list of classes on the classpath that can be exported.

...

Publish/

...

subscribe protocol 

Published packages are A published package is accessible through a URL which consists of XXX 5 parts:

  1. URL prefix - specifies the application context path and the way the server is accessible can be accessed through the Internet and the application context path. This is typically typically http://localhost:8080/openmrs during in development and and http://example.com/openmrs during in production stage.
  2. /ws/rest/metadatasharing/package/  to follow OpenMRS REST patterns
  3. UUID of the package group (a mutual UUID along all package versions)
  4. /latest which indicates that the subscriber will lookup for the latest version of from the package group
  5. (optional) _.form_ suffix required on OpenMRS versions which don't support webservices.  Notedo not support web services. Note: after upgrading OpenMRS from e.g. 1.6.x to 1.8.1 version +, the publish URLs will lose this suffix, but old URLs will remain accessible. 

Example of an publis a publish URL: http:/localhost:8080/openmrs/ws/rest/metadatasharing/package/7f2d4731-0a98-4118-8fe0-d4b9731986c6/latest

Example of a curl to this URL

Code Block
xml
xml

<subscriptionHeader id="1">
    <packageHeader id="2" uuid="874f1efb-d73e-4093-9dd9-6e532be3a6fe">
        <dateCreated id="3">2011-08-18 00:30:45</dateCreated>
        <name>Roles</name>
        <description>All available roles</description>
        <openmrsVersion>1.8.2 Build 21762</openmrsVersion>
        <version>5</version>
        <group>7f2d4731-0a98-4118-8fe0-d4b9731986c6</group>
    </packageHeader>
    <contentUri id="4">../7f2d4731-0a98-4118-8fe0-d4b9731986c6/5/download</contentUri>
</subscriptionHeader>

The packageHeader node contains all header information about the package. 

The contentUri node is a relative URI to the place where we can download zipped package with all metadata. 

The download URL is similar to publish URL, but it ends with: %VERSION/download. This allows us to download any published version of the package, but this feature is not used yet.