LUM - Developer Guide

Data model and high-level flow

../../../_images/lum-architecture.svg

LUM does the following steps to select the ODRL based prohibition or permission for the action on the swidTag.

  1. LUM matches the softwareLicensorId value on swidTag versus the softwareLicensorId on the right-to-use

  2. LUM verifies timing of the right-to-use. Do not select the expired or not effective right-to-use - date in GMT timezone in ISO "CCYY-MM-DD" format

    timing constraints on the right-to-use
    timing sample comment
    enable on specific GMT date
    {"leftOperand": "date",
     "operator": "gteq",
     "rightOperand": {"@value": "2019-08-01",
                      "@type": "xsd:date"}}
    
    right-to-use will start on "2019-08-01" in GMT timezone
    expire on specific GMT date
    {"leftOperand": "date",
     "operator": "lteq",
     "rightOperand": {"@value": "2019-12-31",
                      "@type": "xsd:date"}}
    
    expires after "2019-12-31" in GMT timezone
    “lum:goodFor” for 30 days or 1 year
    {"leftOperand": "lum:goodFor",
     "operator": "lteq",
     "rightOperand": {"@value": "30"}}
    

    or

    {"leftOperand": "lum:goodFor",
     "operator": "lteq",
     "rightOperand": "P1Y"}
    
    asset usage is good for the duration of 30 days after the first entitlement by the permission on any action. "P1Y" - for 1 year. rightOperand formatted either as ISO-8601 for duration or just a number that is converted by LUM to days ("30" -> "P30D")

    Note

    “lum:goodFor”.

    • rightOperand is expected to be formatted as duration from ISO-8601

    • ISO-8601 formats for duration always start with P and put T to separate date from time - at least one number part is required, but any combination is ok: PnYnMnDTnHnMnS, PnW

      "P30D" = 30 days,
      "P3Y6M4DT12H30M5S" = 3 years 6 mons 4 days 12:30:05,
      "P123.5DT23H" = 123 days 35:00:00,
      "P4.7Y" = 4 years 8 mons,
      "P1.3M" = 1 mon 9 days,
      "P1.55W" = 10 days 20:24:00,
      "P0.5Y" = 6 mons,
      "PT36H" = 36:00:00,
      "P1YT5S" = 1 year 00:00:05
      
    • in addition to ISO-8601 format, when the value of the rightOperand is a stringified number, LUM assumes that is the duration in days (default)

      For instance, "30" is converted by LUM to "P30D" and is 30 days

      { "leftOperand": "lum:goodFor", "operator": "lteq",
        "rightOperand": "30" }
      

      is the same as the following

      { "leftOperand": "lum:goodFor", "operator": "lteq",
        "rightOperand": "P30D" }
      
  3. LUM matches swidTag to all the populated refinement on the target of the right-to-use

    refinement on target
    match by sample comment
    swPersistentId is either "abc456" or "def789"
    {"leftOperand": "lum:swPersistentId",
     "operator": "lum:in",
     "rightOperand": ["abc456", "def789"]}
    
    solutionId in Acumos
    swTagId is "xyz123"
    {"leftOperand": "lum:swTagId",
     "operator": "lum:in",
     "rightOperand": ["xyz123"]}
    
    revisionId in Acumos
    swProductName is "Face Detection"
    {"leftOperand": "lum:swProductName",
     "operator": "lum:in",
     "rightOperand": ["Face Detection"]}
    
    model name in Acumos
    swCategory is "image-processing"
    {"leftOperand": "lum:swCategory",
     "operator": "lum:in",
     "rightOperand": ["image-processing"]}
    
    category is the model type in Acumos. Each model has a single model type
    swCatalogId is "XYZ models"
    {"leftOperand": "lum:swCatalogId",
     "operator": "lum:in",
     "rightOperand": ["XYZ models"]}
    
    catalogId in Acumos
    swCatalogType is "restricted"
    {"leftOperand": "lum:swCatalogType",
     "operator": "lum:in",
      "rightOperand": ["restricted"]}
    
    catalogType in Acumos
  4. LUM matches user to all the populated refinement on the assignee of the right-to-use

    refinement on assignee
    match by sample comment
    number of users
    {"leftOperand": "lum:countUniqueUsers",
     "operator": "lteq",
     "rightOperand": {"@value": "5",
                      "@type": "xsd:integer"}}
    
    for constraint by count of users
    restrict users by the subscriber company
    {"leftOperand": "lum:users",
     "operator": "lum:in",
     "rightOperand": ["alex",
                      "justin",
                      "michelle"]}
    
    set of unique userIds comes from agreement-restriction
  5. LUM matches the action value received from Acumos versus the action on the right-to-use

  6. LUM verifies the usage count on the permission for the specific action

    usage constraints on permission
    count sample comment
    action "acumos:download"
    {"action": "acumos:download",
     "constraint": [
       {"leftOperand": "count",
        "operator": "lteq",
        "rightOperand": {"@value": "25",
                         "@type": "xsd:integer"}}]}
    
    download up to 25 times
    action "acumos:deploy"
    {"action": "acumos:deploy",
     "constraint": [
       {"leftOperand": "count",
        "operator": "lteq",
        "rightOperand": {"@value": "35",
                         "@type": "xsd:integer"}}]}
    
    deploy up to 35 times
    action in ["transfer", "aggregate"]
    {"action": ["transfer", "aggregate"],
     "constraint": [
       {"leftOperand": "count",
        "operator": "lteq",
        "rightOperand": {"@value": "45",
                         "@type": "xsd:integer"}}]}
    
    each action has a separate limit of 45

    Note

    please refer to Acumos Right to Use Actions for the actual list of supported actions

    Note

    each action is treated separately from any other action and has its own usage count in metrics.

  7. LUM picks the first right-to-use after ranking/sorting them by the following criteria
  8. LUM increments the usage count in the metrics per action


Technology and frameworks

framework version link
node.js 12.16.1 https://nodejs.org
express.js 4.17.1 http://expressjs.com/
node-postgres 7.18.2 https://node-postgres.com/
openapi 3.0.3 https://swagger.io/specification/
postgres database 11.5 https://www.postgresql.org/