Types of schemes

A scheme is a globally unique identifier which specifies how to find a piece of framework code with which to lookup an object.

  • ip identifies an Ip Host instance. ORDs starting with ip are always absolute and ignore any base that may be specified. The body of an ip query is a DNS hostname or an IP address of the format: dd.dd.dd.dd.

  • fox establishes a Fox session. Fox is the primary protocol used by the framework for IP communication. A fox query is formatted as fox: or fox:<port>. If the port is unspecified, the framework assumes the default port, 1911.

  • file identifies files on the file system. All file ORDs resolve to instances of javax.baja.file.BIFile. File queries always parse into a FilePath. File ORDs include the following examples:

    • Authority Absolute: //hostname/dir1/dir2

    • Local Absolute: /dir1/dir2

    • Sys Absolute: !defaults/system.properties

      Sys absolute paths indicate files rooted under the framework’s installation directory identified via Sys.getBajaHome().

    • User Absolute ^config.bog is rooted under the user home directory identified via Sys.getUserHome(). In the case of station VMs, user home is the directory of the station database.

      User absolute paths

    • Relative: myfile.txt

    • Relative with Backup: ../myfile.txt

  • module accesses BIFiles inside the module jar files. The module scheme uses the file: scheme's formatting where the authority name is the module name. Module queries can be relative. If the query is local absolute then it is assumed to be relative to the current module. Module queries always parse into a FilePath:

    • module://icons/x16/file.png

    • module://baja/javax/baja/sys/BObject.bajadoc

    • module:/doc/index.html

  • station resolves the BComponentSpace of a station database.

  • slot resolves a BValue within a BComplex by walking down a path of slot names. Slot queries always parse into a SlotPath.

  • h resolves a BComponent by its handle. Handles are unique String identifiers for BComponents within a BComponentSpace. Handles provide a way to persistently identify a component independent of any renames which modify a component's slot path.

  • service resolves a BComponent by its service type. The body of the query should be a type spec.

  • spy navigates spy pages. The javax.baja.spy APIs provide a framework for making diagnostics information easily available.

  • bql encapsulates a BQL query.

  • nspace provides a global resolution of objects.

    • Local station example- nspace:SupervisorName|slot:|/a/b/c

    • Remote station example- nspace:DeviceName|slot:/a/b/c. This ORD resolves on a Supervisor to a virtual,

      example- station:|slot:/Drivers/NiagaraNetwork/DeviceName/virtual|virtual:/a/b/c

    nspace provides a global resolution of objects.

    • Local station example- nspace:SupervisorName|slot:|/a/b/c

    • Remote station example- nspace:ControllerName|slot:/a/b/c. This ORD resolves on a Supervisor to the framework virtual.

      example- station:|slot:/Drivers/NiagaraNetwork/ControllerName/virtual|virtual:/a/b/c

  • sys queries the systemDb.

    Note: It supports NEQL only.

    • For example, to query the entire systemDb for all devices in the system, enter: ip:<SupervisorIP>|foxs:|sys:|neql:n:device

      where <SupervisorIP> is the IP address of the Supervisor PC.

    • Another example: to issue a scoped query against the systemDb for ModbusTCP devices in subordinate station, enter:ip:<SupervisorIP>|foxs:|station:|slot:/Drivers/ModbusTCPNetwork|sys:|neql:n:device

      where <SupervisorIP> is the IP address of the Supervisor PC.

  • single is commonly piped at the end of a NEQL query (or certain BQL queries) to resolve the first entity in the result set. The following example runs a NEQL query to find all components tagged with “hs:ahu”, and then resolves the first one in the result set.

    ip:<SupervisorIP>|foxs:|station:|slot:/|neql:hs:ahu|single

    where <SupervisorIP> is the IP address of the Supervisor PC.