Using the Command Line Interface (CLI), it is possible to implement processes and interactions without the user interface in the Datasphere and to automate them using Node.js scripts, for example. An important feature for the usefulness of the CLI in the context of the Datasphere is the provision of CRUD operations, which are considered basic operations in the handling of data elements. CRUD is an acronym and stands for C - creating data elements, R - reading data elements, U - updating data elements and D - deleting data elements. The handling of the individual elements is shown below. It is possible to edit a list of objects:
| Object Name | Command |
| Local Tables | local-tables |
| Remote Tables | remote-tables |
| ER Models | er-models |
| Analytic Models | analytic-models |
| Task Chains | task-chains |
| Data Flows | data-flows |
| Replication Flows | replication-flows |
| Transformation Flows | transformation-flows |
| Data Access Controls | data-access-controls |
| Business Entities | business-entities |
| Fact Models | fact-models |
| Consumption Models | consumption-models |
| Intelligent Lookups | intelligent-lookups |
| Contexts | contexts |
| Types | types |
The local tables serve as an example for illustrating CRUD operations in this blog. The following command serves as the basis for handling CRUD operations:
datasphere objects [object-type][commands]
After the command has been executed, you are forwarded to a dialog. The space ID must always be specified here and, depending on the command, a JSON file to create an object, the technical name of an object to delete it or both to update a view.
Create
The objects listed above can be created using the following command:
datasphere objects local-tables create --space "Space ID" --technical-name "viewName" --file-path "path.json"
Make sure that a JSON file is used as the basis for the objects. The following template can be used for local tables:
{
"definitions": {
"Template": {
"kind": "entity",
"@ObjectModel.modelingPattern": {
"#": "DATA_STRUCTURE"
},
"@ObjectModel.supportedCapabilities": [
{
"#": "DATA_STRUCTURE"
}
],
"@EndUserText.label": "Template",
"elements": {
"Column1": {
"type": "cds.Decimal",
"precision": 38,
"scale": 19,
"@EndUserText.label": "Column1"
},
"Column2": {
"type": "cds.String",
"length": 4,
"@EndUserText.label": "Column2"
}
,
"Column3": {
"type": "cds.Integer",
"@EndUserText.label": "Column3"
}
,
"Column4": {
"type": "cds.Date",
"@EndUserText.label": "Column4"
}
}
}
}
}
Read
The following command can be used to read the objects listed above. A JSON file is returned here. The JSON file is filled with the semantic information of the object and, depending on the object, is similar to the template provided for local tables.
datasphere objects local-tables read --space "Space ID" --technical-name "viewName"
Update
The objects listed above can be changed using the following command. Updates can be made via changes to the JSON file. It is recommended to execute a read command first and to change the JSON file that is obtained by the read command.
datasphere objects local-tables update --space "Space ID" --technical-name "viewName" --file-path "path.json"
Delete
The objects listed above can be deleted using the following command. By specifying the space and the technical name, the objects are uniquely identified and can therefore be deleted.
datasphere objects local-tables delete --space "Space ID" --technical-name "viewName"
For further information, please check SAP Help.
Example 1 - Creating and Deleting a Local Table
A simple use case is described here, in which a local table is created and deleted again. Both take place in a space called "CLI". In the first step, a JSON file is required. In this example, the previous template is used as the file. Once you have prepared the file for your requirements, you can execute the Create command. As can be seen in Figure 1, no parameters are specified in the command, which is why a dialog takes place via the CLI. Here you can enter the space ID and the path of the JSON file. If everything has worked, you should get a successful response. The table should then be generated as shown in Figure 2.
To delete the table, you need the delete command listed above. Again, no parameters are specified here, which is why you have to specify the space ID and the technical name of the object in a dialog. By specifying the correct object, it is deleted from the space.
Example 2 - Read an object and create it in a new space
This scenario represents a useful process for exchanging objects in a space-to-space sharing via the CLI. In addition, such logic could be partially automated using scripting languages so that all or selected objects can be exchanged by specifying the source space and the target space. However, only a simplified use case is shown here in the blog, which is intended to represent the basic function.
Unlike above, in this example the commands are executed with the addition of parameters. First, an object must be selected, which is written to a selected directory via the CLI in the following step. Once the object has been successfully written to the directory, it can be created on the other space in the next step. As the technical name only has to be unique within a space, this step also works without adapting the JSON before the upload. Once the JSON file has been uploaded with the correct parameters, the table should be available in both Spaces, as you can see in figure 5.
Both use cases are relatively simple in this scenario, but efficient. As already mentioned, the use cases can be expanded very widely and offer huge potential. If you have any questions about CLI or if you have an exciting use case, please feel free to get in touch.
- SAP Managed Tags:
4 Comments
