PR for management of Systems/Keys API welcome?

[MatthiasWinzeler]

Hi folks

As you probably know, whenever a new SAP system is set up or the underlying VM is recreated, one has to access the launchpad on https://me.sap.com/licensekey, register the new system (or update an existing one) and generate a new license file.

Since we are moving to the cloud, where VMs might be changing more often than traditionally, we'd like to automate the following tasks:

• List/Create/Update/Delete of Systems in the Launchpad
• List/Create/Update/Delete of License Keys in the Launchpad

Would you accept a PR that extends this module with the functionality above?

I quickly checked what API is used for managing Systems/License Keys and it appears to be a quite nice ODATA API on https://launchpad.support.sap.com/services/odata/i7p/odata/bkey, which should be rather easy to write a client for.

This API is also protected by the same authorization methods (cookies etc.) as the other APIs compatible in this Ansible Collection, so I thought the new API would fit nicely in your already existing Ansible Modules; I could reuse your foundation and just add a new module that talks to an additional API.

I am not sure how stable the i7p API above is and whether it would break in the future, but I think you have the similar issue with the currently compatible APIs (software download etc.) anyway.

What do you think?

[sean-freeman]

Hi @MatthiasWinzeler

Your suggestion is possible, and would be an Ansible Module in itself that re-uses the underlying Python Modules; as you rightly state. See the Development document for the code structure.

Please keep in mind, the Ansible Module should retrieve the data but not run any commands on the target system; a higher-level Ansible Role would be responsible for executing the Ansible Module and then running other Ansible Tasks for CLI commands or API calls to apply the license to a target system.

You'll need to interpret the metadata, for example the main endpoint and probably these endpoints related to your use case:

https://api.sap.com/odata/1.0/catalog.svc/$metadata
https://launchpad.support.sap.com/services/odata/svt/systemdatasrv/$metadata
https://launchpad.support.sap.com/services/odata/installationmanagementsrv/$metadata
https://launchpad.support.sap.com/services/odata/bkey/$metadata

Due to conflict of interest, I would be unable to review any PR. Other SLL-OSI project maintainers will be able to review and approve a PR, so long as it follows the correct procedure for checking User permissions for the SAP Customer Number (SCN), handling Installation Numbers and the Licences therein.

[MatthiasWinzeler]

Hi @sean-freeman - thanks for getting back to me!

Please keep in mind, the Ansible Module should retrieve the data but not run any commands on the target system; a higher-level Ansible Role would be responsible for executing the Ansible Module and then running other Ansible Tasks for CLI commands or API calls to apply the license to a target system.

Agree. The module would only interact with the SAP Launchpad API to register the system, create and download the license keys. The installation of the license key is out of scope, but if ok for you, I'd like to add those commands (should be some one liner i.e. saplikey -install or the HDB equivalent) to the example section, since that's what users usually would want to do anyway.

You'll need to interpret the metadata ...

Thanks for the links - I went through those and I can see some references of Systems, Installations etc. in those links. However, I saw that the SAP UI mainly interacts with another API, which is https://launchpad.support.sap.com/services/odata/i7p/odata/bkey - I am not sure whether the other ones are still in use, so I would just use the i7p one to be as closely aligned to the UI as possible.

I realized that while the API surfaces Systems and License Keys as separate entities, the UI only allows to create those two entities together. I.e. you prefill the System Data, but it's only persisted once you create a License Key for it. The same goes for updates.

Thus, to closely model the UI flow, I'd propose to come up with the following task:

  tasks:
    - name: Create license file from me.sap.com
      community.sap_launchpad.license_key:
        suser_id: "{{ suser_id }}"
        suser_password: "{{ suser_password }}"
        installation_id: 123456789 # this would be manually looked up by the user. I think it's ok to not support creation of installation, since that's usually a company-wide one-time task.
        system:
          id: B01 # free text field
          name: Test-System # free text field
          type: Development system # one of the supported system types per SAP API
          database: SAP HANA database # one of the supported database types per SAP API
          operating_system: Linux # one of the supported OS per SAP API
          infrastructure: Public - Microsoft Azure # one of the supported infrastructure per SAP API
          product: SAP S4/HANA # one of the supported products per SAP API
          version: SAP S4/HANA 2022 # one of the supported product's versions per SAP API
        licenses:
          - type: Standard - Web Application Server ABAP or ABAP+JAVA # one of the supported license types per SAP API
            hardware_key: B1234567890 # free text field
          - type: Maintenance Entitlement
            hardware_key: B1234567890
        delete_other_licenses: true # optional field to delete older licenses of this system if new ones are added

      register: license_key
      # license_key would contain the license keys in raw format, plus some other handy information (i.e. the created system number etc.)

This task would be used for creation as well as update, i.e. if the system already exists, it's updated in an idempotent way. Deletion of Systems and Keys would be supported as well with state: absent.

In order to decide whether a given SID already exists, I would suggest to check if a certain SID for that Product Version already exists (lots of customers reuse SIDs for S4HANA and SAP HANA DB, so they have multiple systems with the same SID).

This interaction would be backed by interactions with I7P - I did a small test with curl and it seems to create the systems and keys fine.

Due to conflict of interest, I would be unable to review any PR. Other SLL-OSI project maintainers will be able to review and approve a PR, so long as it follows the correct procedure for checking User permissions for the SAP Customer Number (SCN), handling Installation Numbers and the Licences therein.

That sounds good. I am not sure what SLL-OSI is, but I understand that there that there is actually someone who could eventually review the PR?

Also, if you have any further information regarding the correct procedure you mention, I'd be very glad.

[kksat]

@MatthiasWinzeler @sean-freeman inspired by your discussion I took a liberty and created ansible modules that manage license with saplikey program on the host. Modules are available in sap.sap_operations collection:

saplikey_get_info - get HW key and other information with saplikey

saplikey_show_info - list all installed sap licenses

saplikey - manage sap license (ensure they are present /absent).

See detailed documentation with examples in the links provided.

@MatthiasWinzeler very looking forward to your PR with code to get licenses from SAP support portal.

[sean-freeman]

@kksat Please do not link or discuss disparate and unrelated code repositories that are vendor-specific / outside of the SAP LinuxLab Open-Source Initiative (SLL-OSI). This confuses end users, it is only permitted for referring to features which are added by a vendor that have not been PR'd/integrated into the upstream; your code base is completely unrelated.

Please speak with your governance representative regarding the agreed by all parties SLL-OSI code release strategy (i.e. upstream (github.com/sap-linuxlab) > midstream (github.com/vendor) > downstream (vendor product)).

I am reporting this comment to the SLL-OSI Governance Board.

[kksat]

@sean-freeman thank you for your comment and opinion. Please let me know the results of you "reporting this comment to the SLL-OSI Governance Board." as soon as it will be available.

[sean-freeman]

@MatthiasWinzeler As suggested before, you will need to investigate each OData Metadata XML file to identify the different action paths. In the examples I provided, you should be able to identify the paths you need.

For example as suggested above: https://launchpad.support.sap.com/services + /odata/bkey/$metadata

The i7p is a prefix seemingly used for authentication paths, and therefore the below provides an identical metadata file: https://launchpad.support.sap.com/services + /odata/i7p + /odata/bkey/$metadata

Using any metadata XML (keeping with your example), it is possible to read the <edmx:DataServices><Schema><EntityType> to see the API endpoints and expected parameters for each endpoint, such as:

/odata/bkey/$metadata
-- Installations
-- Customers
-- Products
-- Systems
-- LicenseKeys
-- etc etc

I cannot discuss further, nor can I describe the correct procedure. This is due to conflict of interest. I wish you the best in codifying this for the open-source community.

The SAP LinuxLab Open-Source Initiative (SLL-OSI) project maintainers will be able to review your PR.

[MatthiasWinzeler]

closing as it will be merged with https://github.com/sap-linuxlab/community.sap_launchpad/pull/17