-
Notifications
You must be signed in to change notification settings - Fork 1
Home
AREasy is a powerful runtime used to manipulate data flows and Remedy development objects, managed by one or more BMC Remedy AR System instances. This application could be used directly in Remedy workflows via a dedicated FILTERAPI plugin or calling specific runtime processes.
**AREasy **environment is able to work in a client-server configuration or as standalone utility, allowing integrated Remedy environments to extract, exports, import or update data outside of internal workflows, or to deploy and export workflow objects in standard format or binary format. Using the runtime engine and API you can create your own actions, to integrate third party environments or to allow data exchange between Remedy AR System resources and other systems and applications.
The most tangible outcome of AREasy is a bunch of some workflow operations (called actions) that could be executed from command line or using Remedy workflow objects, to manage server workflows (data and definitions), to maintain foundation data for ITSM suite and CMDB data (CIs and related details/relationships) and to perform common administrative activities related with BMC Remedy AR System server. Additionally, AREasy Runtime is providing a simplified Java API to create ARS plugins, hosted and executed by AREasy server but called from Remedy workflows. This is possible because AREasy is delivering generic plugins that could enables communication between AREasy plugins and Remedy workflow:
- FILTERAPI plugin which provides a common I/O channel to call (synchronous and asynchronous) and receive output from external processes and workflows implemented outside of Remedy.
- AREA plugin, which can replace actual C or Java AREA plugin, having capabilities to configure and design authentication chain and workflows, based on your needs.
Beside on these “abstract” plugins, AREasy delivers (into a separate module) two specialized AREA plugins, for LDAP authentication and for single-sign-on supporting NTLM (v1 and v2) and also Kerberos. Typically, AREasy is used as a central bus for integration, for third party systems and applications which should exchange data with AR System server. AREasy has possibility to communicate with the ARS servers in a synchronous mode (based on FILTERAPI module) but also in an asynchronous mode (running binary client from the workflow as a normal process or outside of ARS workflows). For example, if you will try extract data from an excel file during an workflow execution and to save data you should run the runtime client implemented in FILTERAPI - to receive a synchronized answer with your workflow, to bring data in real time and then to save and process it.
This parsing engine and actions are already implemented and distributed with the runtime (for the most common data formats), and, speaking for this scenario, you should only implement an additional filter object which should call the FILTERAPI option (specifying AREasy string value for the FILTERAPI name) into a Set Field action, defining the input command and mapping the form field which should receive the answers (the parsed values). So, AREasy could help you to interrogate and integrate other applications and data-sources with minimum effort, reducing dramatically the time for integration implementation. One of main advantages of using AREasy in server mode is that the actions implemented and deployed in the runtime container, could be called using impersonation mechanism, avoiding unmanaged transactions or other system constraints (like licensing policies, transactions with the same user from multiple hosts, etc.).
If you want to execute a user workflow and one of the steps cannot be implemented with ARS objects and definitions, (e.g. if you want to manage some external data inside of your workflow execution session - that means that the current user should keep his console open but in the same time, the same user should be connected on the external service to collect different data and to bring it in the workflow) AREasy will manage all these ARS external actions, working with a different user session but impersonated by the current user.
Depending by your needs (and your specific environment configuration) AREasy could have the following patterns:
Server – starts a runtime execution instance and listens commands (that will specify already and registered AREasy actions) through a TCP socket, to be executed. The call could be initiated by other AREasy instances that could run as a standalone clients or as a plugged clients in Remedy workflow (through FILTERAPI plugin). This server mode could be started manually using scripting command or via Remedy FILTERAPI when the AR System server is started is triggered a specific event.
Client – launches execution of a dedicated AREasy action (already registered in the runtime mapping) through a specific command line, calling the runtime server that could be located locally or on a remote server.
Standalone (or runtime mode) – starts the runtime and executes in the same instance a specific action command (already registered in the configuration) and delivers the output at the end of process execution. Actually this AREasy pattern is able to call and execute without to keep open a communication channel with other AREasy instance or with a Remedy server (the communication pipes) are open only during workflow execution implemented by the fulfilled action.
An AREasy installation instance could be used in any pattern configuration explained before or you can use all of them in the same time. AREasy supports Windows platform (Win XP, Win 7/8, and Windows Server 2003-2012) and any Unix/Linux distribution. Also, AREasy is able to communicate with BMC Remedy AR System server versions 7.5, 7.6.x or 8.x. Runtime Framework
The runtime is the main part of AREasy application, having capability to assume input parameters, to parse them and to compose runtime syntax to call different actions. The actions are already implemented Java classes, having a special coding format which are registered in the runtime configuration files.
When the runtime is called will be created an instance of Runtime Manager component that could run in one of these three options described before: server, client or standalone. To differentiate these pattern you should start the runtime specifying -mode parameter. To start in standalone mode it's enough to ignore this parameter. Another way to call a different type of runtime is to execute a specific binary (from $AREASY_HOME/bin folder) which can do only one of these running patterns: areasy.sh - is the client mode, server.sh - is the server mode, etc. If you want to start the runtime in server mode, all the other parameters will be ignored. If you want to execute an action (so to start the runtime in client mode or standalone) you need to specify all necessary parameters to define a complete command, and the most import is to specify the action name which can be pointed out using -action parameter name.
In case you need help to see how the command line looks like you need to execute help action or help option (parameter): areasy -action help -call or areasy -action -help. When you are starting runtime manager in the client mode you can use two optional parameters to specify the server host and the TCP/IP port for connectivity to the runtime server. So, in this scenario the runtime server is running on a specific machine and the runtime client is called from another machine (e.g. your workstation). To start the runtime in the standalone or client mode always you must call an action, specifying parameter -action and then a value indicating the action name registered in the runtime configuration sectors. This configuration is stored in properties files (the main file is cfg/default.properties) and the action name is given by app.runtime.actions properties. AREasy runtime is coming with a special set of already implemented actions to manipulate data and workflow objects from an AR System server or from ITSM applications. To start the execution of an action which should be connected to the AR System server you must use specific action parameterization to identify a specific AR System server or to configure the runtime instance (in cfg/default.properties configuration file) to have a permanent connection to AR System server. The most significant out-of-the-box action are:
System actions - the runtime delivered a set of actions to work with the runtime container: start, stop, status, echo, clean, help, etc. As special workflows, system actions include a specialized one to install AREasy modules, plugins and service packs without to have downtimes in AREasy server instance. Also, there is a system action that can change online and in real time runtime configurations.
Productivity actions for administration – AREasy provides a complete set of actions to manage Foundation layer from AR System server. These actions have been designed allow ARS administrators to bulk configure licenses, permissions, functional roles and support group membership to specific users. The most important actions provided in this area are:
set/remote system licenses
set/remote application permissions and the corresponding licenses
set/remote unrestricted access
set/remote restricted access for one or many company entities
set/remote functional roles
upload and rename support groups
set/remove support group membership for specific user
These actions really are useful when you have to do specific admin operations many times or when you want to provide deployment packages for an ARS implementation, building procedure to upload and to initiate foundation layer. For instance if you want grant ten thousand Remedy users with different type of licenses (system and application licenses) you can create an excel file, put all the details there are then you can launch AREasy in runtime mode to execute this grant action (-action admin.set.system.license and/or -action admin.set.application.permission) reading data from that excel file.
Generic data management – the runtime is able to execute standard data manipulation actions like:
Data insert in any Remedy form, taking into account the Remedy server-side workflow and disable it.
Data update using complex search and identification keys
Data remove from any Remedy form (with or without workflow)
Data merge taking into account all merging options supported by targeted AR System server.
ITSM operations – AREasy is coming with large set of actions to manipulate ITSM specific data. The most important action are:
Assign a specific support group to an incident
Set incident owner
Create/update configuration items
Make relationships between two CIs
Create/replace/remove people relationships with different CIs
Remedy development objects operations - The actions from this area are able to export and import workflow definitions in standard format and also binary format. More than this, AREasy is able to extend the manipulation actions to the field level (but in binary format) and you’ll be able to transfer one or more fields (and other workflow objects) from one server to another.
Specific system administration operations – The runtime include pre-prepared actions for AR System services administration like:
arsystem service monitor
email engine monitor
license usage monitor and reporting
Additionally, AREasy provides wrappers that can connect and read data from different data-sources and then to can call specific actions that will use extracted data from sources to compose the complete command. The most advanced wrapper is an AREasy module called Advanced Automation Runtime that has a GUI and related workflow developed as a Remedy deployable application.