API version of the toolkit about oasislmf HOT 7 CLOSED

The package/toolkit isn't just a CLI, it contains a Python class framework for creating and working with model lookups and generating keys as objects or files (oasislmf.keys.lookup), exposure management including all the workflows currently available via the CLI including generating keys, Oasis files, losses and running models (oasislmf.exposures), and a set of Python utilities used in the class framework but which can also be used for general purpose stuff independently of that (oasislmf.utils).

The existing CLI uses this class framework and utilities, but there is nothing to stop external users of the package from writing their own scripts, using this Python framework, for performing workflows to suit their own requirements.

from oasislmf.

Okay, but the point is that they might want to run against a hosted system via the web service APIs and not locally.

from oasislmf.

Understand. My point was that the CLI component of the oasislmf package comprises of the cmd subpackage. Other subpackages are not CLI components, but functional/logic components.

from oasislmf.

@mpinkerton-oasis This are three steps to implementing all of this:

1. create a new workflow subpackage with a single workflow module, and move all the workflow logic currently embedded in the CLI command class module (oasislmf/cmd/model.py) into the new workflow module; this workflow logic module will be completely independent of the CLI and will just consist of top-level methods for performing the workflows;
2. refactor the CLI command classes to use the relevant methods in the workflow module - you will still need to capture the command line arguments but they should all be just passed to the relevant method in the workflow module, without any processing
3. create a new API CLI command module in the command subpackage (oasislmf/cmd) - this should contain one API command class per workflow; the classes will extend oasislmf.cmd.base.OasisBaseCommand but their logic will use a sequence of API calls to implement the workflow; the API subcommand will be a top-level subcommand, e.g. oasislmf api, and then the each workflow command will have an appropriate name, e.g. oasislmf api generate-oasis-files

1 and 2 are relatively simple tasks, but 3 will be more complex. Arguably you could view the API CLI as just a way of performing the same tasks as you do now with locally installed models using oasislmf model but with remotely installed models. So you could opt not to create a separate API CLI subpackage, but just augment the existing CLI command classes to include an API option, so, e.g.

oasislmf model generate-oasis-files --api <rest of args>

But this would make the existing CLI command classes more complex, so the first is probably a better option.

from oasislmf.

The workflow methods will still need to use the existing exposure manager oasislmf.exposures.manager.OasisExposuresManager to do the Oasis files generation, and to make calls to the utilities oasislmf.utils. So the workflow methods won't be that complex.

from oasislmf.

Notes on CLI:

oasislmf api --help
usage: oasislmf api [-h] [-V] [-C CONFIG] {run,list,delete} ...

positional arguments:
  {run,list,delete}
    run                 run
    list                list
    delete              delete

Example list:
oasislmf api list --api-server-url=http://localhost:8000 [--models / --portfolios / --analyses]

Example run:
oasislmf api list --api-server-url=http://localhost:8000 --model-id=1 --source-exposures-file-path=./source_loc.csv --analysis-settings-json-file-path=./settings_file.json

from oasislmf.

Still needs, create and healthcheck

from oasislmf.