Services Standard Build User Guide

IdentityIQ Version: 6.0

This document is meant to be a user-friendly guide explaining how to set-up the services standard build, as well
as its applications.
© Copyright 2013 SailPoint Technologies, Inc., All Rights Reserved.

SailPoint Technologies, Inc. makes no warranty of any kind with regard to this manual, including, but not limited to, the implied
warranties of merchantability and fitness for a particular purpose. SailPoint Technologies shall not be liable for errors contained herein or
direct, indirect, special, incidental or consequential damages in connection with the furnishing, performance, or use of this material.

Restricted Rights Legend. All rights are reserved. No part of this document may be photocopied, reproduced, or translated to another
language without the prior written consent of SailPoint Technologies. The information contained in this document is subject to change
without notice.

Use, duplication or disclosure by the U.S. Government is subject to restrictions as set forth in subparagraph (c) (1) (ii) of the Rights in
Technical Data and Computer Software clause at DFARS 252.227-7013 for DOD agencies, and subparagraphs (c) (1) and (c) (2) of the
Commercial Computer Software Restricted Rights clause at FAR 52.227-19 for other agencies.

Regulatory/Export Compliance. The export and reexport of this software is controlled for export purposes by the U.S. Government. By
accepting this software and/or documentation, licensee agrees to comply with all U.S. and foreign export laws and regulations as they
relate to software and related documentation. Licensee will not export or reexport outside the United States software or documentation,
whether directly or indirectly, to any Prohibited Party and will not cause, approve or otherwise intentionally facilitate others in so doing.
A Prohibited Party includes: a party in a U.S. embargoed country or country the United States has named as a supporter of international
terrorism; a party involved in proliferation; a party identified by the U.S. Government as a Denied Party; a party named on the U.S.
Government's Entities List; a party prohibited from participation in export or reexport transactions by a U.S. Government General Order;
a party listed by the U.S. Government's Office of Foreign Assets Control as ineligible to participate in transactions subject to U.S.
jurisdiction; or any party that licensee knows or has reason to know has violated or plans to violate U.S. or foreign export laws or
regulations. Licensee shall ensure that each of its software users complies with U.S. and foreign export laws and regulations as they relate
to software and related documentation.

Trademark Notices. Copyright © 2012 SailPoint Technologies, Inc. All rights reserved. SailPoint, the SailPoint logo, SailPoint IdentityIQ,
and SailPoint Identity Analyzer are trademarks of SailPoint Technologies, Inc. and may not be used without the prior express written
permission of SailPoint Technologies, Inc. All other trademarks shown herein are owned by the respective companies or persons
indicated.

Services Standard Build User Guide Page 2 of 19

Table of Contents
Standard Build Overview ............................................................................................................................................4
Downloading the Build ...........................................................................................................................................5
Exporting Custom Objects ......................................................................................................................................6
Running the Export Script ...................................................................................................................................6
Build Structure Set-up ............................................................................................................................................8
Object Split-up ....................................................................................................................................................8
Build Configuration .................................................................................................................................................8
Configuring the build.properties file ..................................................................................................................9
Folder Structure............................................................................................................................................... 15
Executing the build .......................................................................................................................................... 18
Dev targets explained ...................................................................................................................................... 18

Services Standard Build User Guide Page 3 of 19

Services Standard Build Overview
A build process is critical to the smooth deployment to production of a configured IdentityIQ environment. A
build process helps streamline the process of promoting an IdentityIQ installation’s configuration objects
through the development, test, and production environments so that all three contain the same custom objects
like applications, rules, task definitions, and identity mappings. It also allows for new custom objects and
custom java code to be integrated into IdentityIQ with a single, simple command.

The Services Standard Build (SSB) is a process developed by the SailPoint Services team for use as a build process
for IdentityIQ deployments. This process was designed with the following goals in mind:

 Automate effort of generating deployments for various environments such as development, testing,
UAT, and production.
 Reduce time frame for new team members to become familiar with project structure and
customizations.
 Reduce likelihood of errors due to improper deployment of patches, efixes, and configurations.
 Accelerate the software development process with useful methods and tools that make configuring
IdentityIQ more efficient.
 Enable the SailPoint support team to quickly replicate IdentityIQ environments.
Generally, it is best to set-up a build process once a project requires a move from the development environment
to the test environment. To do this, the set of scripts and directories that make up the SSB needs to be
downloaded and all configuration objects need to be exported from the development environment into the
build directory.

Process Overview
Before beginning, please ensure you have the following:

1. Access to SailPoint’s Compass website. https://community.sailpoint.com/

2. Command line access to your development and test servers. These are the servers where IdentityIQ’s
servlet container (web application server) runs. This may be JBOss, Tomcat, WebShpere, or WebLogic
depending on the environment. Command line access to your production server is only necessary if you
will be moving custom objects to your production server.
3. Ability to create a directory in the WEB-INF/bin folder of your Identity IQ installation directory on your
development server.
4. Ability to stop and start your web application server (Tomcat, JBOss, WebLogic, WebSphere, etc.).
5. Ability to copy a directory from your development server to your test and/or production server.
The steps you will perform to complete this process are as follows:

1. Download the Services Standard Build from Compass.

2. Export the custom objects from you development environment.
3. Set-up the directory structure of the build.

Services Standard Build User Guide Page 4 of 19

 4. Configure the build.
5. Run the build command.

1. Downloading the Services Standard Build

First, download the latest version of the SSB on Compass, located here:
https://community.sailpoint.com/documents/product-resources/implementation-notes/services-standard-build

Download the Zip file with the latest version and unzip it into a file directory accessible to the development
environment. This will create the base build structure. The directory where you have un-zipped the services
standard build files to will be called the “SSB Install Directory” below. Note where you unzipped these files to,
we will reference this directory again later several times throughout the document.

Services Standard Build User Guide Page 5 of 19

 2. Exporting Custom Objects
This section assumes that IdentityIQ has been successfully installed into a development environment and that
object definitions (e.g., applications, rules) have been created. If IdentityIQ has not been installed in at least
your development environment, please do this first. If there are no custom object definitions to export at this
time, skip this step and add them to the build’s <SSB install directory>
\ServicesStdBuild\trunk\config folder as they are created.

Running the Export Script

The export script tells IdentityIQ to export the 35 most common configuration object classes. For example, one
line of the export script is “export -clean exports/CurrentApplicationExported.xml Application”. This line exports
all of the Application objects into a file called “CurrentApplicationExported.xml”.

To see the configuration objects your environment has by object type, navigate to the WEB-INF\bin folder within
your IdentityIQ installation directory from a command prompt. Enter the command “iiq console” once
inside this directory.

Enter the command, “list”, to see all of the object types or “Classes”. Enter “list objectType”, to see all of
the objects of that type in your environment.

If your environment has configuration object types not covered in the 35 object classes listed in the export
script, add more commands to the export script following the syntax of the other lines in the script,
i.e.,“export -clean exports/CurrentObjectClassNameExported.xml ObjectClassName”.

Services Standard Build User Guide Page 6 of 19

Copy the “ExportScript.txt” from the <SSB install directory>\ServicesStdBuild\trunk
directory you un-zipped earlier. Paste this text file into the WEB-INF\bin folder of your IdentityIQ installation
directory. Also, create a folder called “exports” in the WEB-INF\bin folder.

Navigate back to the WEB-INF\bin folder within your IdentityIQ installation directory from a command prompt.
Enter the command “iiq console” once inside this directory.

Once a closing tag appears “>”, enter the following command “source ExportScript.txt”. This will run the export
script and export all of your environment’s configuration objects into the exports folder you just created.

Services Standard Build User Guide Page 7 of 19

 3. Build Structure Set-up
The location of all your environment’s configuration objects is the <SSB install
directory>\ServicesStdBuild\trunk\config directory. Inside of this config folder, create a
folder for every object class you exported. A folder for some objects -- Application, LocalizedAttribute, Rule,
TaskDefinition, and TaskSchedule already exist as samples.

Place every class’ exported xml into its respective folder. For example, place the
“CurrentApplicationExported.xml” file from the “exports” folder, into the <SSB install
directory>\ServicesStdBuild\trunk\config\Application folder.

Object Split-up
It is recommended, but not required, to put each individual object into its own xml file. This makes it easier in
the future to track exactly which objects have been changed between releases. Do this by putting the object’s
entire definition in between the following header, opening, and closing tags:

<?xml version='1.0' encoding='UTF-8'?>

<!DOCTYPE sailpoint PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<sailpoint>
<ApplicationDefinitionHere>
</sailpoint>

Place each xml object into its respective class folder.

For example, CurrentApplicationExported.xml would be split into Application-ActiveDirectory.xml and

Application-MicrosoftExchange.xml

4. Build Configuration
After all custom objects have been placed inside their proper class folders, move the entire <SSB install
directory> folder into your new environment.

Place your installation version’s IdentityIQ zip file into the <SSB install
directory>\ServicesStdBuild\trunk\base\ga folder. If you are running IdentityIQ 6.0, you
would put identityiq-6.0.zip here, for example. You can place as many different IdentityIQ zip files as you would
like here. The correct .zip will be selected based off the IIQVersion value set in the environment specific

Services Standard Build User Guide Page 8 of 19

build.properties file. If you cannot locate this zip file, you can find it here:
https://community.sailpoint.com/documents/product-resources/productfiles

If you are running a patched version of IdentityIQ, place the patch .jar file for your installation into the <SSB
install directory>\ServicesStdBuild\trunk\base\patch folder. You can place as many
different patch .jar files as you would like here. The appropriate patch .jar will be selected using the
IIQPatchLevel property set in the environment specific build.properties file. All patch .jar files can
be located here: https://community.sailpoint.com/documents/product-resources/productfiles

Create a folder inside of <SSB install directory>\ServicesStdBuild\trunk\base\efix

based off the version of IdentityIQ you are running. For example, if you are running version 6.0 patch 2, name
your folder “6.0p2”. If you are using IdentityIQ version 5.5 with no patch level, name your folder “5.5”. This
specific naming convention is important. Your build will fail if this folder’s name does not match the version of
IdentityIQ you are running.

4.1 Configuring the build.properties file

The build.properties file is a crucial configuration file that specifies a few very important things, like the version
of IIQ you are running, the location of your Java Development Kit (JDK), location of your application server, and
the database location and database access credentials. Without this information the build cannot run
successfully.
Now configure the build.properties file found in the <SSB install directory>\ServicesStdBuild\trunk folder. Use
your favorite text editor to edit this file. The following section explains how to fill out the build.properties file:

Services Standard Build User Guide Page 9 of 19

IIQVersion (required)- Specify the base version of IdentityIQ that you are building from. Ex. 4.0, 5.0, 5.1, 5.2,
5.5, 6.0, or 6.1.

IIQPatchLevel (only required if using a patch level) - If you want to deploy a patch level specify what level with
pX syntax. Ex. p1 or p6. If you are not on a patch level then leave this entry blank.

IIQHome(required) - The home directory of the IdentityIQ web application in your sandbox/development
environment.

Customer (optional) - The name of the client or project phase

jdk.home (required) - The path on your system to the Java Development Kit (jdk) you want to use to compile
any custom Java code you may have developed as part of your IdentityIQ configuration. As with all system
paths, if there are spaces in your jdk path, put the entire path in double quotes.

runCustomScripts (leave as false if unsure) - (true/false) The build is not meant to be modified. You will notice
the core build files are set to be read only. The main build has two hook points after file layout and after war
creation where you can execute customized build scripts. This flag indicates if these customizations should be
executed.

application.server.host (required)- The IP address of your application server in your sandbox/development

environment

Services Standard Build User Guide Page 10 of 19

application.server.port (required) - The port the application server is running on. For example, 8080 is the
Tomcat default.

application.server.start (required) - Since there are so many different application servers we leave it to you to
write a script that starts and stops the server, sets up JVM parameters etc. Many application servers already
ship with these but you can specify which ones you want to use here. These scripts are used in development
targets that cycle the application server for you.

application.server.stop (required) - Mirror of the above.

db.url (required) - The JDBC URL to your local database.

db.userid (required) - Database user that has create and drop schema privileges . Ex. root on MySql. (Supply
these parameters only for the sandbox/development environment. Test and Production environment are
managed in a more secure fashion.)

db.password (required)- The password for the root db user. (Supply these parameters only for the
sandbox/development environment. Test and Production environment are managed in a more secure fashion.)

db.driver (required)- The class of the JDBC driver to use for SQL connections. This is the same type of value you
would put in your iiq.properties file following the directions in the IdentityIQ Installation Guide.

iiq.path (required)- The installation directory within the application server directory of the IdentityIQ
application. Usually /iiq or /identityiq

db.type (required) - (db2/mysql/oracle/sqlserver) one of these values used to pick which database scripts to
run.

override.safety.prompts (leave false if unsure) - Certain dangerous build targets like dropdb will prompt the
user for confirmation before executing. If you are using the build to make test cases you may want to turn off
these prompts.

manager.url - URL to the tomcat manager script interface. Prior to Tomcat Version 6 the url is usually /manager
but post Version 6 it is /manager/text.

manager.login - A user who has the manager-script role in the Tomcat manager application. For information on
how to set this up check out http://tomcat.apache.org/tomcat-7.0-doc/manager-
howto.html#Executing_Manager_Commands_With_Ant

manager.pw - The password for the above account.

usingLcm - If your implementation includes Lifecycle Manager, you can ensure that it is included in your project
build by enabling the “usingLcm” property in the build.xml file. This will insure that init-lcm.xml is called
immediately after init.xml (which is renamed to init-default-org.xml by the Services Standard Build.)

Services Standard Build User Guide Page 11 of 19

Supporting multiple platforms (Windows/Linux/Unix) for different environments
If your environment has different operating systems for different stages of IdentityIQ development – for
example, Windows for sandboxes and Linux for Test and Production servers -- you will need to configure
multiple “build.properties” files.

The “build.properties” file described above loads the defaults for the build with respect to the path to Java
binaries, IdentityIQ version and other details. In order to override those defaults on a per-server basis you can
specify another properties file with properties that just apply to one server. Each server or host used in
development and testing can override the settings in “build.properties” by using its own
“build.properties.hostname“ file. For example if your host is named “sailsandbox” then the properties file
unique to that server would be called “build.properties.sailsandbox”. The server’s properties file has the exact
same format and fields as the “build.properties” file described in the previous section and only has to specify the
fields that it wants to override with new values.

4.2 Setting up environment specific properties files

Because the goal of this process is to create a uniform Identity IQ distribution in all three environments
(development, test, and production), it is important to configure environment specific properties files.

Each environment has different logins, IPs and passwords. The SSB will automatically look for tokenized strings
in your custom configuration xml and substitute the appropriate values per environment.

<target>.target.properties
This set of files contains name value pairs for token substitution during build time. You should have one file for
each environment in your deployment.

Example

sandbox.target.properties
test.target.properties
UAT.target.properties
prod.target.properties

Each file is just a list of key/value pairs. The build follows the convention that the keys follow the %%.*%%
pattern.

For example, you may have an Active Directory application configuration that looks like this:

<?xml version='1.0' encoding='UTF-8'?>

<!DOCTYPE sailpoint PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<sailpoint>
<Application authoritative="true"
connector="sailpoint.connector.ADLDAPConnector"
featuresString="AUTHENTICATE, MANAGER_LOOKUP, SEARCH, UNSTRUCTURED_TARGETS"
name="AD" profileClass="" type="Active Directory">
<Attributes>
<Map>
<entry key="password" value="mySuperSecrectProductionPassword"/>

Services Standard Build User Guide Page 12 of 19

 <entry key="managerCorrelationFilter">
<value>
<Filter operation="EQ" property="DN" value="manager"/>
</value>
</entry>
<entry key="user" value="productionADuser"/>
<entry key="groupHierarchyAttribute" value="memberOf"/>
<entry key="port" value="3379"/>
<entry key="authorizationType" value="simple"/>
...

To support multiple environments you would substitute passwords, ports, etc. with keys that will go in your
<target>.target.properties file.

<?xml version='1.0' encoding='UTF-8'?>

<!DOCTYPE sailpoint PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<sailpoint>
<Application authoritative="true"
connector="sailpoint.connector.ADLDAPConnector"
featuresString="AUTHENTICATE, MANAGER_LOOKUP, SEARCH, UNSTRUCTURED_TARGETS"
name="AD" profileClass="" type="Active Directory">
<Attributes>
<Map>
<entry key="password" value="%%AD_PROXY_PASSWORD%%"/>
<entry key="managerCorrelationFilter">
<value>
<Filter operation="EQ" property="DN" value="manager"/>
</value>
</entry>
<entry key="user" value="%%AD_PROXY_USER%%"/>
<entry key="groupHierarchyAttribute" value="memberOf"/>
<entry key="port" value="%%AD_PORT%%"/>
<entry key="authorizationType" value="simple"/>
...

Then, for example, in the file “prod.target.properties” you would have:

#######################################################

# AD Connectors

#######################################################

%%AD_HOST%%=example.com

%%AD_PORT%%=3379

%%AD_PROXY_USER%%=productionADuser

%%AD_PROXY_PASSWORD%%=mySuperSecrectProductionPassword

Services Standard Build User Guide Page 13 of 19

… and so on for each of your environments. Note: the password values should be IIQ encrypted strings.

Setting the target variables by editing servers.properties

To set this up you must add your machine hostname to the servers.properties file in the root build directory
with the environment that the machine is supposed to use. This tells the build what environment you want to
use. If your environments are sandbox, test, UAT and prod and you wanted to build using the settings for
sandbox you would set your machine environment to "sandbox" (see the servers.properties file).

<target>.iiq.properties
This file is the iiq.properties file you want to use for the target environment. For example, if your environments
are sandbox, test, UAT and prod, you would have four files each containing the iiq.properties that know how to
connect to the database server in that environment. This way you can support different properties for different
environments, such as having a direct connection in sandbox and test while having a JNDI named connection in
UAT and production.

Example

sandbox.iiq.properties
test.iiq.properties
UAT.iiq.properties
prod.iiq.properties

##### iiq.properties #####

#
# (c) Copyright 2008 SailPoint Technologies, Inc., All Rights Reserved.
#
# This file contains configuration settings for IdentityIQ. For your unique
# environment, you will need to adjust the username and password properties
on
# the dataSource below and uncomment the applicable database settings.
#

##### Data Source Properties #####

dataSource.maxWait=10000
dataSource.maxActive=50
dataSource.minIdle=5
#dataSource.minEvictableIdleTimeMillis=300000
#dataSource.maxOpenPreparedStatements=-1

Services Standard Build User Guide Page 14 of 19

dataSource.username=root
dataSource.password=root

##### MySQL 5 #####

## URL Format:
dataSource.url=jdbc:mysql://<host_name>:<port>/<dbname>?useServerPrepStmts=t
rue&tinyInt1isBit=true&useUnicode=true&characterEncoding=utf8
dataSource.url=jdbc:mysql://localhost/identityiq?useServerPrepStmts=true&tin
yInt1isBit=true&useUnicode=true&characterEncoding=utf8
dataSource.driverClassName=com.mysql.jdbc.Driver
sessionFactory.hibernateProperties.hibernate.dialect=org.hibernate.dialect.M
ySQL5InnoDBDialect
#
# Setting for the BSFManagerPool set on the ruleRunner
#
bsfManagerFactory.maxManagerReuse=100
bsfManagerPool.maxActive=30
bsfManagerPool.minEvictableIdleTimeMillis=900000
bsfManagerPool.timeBetweenEvictionRunsMillis=600000

##### Debug Settings #####

# Uncomment to send all SQL queries to std out. This provides a lot of
output
# and slows down execution, so use it wisely.
#sessionFactory.hibernateProperties.hibernate.show_sql=true

# Hibernate Transaction Isolation Levels

# 1 = Read Uncommitted, 2 = Read Committed, 4 = Repeatable Read, 8 =
Serializable
#sessionFactory.hibernateProperties.hibernate.connection.isolation=1

Folder Structure

Services Standard Build User Guide Page 15 of 19

This is the high level folder structure of the build. The top level directories should not be modified

base - Contains binaries distributed by SailPoint. You can download these from community.sailpoint.com

efix - Contains any efix archives sorted by directory name where the directory name follows the naming
convention <version><patchlevel>. If there is no patch level just the version number. Because efix solutions only
work with the specific product version they were designed for you must make a unique directory for each
version and patch level you want to build against. If the build does not find a efix directory for the version its
building for it will fail with the error indicating so. In the above example there is a efix directory for 5.1p5.

ga - Contains the SailPoint GA release binary. You can have as many GA release binaries as you want to build
against and the appropriate one will be selected using the values you set in build.properties.

Example: /base/ga/identityiq-6.1.zip

patch - Contains the SailPoint patch binaries. You can have as many patch binaries as you want to build against
and the appropriate patch will be selected using the values you set in build.properties.

Example:/base/patch/identityiq-6.1p1.jar

config - Contains all SailPoint XML configuration sorted by folders where each sub directory is named by the
type of top level SailPoint object it holds. In the provided example Application, Rule, TaskDefinition and
TaskSchedule directories are shown. In general as you customize more object types you should add a directory
to contain that object. While writing code, try to make the separation of object types as granular as possible

Services Standard Build User Guide Page 16 of 19

such that it is easy to view all objects of a particular type. For example, instead of inlining a rule directly into a
TaskDefinition, a reference to that rule should be created and the Rule itself would live in its own file in the Rule
directory. Separate and encapsulate .

db - Contains customized database scripts.

lib - Contains libraries used by the build process.

scripts - With the exception of the master build.xml file in the root directory, all other build files are contained in
this directory. Shipped and supported build files are read-only and follow the name convention build.*.xml. If
you customize the build process you must declare your customizations in build files that follow the naming
convention build.custom.*.xml. These files adhere to an interface which is discussed in detail in the Customizing
the build process section of this document.

servicestools - This folder may or may not be included in your version of the build archive. It contains the
source code and an ANT project to build the services-tools.jar which is placed in the lib directory of the build.

src - Contains all of your custom java. Note this java will be placed in a jar file which will be placed in the main
WEB-INF/lib directory. You should NOT "clone and own" SailPoint shipped classes in this area. Since they will be
placed in the classpath at the same level as the shipped classes you may get behavior you do not expect. If you
absolutely must modify a core class you will have to define a build.custom.*.xml file to handle layout of these
files as you are basically defining your own efix. By default the build will not play nice with this practice.

web - Contains content that will be directly overlaid on the IIQ folder structure. Examples include custom
graphics/branding, xhtml, jsp and custom message catalogs etc. An example may be including custom changes
to the Hibernate XML configuration files. Under web you will need to create the folder structure to where these
files are normally stored.

../web/WEB-INF/classes/sailpoint/object/hibernateExtended.hbm.xml
Where hibernateExtended may be any of the Hibernate XML configuration files usually found in the
object directory, such as IdentityExtended.hbm.xml or LinkExtended.hbm.xml

Figure 1: modified Hibernate XML configuration files

Services Standard Build User Guide Page 17 of 19

 5. Executing the build
Once you have performed all the steps in the previous sections you are ready to build. Copy your entire build
structure and add it to your new environment, ensuring you build.properties is configured to match this new
environment.

To create an initial Services Standard Build package in the standard J2EE Web Application Archive that can be
deployed to a web application server such as Tomcat, you can perform the following steps.

 Open a Terminal or Command Prompt window

 Navigate to <SSB install directory>\trunk
 Enter build war
 This will generate a deployable war file and you will receive a confirmation message similar to the one
below:

war:
[war] Building war:
/home/workspace/SSB/trunk/build/deploy/identityiq.war
[echo] A MD5 checksum was generated for this war file
and placed in the war file directory. Keep this checksum to
diagnose potential version issues

BUILD SUCCESSFUL

 Deploy this file to the target web application server. You may need to consult your application serverss
deployment guide for details. In the case of Tomcat, you can simply copy this custom identityiq.war to a
folder under <Tomcat>/webapps
 Navigate to this directory; cd <Tomcat>/webapps/identityiq
 Expand and delete the war; jar xvf identityiq.war
You will need to create the IIQ database and tables, and if necessary consult the IdentityIQ Installation Guide for
details. Otherwise you are ready to use your customized IIQ application.

If you wish to update any custom objects and redeploy them to IdentityIQ you can perform the following steps.
Open a terminal or command prompt window,

 navigate to the <SSB install directory>\ServicesStdBuild\trunk folder and

 enter “build importdynamic”. This command will import all of the custom xml from your config
folder into IdentityIQ.
 Open IdentityIQ in a web browser and you will see the applications, rules, and other custom objects
from your original environment in this new one.

6. Dev targets explained

Here are the other build targets and their uses.

Services Standard Build User Guide Page 18 of 19

clean
Deletes everything in the <SSB install directory>\ServicesStdBuild\trunk\build directory.

createdb
Depends on the build.properties file having a database account setup that has schema creation and drop
privileges. This will setup the IIQ schema and apply any patch updates.

cycle
Depends on the application.server.start and stop properties being set. This will cycle your application server and
reload all web applications. If you are using Tomcat and you have the CATALINA_HOME environment variable
set this target will just reload the IIQ application and not the entire server.

dropdb
Drops the IIQ database.

dist
Copies the entire expanded war content to your application server webapps directory.

importcycle
Runs through the entire build process, validates and imports all custom xml, compiled java and static web
content and cycles the server. Useful while developing custom java.

importdynamic
Imports all content that does not require an application reload; Custom XML, static web content etc. Useful for
developing rules, workflow and branding.

export
Exports objects specified within objectsToExport.properties (this will now be generated – edit Rule-
OutputCustomObjectFile.xml in scripts if you need to add more objects to ignore or export – the variable name
of ignored object classes is listOfIgnoredClasses.) from your IIQHome repository to build/export so that you
don’t manually have to copy and paste xml from console-exported files to your build environment. Edit the
property file to include all types of objects you want to export, as well as the names of the objects for each type.

Document Revision History

Revision Date Written/Edited By Comments
February 2013 Blake Bowen Initial Creation (Current IdentityIQ version: 6.0)
March 11, Tina Timmerman 1st Revision
2013
April 19, 2013 Brendon Jones 2nd Revision
June 3, 2013 Blake Bowen Final Revision for SSB 1.2, posted to Compass

Services Standard Build User Guide Page 19 of 19