Getting started with Data Studio
BMC AMI DevX Data Studio
provides a single interface to visualize both mainframe and non-mainframe data in a common and intuitive manner.
helps the developers and data architects to efficiently manage both test and production data and meet the demands of digital business.
Product architecture
The following figure illustrates the
Data Studio
architecture:

Data Studio
is a distributed product, which requires various separate components to be installed, typically on multiple networked computers. All the components must then be configured to properly communicate among themselves and with other BMC AMI DevX products. The preceding figure illustrates the relationships between the various components by breaking them into three logical layers (Client, Server, and Execution), based on their roles in the overall architecture.
Client layer
The primary users of
Data Studio
work directly with the applications from the Client layer. The Client layer contains the
(with the
feature included), and several additional applications and utilities, such as ConverterPro, ComparePro, Homebase, Repository Management Utility and so on.
Server layer
The Server layer contains one server application, File-AID Services (FAS). FAS is primarily responsible for management of Data Privacy projects - that include definitions of data elements, privacy rules and so on. Data Privacy projects and other privacy-related artifacts are stored in the Data Privacy Rules Repository. During the execution of data processing requests, FAS provides analysis of data layouts and detects which fields need to be disguised and which rules need to be executed for which fields.
FAS also serves as a hub for other Enterprise data components by sharing some configuration settings, such as the connection information to
BMC AMI Common Enterprise Services
(CES) and licensing configuration.
On Windows, File-AID Services installation includes a separate Windows service,
File-AID/EX
communication manager, which serves as a proxy in communication with the execution servers. It also provides access to the
repository, which stores definitions of requests and various artifacts that
works with, such as applications relationships or selection criteria.
There are two types of communication managers used by
Data Studio
:
- Local, which are installed as part of. Local communication managers are used by default and typically don't require any configuration. These communication managers are launched in a separate Windows process (named fa_commgr.exe), when it is required for communicating execution requests or for browsing the repository. Local communication managers define their own lists of connected repositories, including local (non-shared) repositories, and support communication with local (embedded into) execution servers.
Shared, which are installed with File-AID Services (currently only on Windows), as a separate Windows service. Shared communication managers provide access to all Enterprise Data clients to the same sets of repositories. They are also a good option for automated unattended execution of data processing requests, such as execution of
Total Test
-steps from a Workbench CLI environment.
Execution layer
The Execution layer contains the components required for execution of data processing requests.
Data Studio
supports two types of requests—mainframe and distributed.
The mainframe requests typically come from BMC AMI DevX File-AID mainframe products, such as
BMC AMI DevX File-AID/RDX
,
, or
. To apply Data Privacy rules, the File-AID products launch File-AID Rules Engine (FARE), which runs in IBM Java Runtime Environment. FARE makes calls to FAS for instructions on which rules need to be executed and then applies those rules to certain fields.
The distributed requests are handled by
File-AID/EX
execution servers and are installed on Windows or UNIX/Linux platforms. The
feature of
includes a local execution server that is launched automatically when the local
applications need to communicate with it. Local execution servers are not intended for processing production data or automated (batch) executions, but for developing and debugging
specifications. Per automated executions and processing large volumes of data, use stand-alone execution servers which are running as a Windows service or a Unix daemon and which can be shared by multiple users. To support data privacy, execution servers need to have the File-AID Rules Engine (FARE) installed.
A
File-AID/EX
execution server has the ability to access mainframe data via the optional
Executive module.
Use
File-AID/EX
Scheduling Agent for scheduling
(distributed) requests from the mainframe.