Remedy API Quick Reference

The document provides information about the Remedy API, including the C and Java APIs. The C API allows clients to manipulate data by creating, retrieving, updating, and deleting entries, forms, and menus. The Java API provides the same functionality as the C API in a Java environment and is easier to program. Both APIs require certain library files. The document also discusses object relationships and comparisons between Remedy User and API terminology.

Uploaded by

Dileep Prabakar

Available Formats

Download as DOC, PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

614 views

Remedy API Quick Reference

Uploaded by

Dileep Prabakar

Available Formats

Download as DOC, PDF, TXT or read online on Scribd

You are on page 1/ 4

Remedy API Quick Reference:

C API:

The AR System clients use the C APIs to manipulate data. For example, the clients use C APIs to
create, retrieve, update, and delete entries, forms, and menus, and to control workflow. You can
use the C API to extend AR System functionality.

The AR System API contains data structures that store both simple and complex information.
Structures that store simple information, such as the type of value or the product of an arithmetic
operation, serve as the building blocks for complex structures.

The C APIs consist of sets of library routines that you can compile to run on Windows or UNIX
platforms. You can run API programs from a command line or from the AR System; in the Set
Field $PROCESS$ action from an active link, filter, or escalation; or with the Run Process action in
an active link, filter, or escalation.

Java API

The AR System Java API is a collection of Java classes that provide the full AR System C API
functionality in a Java development environment.
The Java API:
• Provides an object model of AR System server entities (also called server objects),
definitions, and data.
• Accesses the AR System server indirectly, through the AR Server Proxy class and methods
on the object model classes.
• Is easier to program than the C API, in part, because you do not have to establish and
manage connections, or manipulate complex setup API parameters. You will find it easier
to use the Java API if you are already familiar with the C API.

JAVA API Requirements:

Windows

• arrpc70.dll
• arutl70.dll
• arapi70.dll
• arapi70.jar
• arjni70.dll
• arutil70.jar
• arjni70.dll

UNIX:

• arapi70.jar
• libarjni70.so (Solaris, AIX, Linux)
• libarjni70.sl (HP-UX)
Some terminology has changed from version to version of AR System and the
BMC Remedy User client, but the API terms have stayed the same so that
code does not need to be rewritten. The following table compares
BMC Remedy User terms with API terms.

BMC Remedy User term C API term

Remedy C API

request entry
form schema

search Get list

create/submit create

display get

modify set

Library files required for API

Library files
In addition to the requirements in the following table, you must have arcatalog_eng.dll in your path
at runtime. Provide the full path to the AR System libraries.

For Windows:

Have arrpc70.dll, arutl70.dll, and arapi70.dll in the path.

For UNIX:

Have libar.a (static library) and libar.so (shared object library).

High-level object relationships

Before discussing specific data structures, it is helpful to understand the highlevel relationships
between AR System objects (see the Form and Application Objects guide for definitions and
descriptions of these objects). As the following figure shows, the foundation of all client
programs built on the AR System is the schema. Although the AR System API still uses schema,
the AR System clients now see schemas as forms. A client must access at least one and can
access many schemas.
Your client program can also have optional menus and containers. Either servers or schemas
(forms) can own containers, which the server uses to create guides and applications.
Applications can contain one to many schemas. Guides can be shared and can contain one to
many active links. There are five types of schemas. The most common, data schemas, contain
data in the AR System database. Join schemas show data from two or more data schemas with a
common matching field, and display-only schemas show data from one data schema. These
latter two schema types do not contain data themselves. View schemas show data from external
database tables and act like data schemas. Vendor schemas acquire data from the plugin service
and act like data schemas. When you modify values in a join schema, you are changing the data
in its parent data schemas.

Each schema must have at least one view (the default view) but can have many views. Similarly,
each data schema must have at least one field but is likely to have many fields. (In actual
practice, every data schema is automatically created with nine core fields that cannot be deleted.
For more
information about core fields, see the Form and Application Objects guide.) Fields come in two
types—data fields and nondata fields (trim, control, page, and table). A schema must have at
least one data field. Nondata fields are optional.

Most schemas have many entries, but a schema can exist without an entry. Although the AR
System API still uses this term, the AR System clients now see entries as requests. Similarly, any
number of filters, escalations, or active links can be associated with a schema or list of schemas,
but these objects are not required. See “Schemas” on page 61 for more information. Both active
links and menus can be associated with a field. While active links can be associated with either
data or control fields, menus can only be associated with data fields. The relationships between
them, however, are exactly reversed.

An active link must be associated with a particular schema. A data or control field can have any
number of active links associated with it. A particular execute-on condition of an active link can
only be associated with one field. Different execute-on conditions in the same active link can
reference different fields. A menu can be associated with any number of data fields, both within
an individual schema and across multiple schemas. However, a data field can have only one menu
associated with it.