| Open topic with navigation |

Publisher Testing of the patientINFORM piPush Function

To facilitate rapid deployment of “piPush” receivers by patientINFORM participating publishers, CrossRef has set up a development copy of the PIregistry form used by the VHO’s. You may refer to the standard form instructions for information on the fields and their uses.

The development form is located at: http://www.crossref.org/testPIregistry

The development form works exactly the way the production form works except for 3 functions that are altered to help the publisher test their systems.

1. The development copy has all the VHO user’s accounts set to use one password and that is ‘tryme”. This allows the publisher to act as a VHO to register items for testing that point to their own content.
2. The development copy internally executes all ‘piPush’ http connections with the “test” parameter set to “true”. So ‘piPush’ POSTs from this system and the production system differ ONLY by that parameter.
3. The development copy uses a separate table to override where ‘piPush’ transactions are sent for DOI registrations. This is useful if you want to set up a particular location for your piPush receiver for testing. See the item 2b in the Publisher Implementation instructions for more on this override feature.

Here is a sample process a publisher might go through to implement this service:

1. Publisher ABC Publishing signs up to participate in patientINFORM.
2. ABC Publishing has their web programmer put together a http servlet that deploys under the name piPush on their server at http://www.abcpublishng.com. Internally, that servlet accepts HTTP Posts, processes the parameterized fields for the fields setId, vhoId, target, cover-sheet, delay, return, title, description, delete, test as noted in Patient Inform: Publisher Implementation, writes whatever handle is required into their internal system to turn on access for their content based on the return URL data, and return a 200 to the HTTP requester if all goes well or some error (403, 404, 500) if it does not.
3. The publisher’s developer then contacts CrossRef (currently Jon Stark jstark@crossref.org) to ask that the development system be set up to send all test piPushes for their prefix (e.g.,10.9999) to http://www.abcpublishing.com/piPush/.
4. Once step C is completed, the developer proceeds to the test form at http://www.crossref.org/testPIregistry and acts as a VHO to register an article that points to their own target publication (target set to 10.9999/test-article) and then clicks save to initiate the piPush.
5. The developer can then see the response the PIregistry gets as well as monitoring their own piPush application to see what comes through and test their application’s behavior.
6. Once all testing is done and the publisher is ready, they can chose to inform CrossRef (email jstark@crossref.org) of the final, official domain they want to redirect piPush transactions to (www.abcpublishing.com) or set up their piPush application at the domain their content is hosted at by default (i.e. 10.9999/abcDois all look up to www.abcpublishing.com/blah/blah/abcDois... and piPush answers at www.abcpublishing.com/piPush/ then no override is required).

link

support@crossref.org

| Open topic with navigation |