This how-to article describes how to create UMM-S records and associations between an individual UMM-S record and one or more UMM-C records. This process workflow is needed in order to provide functionality to needed in the Earthdata Search client. The UMM-S records discussed here are limited to the Service Types: ESI and ECHO ORDERS.

Creation of UMM-S Records of type: ESI and ECHO ORDERS

|Step 1. Take a JSON template UMM-S record (which contains all of the major classes and fields needed). S1200XXXXXX-ESI-UAT-LPDAAC_TS2.json S1200XXXXXX-ECHO-ORDERS-PROD-NSIDC_ECS.json

Step 2. Locate the correct service urls for each provider. These can be found using the MMT client. e.g. for CMR UAT environment: visit: For CMR PROD environment, visit

Step 3. Edit the Service URL into the RelatedURLs/URL field and ensure that all the other information which relates to that Service URL is correct, i.e. Description, URLContentType, Type, SubType, GetService, etc.

Step 4. Using the CMR API, create a valid CMR curl command to ingest the saved UMM-S record, e.g. curl -i -XPUT -H "Content-type: application/vnd.nasa.cmr.umm+json" -H "Authorization: Bearer XXXX" -d @S1200XXXXXX-ECHO-ORDERS-UAT-LPDAAC_TS1.json

Step 5. Verify that the UMM-S record has been created by checking the existance of the Service concept_id returned from the 100 response, e.g. <?xml version="1.0" encoding="UTF-8"?><result><concept-id>S1224343297-LPDAAC_TS1</concept-id><revision-id>1</revision-id></result>

Creation of UMM-S to UMM-C associations

Single Association:

Step 1. Using the CMR API (, create the association of the service to the collection with the curl command, e.g. curl -XPOST -i -H "Content-Type: application/json" -H "Authorization: Bearer XXXX" -d \ '[{"concept_id": "C247XXXXXXXX-LPDAAC_TS1"}]'

Step 2. Verify that the UMM-S and UMM-C records have been associated by checking the existence of the service_association returned from the 200 response, e.g. [{"service_association":{"concept_id":"S1224343297-LPDAAC_TS1","revision_id":1},"associated_item":{"concept_id":"C247XXXXXXXX-LPDAAC_TS1"}}]

Bulk Association:

Step 1. Get script from the Git directory (for permission contact and/or

Step 2. Create a tab delimited text table file the Token_ID, Service Concept_ID and the collection Concept_IDs to associate the service too.

Concept IDService Concept_IDTokenProvider

(Table example)

Step 3. Create Collection Concept_ID list to use as the look-up file for the tab delimited text table file.

Step 4. Run script ./ <CollectionConceptID_Filename> <Token_column_number> <ServiceConceptID_column_number> <Table_Filename>;

e.g. ./ CollectionConceptID_EDF_OPS.txt 3 2 EDF_OPS_association_table.txt

Step 5.  Verify that the UMM-S and UMM-C records have been association by checking the existence of the service_association returned from the 200 response, e.g. [{"service_association":{"concept_id":"S1224343297-LPDAAC_TS1","revision_id":1},"associated_item":{"concept_id":"C247XXXXXXXX-LPDAAC_TS1"}}] within the *_tag_ID_Service.txt files created by the script.

Testing the Environment via the Earthdata Search Client

The test steps which we used to verify the environment are as follows:

Step 1. Bring up

Step 2..Bring up

Step 3. Search for a collection in the provider you want to test in both. Concept id search will work.

Step 4. In both, try a direct download for one of the granules in that collection. Note: the granules I found in my quick test were ftp links which didn’t exist. This is where Sudha might be able to tell you what collections are ‘good’ ones in SIT.

Step 5. Try a ‘stage for delivery’ in both tools.

Step 6. Try a customization in both tools.

  • No labels