Introduction to OG Access Tool

In some dedicated SaaS deployments, you can use Output Generator Access Tool (OGAT) to develop and test modifications you make to IXIA CCMS Output Generator (OG).

OGAT allows you more control of your outputs. Product highlights include:
  1. A single development environment with discrete entities to safeguard development from production
    1. The Development OG runs on a completely separate server from either Test or Production OG so that you can iterate on your modifications.
    2. Scripted tools guide your Development and Test deployment activities
    3. All users within your Dev Group share a single Development Environment
    4. As a user and member of a Dev Group, you have access to both Dev and Test servers
  2. Access controls for the development system, where only delegated system users have access to the tools and the environment
  3. No need to replicate content
    • Use the Development OG for both Test and Production OG client by switching your connection OG information in CCMS Desktop
    • You can generate output from CCMS Desktop directly to either instance of OG.

The possible range of modifications and customizations you can make using OGAT include:

  • Creation and modification of custom outputs
  • Management of DITA Open Toolkits
  • Creation and modification of DITA-OT plugins
  • Modification of CCMS Output Generator files
    Note: Exclusions include MadCap Software proprietary files that are required for CCMS Output Generator to properly function
  • Creation and modification of custom DTD files
    Important: If you modify DTDs, you must also modify files in the system configuration.

OGAT is built on a central repository that enables file sharing between your Development Environment, Test Environment, and Production Environment.

Figure: Typical OGAT development workflow
Typical OGATdevelopment, test, and production workflow

Item

Action

1

Make updates to OG

2

Debug updates

3

Restart OG as required

Note: Restart if your changes meets any of the following conditions:

  • OG version is prior to or at 6.2

  • OG is 6.3 or higher and is a change to the memory or to system properties

4
Validate changes to the Development repository and take one of the following actions:
  • If the update is successful, proceed to the next step
  • If the update fails, go back to debug

5

Commit changes to the repository and update to Test

6

Restart OG as required

Note: Restart if your changes meets any of the following conditions:

  • OG version is prior to or at 6.2

  • OG is 6.3 or higher and is a change to the memory or to system properties

7
Validate changes to the Test repository and take one of the following actions:
  • If the update is successful, proceed to the next step
  • If the update fails, begin again at 1

8

Tag the repository's current state and notify IXIA CCMS Customer Support using its Open-Source Ticket Request System (OTRS)

9

Upon your notification in OTRS, IXIA CCMS Customer Support moves your modification commits to Production