This wizard allows you to create skeleton data set maintenance custom function.
The wizard allows you to define the fields and data set you wish to store.
The starting point is the custom function name and description:
The name must be at least 2 characters and may not contain spaces or characters invalid for a URI (such as “:”, “/”, “?”, “&” etc.).
This name becomes the name of the custom function. Please note that the first letter will always be capitalized.
The description will become the description for the custom function.
The next step is the repository settings:
The repository name is the location where all the components of the custom function will be created. This repository must not exist as it will be created with the rights of the user creating it.
You can also choose to add the custom function to an existing repository. The effect of doing that is that no configuration will be created in the new repository. Instead, the existing repository will have the new repository added as an included repository and the custom function rule will automatically have the new function name added so that the deployment of a single configuration can activate multiple custom functions. The rule set that manages the different services is named CustomFunctions.
Next you enter the fields you wish to maintain:
You should enter one field per line. Fields may not contain spaces and/or special characters.
Next are the field labels:
Labels are free format and must simply contain valid text.
The final step is to provide a database and data set name:
Once the rules are generated, you will need to check these database settings against the configuration.
The last step is to review your choices and click on Continue to generate the repository.
This wizard allows you to create administrative definitions for JDBC connections to a number of common databases.
This wizard does NOT install the requisite driver classes and does not configure the relevant class path to include those same driver classes.
The starting point is the selection of a database provider:
If your database is not found in the list, you must refer to the documentation library for information on how to install the definitions manually.
The next step is to select a database server to connect to:
You will have the option of creating a new database server or using an existing one.
Note: For connectivity purposes, and defined server other than template servers can act as a database server.
If you choose to create a new database server, you must supply a server name and the IP address or host name for the server:
The name must be at least 2 characters and may not contain spaces or characters invalid for a URI (such as “:”, “/”, “?”, “&” etc.).
This name is only relevant within the Octopus console, it does not have any network level significance. If you have a physical server that is running multiple instances of the same database on different ports, you will need to provide a unique name for each instance.
The next step is the port number:
The wizard already knows the default port number for each of the databases it can create definitions for. If no port number has been given to you, we suggest you try the default provided by the wizard.
The final step before completion is to provide a User ID and Password for the service account you will use to connect to the database:
This account must have the requisite credentials to perform any type of procedure or query that you wish to execute against the database.
The last step is a confirmation that you have completed your choices:
Click on Continue to generate the required database definitions.
This wizard allows you to create skeleton REST services with a JSON payload.
The wizard allows you to select the REST methods and HTTP schemes used, authentication methods and credential storage options.
The starting point is the service name:
The name must be at least 2 characters and may not contain spaces or characters invalid for a URI (such as “:”, “/”, “?”, “&” etc.).
This name forms the endpoint name for the REST service and will also be used as the prefix for all rules and data files created by the wizard to ensure that multiple REST services can be merged into one. For the purpose of this, the service name’s first letter will always be capitalized, however the endpoint name is not case sensitive.
For example: If you enter a name of “helloWorld” and deploy to the proxy server, the endpoint name on the local machine will be:
http://localhost/helloworld
The next step is the repository settings:
The repository name is the location where all the components of the service will be created. This repository must not exist as it will be created with the rights of the user creating it.
You can also choose to add the service to an existing repository. The effect of doing that is that no configuration will be created in the new repository. Instead, the existing repository will have the new repository added as an included repository and the service entry rule will automatically have the new service name added so that the deployment of a single configuration can activate multiple services. The rule set that manages the different services is named ServiceEntry.
You then need to select the methods that you plan to use for the service:
The default is GET and POST. You can of course add missing methods later if you wish, by editing the rule sets. The rule set that governs the available methods is _V1.
The next step is to select the schemes allowed for the service:
You must select at least one scheme. Please note that unless you have a valid certificate in place, testing without http can be verify difficult with modern browsers. You can always change the schemes later by modifying the rule set _Service.
Next you will be asked if you require authentication:
No matter your choice, a rule set named _authentication will be created so that you can modify it later.
If you choose to include Basic or Parameters authentication, a rule set named _CheckUser will be created to verify the provided user name and password.
If you choose to include IP address authentication, a rule set named _CheckIP will be created to verify the incoming IP address.
Your choice of credential store is next:
Depending on your choice, you will be asked some follow up questions. For example, for storage of users or IP addresses in a CSV file, you will be asked to supply some initial users or IPs:
The content of this input field will be written to a data file named _userList for User IDs and password.
The content of this input field will be written to a data file named _ipList for IP addresses.
Please note that passwords in this scenario remain insecure.
Other credential stores will ask you similar relevant questions to establish an initial template rule set. If you choose “Data set” or “Database” as your credential store, you will also be asked to provide a password hashing algorithm:
The default hash salt is randomly derived for maximum security. You can of course change it to suit your environment.
Important: The data set and database options will require your selected database to be added with the relevant driver to the service configuration before deployment. If you are using a database, you must have the relevant table already created and populated.
For all authentication options except LDAP, it is recommended that you create a custom function to allow the service owner to maintain the users and/or IPs stored in the credential store.
Once authentication is defined, you need to provide a JSON formatted error message template:
This template is used to signal service level errors to the user (failed authentication, invalid methods etc.). It is not intended for data level errors, which is represented in the next page:
This is the response template that will be used for each of the methods (GET/POST/PUT/DELETE) upon execution. Data level validation errors should use this template, as should success messages. The status returned should be either “success” or “fail”.
Once your template is completed, there is only one more step, which is to review your choices and click on Continue to generate the repository.
