Introduction
This is an introduction to the Ataccama Admin Centre serverConfig and runtimeConfig files:
- What the files are and where to find them
- How to setup security on the Admin Centre UI itself
- How to setup an online service endpoint on Admin Centre
- How to setup Admin Centre to enable the run of schedulers, workflows and plans / components
The intended audience for this article are Power Users for Ataccama ONE. Power Users may have built some plans / components / workflows / schedulers / online services, and are now looking to host them on a server environment.
What is the Ataccama Admin Centre?
The Atacccama Admin Centre can also be referred to as the “ONE Runtime Server”. For the purposes of this document, we will refer to is as the Admin Centre.
![](https://uploads-us-west-2.insided.com/ataccama-en/attachment/13665b53-e132-4524-b920-db51383fec5c.png)
Admin Centre is a monitoring and administrative tool that performs a variety services¹. The services include allowing users to invoke workflows and plans, and automate built jobs. In Admin Centre, jobs can be triggered automatically on time schedule or manually on an adhoc basis.
¹ For More information see the Runtime Server Development Guide (requires support portal login)
Where is Ataccama Admin Centre?
In a typical enterprise set up, Ataccama Power Users have Ataccama ONE Desktop installed, which gives you the ability to ‘spin up’ an Admin Centre environment locally. A local environment is ideal for development and unit testing.
At the server level, there is typically one Admin Centre installed per environment: e.g. one in Dev, Test, and Prod. Depending on use case, some customers install more than one server per environment to suit their needs.
What are the serverConfig and runtimeConfig files?
The serverConfig and runtimeConfig are xml files essential to starting the Ataccama Admin Center.
The Admin Centre has various components (link), the serverConfig file is where you would instruct the Admin Centre on the components to start up. Each component has specific properties that need to be defined. The most common components are:
- Http dispatcher: an http web page component that allows users interaction with Admin Centre.
- Online service: component that hosts endpoints to accept API calls. The endpoints would be connected to a .plan or .comp file to perform various operations, e.g. reading or writing data to applications, or validating data against some rules.
- Workflow: component that allows the running of workflows.
- Scheduler: component that allows the running of schedulers.
RuntimeConfig file, on the other hand, is configuration for connections between the Admin Centre and other services. Some of the possible connections that could be included are:
- Connection to keycloak for securing the Admin Centre
- Connections to databases, and related database drivers
- Connections to other applications or servers, e.g. Ataccama ONE applications, SMTP server, S3 bucket etc.
- Definitions of file system folder shortcuts
These connections would be used in .ewf workflows, .comp components or .plan plan files.
Where do I start?
You should start with building a set of serverConfig and runtimeConfig files on your Ataccama ONE Desktop.
Configure everything you can on your local workstation.
Components like workflow and scheduler components should be straight forward: they only require a reference to a designated folder on your file system. Database connections can be tricky, as sometimes due to networking constraints, database connections might only be allowed from the application server on your dev/test/prod environments rather than your local workstation.
Once you have a configured set of files, attempt to start up your Admin Centre. There are multiple ways to do this depending on licensing; you might be able to start from the workstation’s command line, or you might need run the start.bat file within your ONE Desktop.
When you are satisfied the configuration is correct locally (more below), you can then make copies of these files and deploy them to your dev/test/prod environments. Some details in the files (e.g. keycloak and database connections) will need to be different per environment.
A few links to our official documentation portal for background information:
- ONE Runtime Server Development Guide - link
- Server Configuration - link
- Server Components - link
- Runtime Configuration - link
- Server Security - link
Where are these configuration files?
The Ataccama Admin Centre is included in the Ataccama ONE Desktop distribution. It should come with default.serverConfig
and default.runtimeConfig
files.
The Ataccama Admin Centre also comes with two additional that need consideration: one-executor.serverConfig
and one-executor.runtimeConfig
files.
The files provided are a template only, they can be inspiration for you to create your own set of serverConfig and runtimeConfig files.
You can find all of the files in the <build>/runtime/server/etc
folder of your installation.
Sample project structure
The configuration of the files must be in line with your project structure. For the examples that follow let’s use this sample project structure (image below). In the example (non PaaS) project I am intending to run one Admin Centre to host plans and workflows for mdm and rdm projects:
![](https://uploads-us-west-2.insided.com/ataccama-en/attachment/7f46cdab-e516-4444-a5c9-308c1535f89e.png)
Best practice around actual project structure itself is a topic for another time, shown here is one example of project structure. We are focusing on how to tailor your .runtimeConfig and .serverConfig files to fit your project structure.
It is recommended that the project folder structure on your local workstation is replicated to your server environment.
The easiest way to ensure this is to synchronise the project with a version control software, for example: Git. The process for developing configurations is to: build for your local computer and test, when successful, tweaking the config files as required for transferring to the server environment. Within Ataccama the folder structure will be the same on the server as it is locally.
If you are considering also synchronising the serverConfig and runtimeConfig to the application server using Git, CAUTION: as mentioned above - the serverConfig and runtimeConfig files on each environment may be different, so be careful when merging branches between different environments as not to overwrite environment-specific configuration files.
What is inside the configuration files?
ServerConfig
Let’s take a look at default.serverConfig
file (a redacted version with only selected components is included below for illustration purposes). The file is well commented to what each component does. If you need to activate a component, simply remove the comment tags around that component, and change the properties as necessary.
At the top of the file you can see that the internal port for starting the runtime server will be 7777, next is the default.runtimeConfig
reference. This means at runtime, the default.euntime configuration will be used in conjunction with this default.serverConfig
file.
You can rename these files if you want, you will just need to make sure your server start script references the correct .serverConfig file, which in turn references the correct .runtimeConfig file. Making copies and renaming startup configuration files can help keep local configuration changes from impacting configurations needed for servers. For example a user might maintain a local server start script labeled start_local.bat, that points to a local.serverConfig, thus helping to ensure changes needed locally do not overwrite the default files.
See attachment: ServerConfig
RuntimeConfig
Here’s the default.runtimeConfig
. It’s has structure but no content.
Users can generate runtime configuration files using One Desktop. Follow this document to export a runtime that you can use for building a runtimeConfig file for your Admin Centre.
See attachment: RuntimeConfig
Continued on Ataccama Admin Centre: ServerConfig and RuntimeConfig for beginners (Self-managed installations) 2/2
Links to the legacy documentation portal are no longer available. Read about the changes and how to access our documentation here.