odds_overview

Source/Repository actor simulator

There is a class of IHE actor that is not modeled will in Toolkit, the Integrated Source/Repository. In the profiles this is defined as a Document Source combined with a Document Repository. It may or may not accept Provide and Register transactions like a normal Document Repository. It does generate Register transactions to the Document Registry.

We have some coverage for its functionality in that the test client can generate any transaction so it can appear to be a Document Source and send a Provide and Register or as a Document Repository and send a Register. But when it acts as a Repository it cannot fulfill the requirement of handling Retrieve transactions.

These requirements actually occur in two places, the Integrated Source/Repository and the On-Demand Document source.

These actors can be partially simulated by using the test client and a Repository simulator together. A problem with this simplification is that the test client is missing functionality. It can be driven only by the user interface. This is a problem when wanting to automate tests.

The test client acting as a Repository can send metadata to a Registry. But when a Document Consumer later wants to follow up the stored query with a retrieve there is no repository to retrieve from (and no document either). This can be upgraded by manually creating a Document Repository, initializing it to forward to the Registry under test and then have the test client send indirectly through the Repository. The problem with this approach is the manual creation and configuration of the Repository simulator.

On-Demand documents offers two use cases. When a document is retrieved from an On-Demand Document Source (which is more repository like in this phase of its operation) a side effect is for it to send a Provide and Registry to a Document Repository. The problem here is simply where does the document (which is returned in the Retrieve and sent as part of the Provide and Register) come from? Secondly, where does the metadata come from?

A more advanced use case is where sometimes a Retrieve returns a new/different document and sometimes it returns the same document as last time. Only when a new/different document is returned does it generate the Provide and Register. Where does this content and logic come from?

Operation overview

Create sim - Create sim with Simulator Manager tool. The sim type is OD Document Source. The sim is based on the Document Repository sim with extensions to handle the on demand content.

Configure - Select a repository and registry. The repository must be configured to forward metadata to the registry. The combined Repository/Registry sim can be used. The OD Document Source sim will send the on demand DocumentEntry to this registry. When the OD Document Source accepts a retrieve request it will send a provide and register to this repository.

Select a content bundle to use (bundle should be installed ahead of time). This is part of the OD Document Source configuration.

Start - Decode the content bundle. Register the on-demand document (specified in the bundle). This should be done in the OD Document Source configuration tool.

The sim runs until it is deleted.

Configuration elements

Registry selection - this is needed for a "regular" document repository as well.

Content bundle selection - this is a file selector. In the first prototype it should be limited to a text box for the file path.

Start button - this is a problem. There is currently no support in the configuration editor for buttons.

Extensions to the Document Repository Simulator code base

When the OD Document Source sim is started the content bundle is decoded and some state is initialized in the private area set aside for the simulator in SimDb. The start action sends a register transaction to the configured registry containing a single DocumentEntry, the On Demand DocumentEntry. In the simulator state an element is created indicating the next section to be executed.

When the OD Document Source receives a retrieve transaction the next section state of the sim is checked. If there is a next section then the provide and register specified in that section is sent to the configured repository (not the OD Document Source, the real Document Repository). When the provide and register completes the stable document can be inserted into the repository part of the On Demand Document Source and retrieve request can be completed (response sent). Inserting the stable document in the repository part of the OD Document Source requires the following information:

• Document taken from the bundle section
• Newly generated Document.uniqueId. This id must be included in the provide and register as well.
• Mime type of the document. This must be extracted from the metadata included in the bundle section.

The return message from the retrieve includes

• Document
• mime type of document
• uniqueId of the On Demand document
• uniqueId of the Stable document