Sap profile gatherer

[arbulu89]

Edit: I have decide finally to go with the map way. See comments below
Edit2:: In the future, we could upgrade this gatherer to return the installed SAP instances per SID in the host, which will be really needed in many checks. We could reuse this gatherer instead of creating a new one

SAP profiles gatherer. It walks the /sapmnt/<SID>/profiles folder to look for profiles.
It only gets the latest profile for each instance (so files ending with numbers or old DEFAULT files are excluded).
It returns a flat structure adding the sid as field.

I have some doubts if it should go in this way, or in "sid as map" kind of tree. Unfortunately rhai doesn't have the groupBy feature. Wdyt?

See example:

[

  #{
    "content": #{
      "SAPDBHOST": "10.80.1.13",
      "SAPGLOBALHOST": "sapnwpas",
      "SAPSYSTEMNAME": "NWP",
      ...
    },
    "name": "DEFAULT.PFL",
    "path": "/sapmnt/NWP/profile/DEFAULT.PFL",
    "sid": "NWP"
  },
  #{
    "content": #{
      "DIR_CT_RUN": "$(DIR_EXE_ROOT)$(DIR_SEP)$(OS_UNICODE)$(DIR_SEP)linuxx86_64",
      "DIR_EXECUTABLE": "$(DIR_INSTANCE)/exe",
      "DIR_PROFILE": "$(DIR_INSTALL)$(DIR_SEP)profile",
      ...
    },
    "name": "NWP_ASCS00_sapnwpas",
    "path": "/sapmnt/NWP/profile/NWP_ASCS00_sapnwpas",
    "sid": "NWP"
  },
  #{
    "content": #{
      "Execute_05": "local ln -s -f $(DIR_EXECUTABLE)/disp+work$(FT_EXE) $(_DW)",
      "Execute_06": "local rm -f $(_IG)",
      "Execute_07": "local ln -s -f $(DIR_EXECUTABLE)/igswd_mt $(_IG)",
      ...
    },
    "name": "NWP_D01_sapnwppas",
    "path": "/sapmnt/NWP/profile/NWP_D01_sapnwppas",
    "sid": "NWP"
  }
] 

[arbulu89]

Edit:
I have decided to go with the tree/map hierarchy. It will be better for consumption, as in essence, it is a tree.
Grouping and doing checks for each SID would be the normal thing in most of the cases.
If a flat map is needed, it is easy to convert this map in that way (doing the opposite is not that simple)
The result would look like:

#{
  "NWP": {
    "profiles": [
      #{
        "content": #{
          "SAPDBHOST": "10.80.1.13",
          "SAPGLOBALHOST": "sapnwpas",
          "SAPSYSTEMNAME": "NWP",
          ...
        },
        "name": "DEFAULT.PFL",
        "path": "/sapmnt/NWP/profile/DEFAULT.PFL",
      },
      #{
        "content": #{
          "DIR_CT_RUN": "$(DIR_EXE_ROOT)$(DIR_SEP)$(OS_UNICODE)$(DIR_SEP)linuxx86_64",
          "DIR_EXECUTABLE": "$(DIR_INSTANCE)/exe",
          "DIR_PROFILE": "$(DIR_INSTALL)$(DIR_SEP)profile",
          ...
        },
        "name": "NWP_ASCS00_sapnwpas",
        "path": "/sapmnt/NWP/profile/NWP_ASCS00_sapnwpas",
      },
      #{
        "content": #{
          "Execute_05": "local ln -s -f $(DIR_EXECUTABLE)/disp+work$(FT_EXE) $(_DW)",
          "Execute_06": "local rm -f $(_IG)",
          "Execute_07": "local ln -s -f $(DIR_EXECUTABLE)/igswd_mt $(_IG)",
          ...
        },
        "name": "NWP_D01_sapnwppas",
        "path": "/sapmnt/NWP/profile/NWP_D01_sapnwppas",
      }
    }
  ]
} 

[CDimonaco]

Just some comments

[CDimonaco]

I know it's old code but we want to refactort this to the default/new constructor convention we have in the other gatherers? To inject dependencies in tests and the default one with the real scenario?

[arbulu89]

I get your point (even though this is not a gatherer code).
Refactoring a bit the code would allow us to test better (in fact, this particular function is not even tested...).
Do you mind if I open a tech-debt ticket in our backlog?
The refactor might not be so trivial, and I don't want to include it in this PR

[rtorrero]

LGTM @arbulu89, thanks! just left you a minor question in the code 👍

[rtorrero]

Here you refer to the "latest" profile names and a bit below, on line :246 you output "New SAP profile found"...
Are these really new or will they be always found everytime this code is run?

[arbulu89]

Well, latest in this context means the "latest valid SAP profile".
SAP has its own backing up system, where old backup files are stored in the same folder, with .x terminology (where x is a digit). It is a bit different for the DEFAULT.PFL but the concept is the same.
The logging simply prints all found profiles.

This code is deterministic, it will always return the same, as long as the Filesystem is the same of course

[rtorrero]

Thanks for the clarification!