Build toolBuild tooltypeRuns at build time. Nothing of it ships in the deployed application.See every one →What this type is →by SAPby SAPoriginPublished by SAP itself. A visible facet, never an input to a reading — a dormant official plugin reads exactly like a dormant independent one.See every one →

@sap/ams-dev

Compiles the DCL authorization policies of SAP's Authorization Management Service to DCN, so an AMS-secured application runs and is tested on a laptop.

Policies for AMS are written in DCL and the runtime reads DCN, so nothing local can evaluate one until it is compiled. This is the compiler: a compile-dcl bin takes a DCL source root and a DCN output root, runs entirely in Node.js through WebAssembly with no Java installed, and can be told to fail on a warning or a deprecation rather than only on an error. In a CAP project it reacts to DCL changes, compiling them under mocked authentication and, under ias authentication, pushing the policies to the AMS server from the SAP Identity service binding. A test then runs against the local bundle with policy assignments mocked per tenant and user in JSON, which is what its own pretest and posttest example wires up.

Facts

Latestv3.0.2ReleasedLicenceSAP DEVELOPER LICENSE AGREEMENT 3.2

Where it sits

Lives in
Provides
Local developmentCAPLocal developmentcapabilityRunning the whole stack on a laptop against real bindings — the service, the UI and the routing in front of it — without deploying to see a change.AuthorizationCAPAuthorizationcapabilityDeciding who may read or change what, at service, entity and instance level — role checks, forwarded user context, and restrictions evaluated as query filters rather than after the fact.
Flavors
Node.jsfrom its runtime
Requires
@sap/cds≥ 8@sap/cdsartifactThe peer range, as published.

Who is behind it

SAPSAPOrganisationMaintains this
In the atlas: maintains 137, wrote 14
@SAP
maintainer

Before choosing this

Conditions

LicenceSAP Developer License Agreement 3.2 CAP§ 1, 2, 3A cds-plugin is used with SAP CAP materials, or an artifact is explicitly identified as a CAP plugin or application.
  • § 1 License. Productive customer applications are limited to SAP BTP or another SAP-licensed platform, and mass extraction to a non-SAP product is restricted except where solely required for SAP interoperability.
  • § 2 Intellectual Property. The agreement retains SAP's rights in the covered materials and limits making APIs, tools or software available to third parties, while preserving ownership of customer applications subject to SAP's underlying rights.
  • § 3 Artificial Intelligence Training. The agreement prohibits use of the covered materials and customer applications for training artificial-intelligence models or systems.
SAP Developer License Agreement 3.2 CAP →
PracticalFunctional boundary

Its own account of itself is local running and tests: the DCN it writes serves as input for running an application using AMS on the DCL bundle locally. It carries the SAP Developer License Agreement rather than an open-source licence, and the repository named in its package metadata is an internal SAP host, so the npm page is the only thing to read.

What it declares

Every artifact

Type
Build tool
Origin
By SAP
Runtime
Node.js

As a build tool

Declared for
>=8
Distributed through
npm

Connections2

Install

npm add @sap/ams-dev

Derived from the package name. No recipe recorded; the README has the configuration.

README

quoted from @sap/ams-dev@3.0.2 under SAP DEVELOPER LICENSE AGREEMENT, read
@sap/ams-dev@3.0.2/README.mdOn npm

@sap/ams-dev

This module provides tooling support for extending applications which authenticate users via the SAP Cloud Identity Services with AMS (Authorization Management Service) authorization checks.

The primary functionality provided by this module is enabling tests on local DCL (Data Control Language) bundles. To this end, it provides the compile-dcl script to produce DCN (Data Control Notation) files for the ADC (Authorization Decision Controller) used in @sap/ams versions >= 1.17.0.

CAP integration

For CAP (Cloud Application Programming Model) applications, the plugin integrates nicely into mocked auth and hybrid environments which allows developing local applications with AMS bound to SAP Identity service instances on SAP BTP. In both cases, it reacts to changes of DCL files. During mocked auth, it compiles them to DCN files. When using ias auth, it provides a feature to push the policies to the AMS server from the SAP Identity service binding.

For details, refer to the documentation of @sap/ams.

DCL compilation

This module provides a bin script called compile-dcl which compiles .dcl files to .dcn files which serve as input for running an application using AMS on the DCL bundle locally, e.g. for unit tests.

Note: The DCL compiler now runs entirely in Node.js using WebAssembly. Java is no longer required.

If you install this module globally via npm, you can call the compile-dcl CLI script from any shell. If you install it locally in a project, you can run it via npx compile-dcl (or npx --package=@sap/ams-dev compile-dcl to make 100% sure you are running the compile-dcl script from this module).

compile-dcl

The script requires both a source and an output directory as parameter in addition to some optional parameters (see compile-dcl --help):

Usage: compile-dcl --dcl [DCL_SRC_ROOT_DIR] --output [DCN_OUTPUT_ROOT_DIR]

Options:
      --help       Show help                                           [boolean]
      --version    Show version number                                 [boolean]
  -d, --dcl        path to DCL root directory                [string] [required]
  -o, --output     path to DCN output root directory         [string] [required]
  -l, --log-level  log level
                [string] [choices: "info", "error", "silent"] [default: "error"]
  -f, --failOn     fail on error, deprecation or warning
        [string] [choices: "error", "deprecation", "warning"] [default: "error"]

Examples:
  compile-dcl -d src/dcl -o build/dcn  compiles DCL in root directory src/dcl to
                                       DCN in output root directory build/dcn

We recommend the use of --failOn warning to not miss out on potential future deprecation warnings regarding the DCL syntax.

Testing with a local DCL bundle

To test your application with local DCL policy files and mocked policy assignments, follow these steps depending on the @sap/ams version of your project.

@sap/ams 3.x
  1. Compile the DCL bundle to DCN before running the application
  2. Use AuthorizationManagementService#fromLocalDcn(dcnRoot, config) to create the AuthorizationManagementService singleton with the following config:
  • dcnRoot (string) the root directory of the DCN compilation.
  • config.assignments (string | PolicyAssignments, optional) a path to a PolicyAssignments JSON file or an in-memory PolicyAssignments object.

In PolicyAssignments, the assignments are based on the SAP Identity Service app_tid (tenant) and scim_id from the user's (mocked) token.

{
  "tenant1": {
      "user1": [
        "sales.readAllSalesOrders"
      ],
      "user2": [
        "sales.readAllSalesOrders",
        "sales.writeAllSalesOrders"
      ]
  },
  "tenant2": {
      "user1": [
        "sales.readAllSalesOrders",
        "sales.writeAllSalesOrders"
      ]
  }
}

In your package.json, you could set-up the pretest and posttest lifecycle scripts to perform the necessary DCL compilation before the tests and cleanup the DCN output afterwards.

This is an example package.json for an application using jest as test framework but any other framework can be used:

"config": {
  "dcn_root": "test/dcn"
},
"scripts": {
    "pretest": "npx --package=@sap/ams-dev compile-dcl -d test/dcl -o $npm_package_config_dcn_root",
    "jest": "AMS_DCN_ROOT=$npm_package_config_dcn_root jest", // or any other framework
    "test": "npm run jest",
    "posttest": "rm -rf $npm_package_config_dcn_root"
  }
@sap/ams 2.x
  1. Compile the DCL bundle to DCN before running the application
  2. Set environment variable AMS_DCN_ROOT to the DCN output root folder
  3. Create a data.json file in which you assign policies to mock users
  4. Run the application
  5. In @sap/ams versions >= 1.17, when creating a PolicyDecisionPoint without the new constructor argument for passing an explicit bundle loader, it will automatically load the bundle located at AMS_DCN_ROOT when its value has been set

Inside the data.json file you can mock policy assignments to users based on the SAP Identity Service app_tid (tenant) and scim_id from the user's (mocked) token.

{
    "principal2policies": {
        "tenant1": {
            "user1": [
              "sales.readAllSalesOrders"
            ],
            "user2": [
              "sales.readAllSalesOrders",
              "sales.writeAllSalesOrders"
            ]
        },
        "tenant2": {
            "user1": [
              "sales.readAllSalesOrders",
              "sales.writeAllSalesOrders"
            ]
        }
    }
}

In your package.json, you could set-up the pretest and posttest lifecycle scripts to perform the necessary DCL compilation before the tests and cleanup the DCN output afterwards. If you use a data.json for mock policy assignments, copy it to the DCN root folder after compilation. Make sure to run the tests with the correct AMS_DCN_ROOT.

This is an example package.json for an application using jest as test framework but any other framework can be used:

"config": {
  "dcn_root": "test/dcn"
},
"scripts": {
    "compile-dcl": "npx --package=@sap/ams-dev compile-dcl -d test/dcl -o $npm_package_config_dcn_root && cp test/dcl/data.json $npm_package_config_dcn_root/data.json",
    "pretest": "npm run compile-dcl",
    "jest": "AMS_DCN_ROOT=$npm_package_config_dcn_root jest", // or any other framework
    "test": "npm run jest",
    "posttest": "rm -rf $npm_package_config_dcn_root"
  }
SAP DEVELOPER LICENSE AGREEMENT 3.2, read licence

History

Latest

v3.0.2

  1. v2.2.0

  2. v2.1.4

  3. v2.1.3

  4. v2.1.2

  5. v2.1.1

  6. v2.1.0

  7. v2.0.0

  8. v1.3.1

  9. v1.3.0

  10. v1.2.0

  11. v1.1.0

  12. v1.0.1

  13. v1.0.0

  14. v0.10.2

  15. v0.10.1

  16. v0.10.0

  17. v0.9.0

  18. v0.8.6

  19. v0.8.5

  20. v0.8.4

  21. v0.8.3

  22. v0.8.2

  23. v0.8.1

  24. v0.8.0

  25. v0.7.1

On npm
522downloads per week, npm
Weekly downloads for @sap/ams-dev26 complete calendar weeks from 2026-04-27 to 2026-10-25; the latest total is 522.27 Apr – 3 May: 1,7104 May – 10 May: 2,19311 May – 17 May: 1,76618 May – 24 May: 2,52225 May – 31 May: 1,9441 Jun – 7 Jun: 2,4298 Jun – 14 Jun: 1,94215 Jun – 21 Jun: 2,60222 Jun – 28 Jun: 2,77629 Jun – 5 Jul: 3,3656 Jul – 12 Jul: 2,57013 Jul – 19 Jul: 2,36520 Jul – 26 Jul: 2,54527 Jul – 2 Aug: 2,4103 Aug – 9 Aug: 2,10110 Aug – 16 Aug: 2,36817 Aug – 23 Aug: 2,63324 Aug – 30 Aug: 2,08931 Aug – 6 Sept: 2,1027 Sept – 13 Sept: 1,48214 Sept – 20 Sept: 2,27821 Sept – 27 Sept: 2,78728 Sept – 4 Oct: 2,8105 Oct – 11 Oct: 2,12612 Oct – 18 Oct: 2,02019 Oct – 25 Oct: 522

Others providing21

Local development
  1. abap2UI5 PlaygroundIn-browser ABAP editor beside the abap2UI5 app it buildsfrom ABAP
  2. web-abap2UI5abap2UI5 transpiled to JavaScript and run in a browser tabfrom ABAP
  3. vite-plugin-cdsServes a Vite app through cds watch and imports .cds filesfrom CAP
  4. com.sap.cds:cds-feature-dev-dashboardBrowser dashboard for a running CAP Java service during developmentfrom CAP
  5. com.sap.cds:cds-maven-pluginMaven plugin running CDS build steps in a CAP Java projectfrom CAP
  6. @cap-js-community/commonSix CAP features in one package, from replication cache to rate limitsfrom CAP
  7. abap_trial_dockerScripts running the ABAP Developer Edition in Dockerfrom ABAP
  8. @neoimpulse/cap-js-bootstrapCLI starting several CAP services and an AppRouter locally togetherfrom CAP
  9. open-steamgateLocal ABAP server serving /IWBEP/ OData v2 without an SAP systemfrom ABAP
  10. pokrakam/abapDevSysInitABAP report setting up a new ABAP Developer Edition or trial systemfrom ABAP
  11. @sang2x/captoolsCLI of CAP development tools for Cloud Foundry workflowsfrom CAP
  12. @sap/cds-dkCommand line client and development toolkit for CAPfrom CAP
  13. @sap/cdsCAP Node.js runtimefrom CAP
  14. dev-approuterDev-time wrapper for the SAP Application Routerfrom CAP
Authorization
  1. SAP Authorization and Trust Management serviceOAuth server issuing JWTs and holding scopes for BTP appsfrom BTP/BAIP
  2. OAuth 2.0 on SAP BTPOAuth 2.0 grant flows for applications and APIs in Neo regionsfrom BTP/BAIP
  3. com.sap.cds:cds-services-bomMaven bill of materials pinning CAP Java module versionsfrom CAP
  4. cap-toolkitUtility bundle for CAP handlers: builder, roles, validation, queriesfrom CAP
  5. @sap/amsAuthorization from DCL policies for Node.js apps on SAP Cloud Identityfrom CAP
  6. @sap/cdsCAP Node.js runtimefrom CAP
  7. sap-usi-authority-checkAuthority check helper class used across SchwarzIT's USI reportsfrom ABAP
  8. cds-entra-idMaps Microsoft Entra ID groups and app roles onto cds.User rolesfrom CAP

Details

Sources5
The discovery passdiscovered herechecked
npm registrydiscovered herechecked
npm registry, @sap/ams-devversion, releases, installschecked
README.mdquoted, and what the entry declareschecked

Sources are graph entities: the same page may back several entries, and an unreachable source flags every row that rests on it.

Compatibility and provenance
runtimesnode
declared for>=8
latestv3.0.2
first release
releases and cadence26, ~38d median
discovered viaThe discovery pass, npm registry
first seen in the atlas
ecosystem and domaincap, developer-experience
History in the atlas1
  1. First seen.
For your agent