Configuration

When the server starts up, it reads a config.json file that provides the server configuration information. The following is one example of a configuration when using MongoDB as a database:

{ "scheme": "http", "host": "localhost", "port": 3000, "context": "/r", "URL": "mongodb://localhost:27017/ldp”, “services”: “services.json", "resources": "change-requests" }

The config information should also reference a services file that is a ServiceProviderCatalog (SPC) used to configure the (initial) services for the server. This file is a JSON-LD file that defines the service providers and services for the server.

A server could support updates to the services while it is running, but may also restrict this to edits to a config file that is only processed when the server is restarted.

On startup, the service reads the config.json file, gets the services SPC file, reads the JSON-LD and then ensures the SPC, SP and Service LDPs and all the creation factory LDPC URIs, etc. in the services document exists and creates them if they are not.

The service merges the service provider information with the current server configuration. It does not delete any existing services that no longer appear in the SPC because that could loose data. Instead it is expected that an admin with sufficient access rights would use a console to manage old catalogs, or they would simply be retained for compatibility with older apps.

The SPC, SP and Service resources are LDPCs that are stored in a database of your choice (e.g. MongoDB, Apache Jena Fuseki) with the properties specified in the config catalogs.

Jazz platform typically uses a single ServiceProviderCatalog at the root services URI. This contains ServiceProvider entries for all the service providers, typically one for each ProjectArea.

This allows the services to be configured differently for each project area.

The @id’s in the catalogs are relative to the server. The full URL is added when the server is configured so that the stored resources have fully qualified URIs, without having to hard code that information in the spa.json or serviceProvider.json files.

The initial SPC could have one default service provider representing a generic project area that could be used for anything. Others could created dynamically by POSTing to create a new ServiceProvider LDPC. But the sample server will support the OSLC CM 3.0 vocabulary and shapes.

RTC uses different LDPC/folder/creation factory for each change request type.

This server uses a single root LDPC for all ChangeRequests, and allows any subtype to be created in that folder. Subtypes are discovered from the OSLC CM vocabulary.

For example. RTC supports creation factories for:

• ChangeRequest (these are all usages of ChangeRequest - another way of depicting subtypes, The RTC admin UI allow creating and updating these usages and providing additional properties and editors) ":b10", ":b7", ":b0", ":b16", ":b20", ":b3", ":b21", ":b4", ":b27", ":b28"
  • adoption
  • task
  • impediment
  • defect
  • planItem
  • retrospective
  • epic
  • drafts
  • buildtrackingitem
• SelectionDialog :b9", ":b5", ":b1", ":b19", "_:b23
  • default
  • requirementsChangeRequest
  • task
  • defect
  • planItem
• CreationDialog :b22", ":b24", ":b25", ":b26"
  • task
  • requirementsChangeRequest
  • planItem
  • defect, default (in the same oslc:Dialog as multiple usages)