This command configures a connection to an external database. Using this connection, a workflow can execute a stored procedure using the DBExecute system function in Process Designer.
CAUTION You must configure identical connections on all servers in a farmed Process Engine (PE) system. Alternatively, after configuring a connection on one server, you can copy its configuration file to the corresponding directory on each of the remaining servers in the farm. The configuration file is named .<alias>.bin, located in FNSW_LOC/sd/ where PE is installed.
TIP You can view the configured connections using the listdbconfig command.
NOTE PE must have access to the appropriate database libraries so that stored procedures can be called. You must take additional steps to configure the PE server in order to call stored procedures from system steps. See Additional configuration steps below.
NOTE If PE is deployed on a Windows-based server, you can define the stored procedure in a SQL Server database, an Oracle database, or a DB2 database. If PE is running on a Unix-based system, you can define the stored procedure in an Oracle database or a DB2 database. A Unix-based PE cannot call a stored procedure in a SQL Server database.
TIP The stored procedure can be located in a database other that the workflow database.
Syntax
The syntax varies depending on the type of database.
Database | Syntax |
---|---|
SQL Server |
dbconfig <alias> s <groupname> <dbname> <authentication> [<dbuser> <dbpassword>] |
Oracle |
dbconfig <alias> o <dbname> <dbuser> <dbpassword> |
DB2 | dbconfig <alias> d <dbname> <dbuser> <dbpassword> |
Parameters
alias | A name, unique within the PE system, to identify the PE Database Connection. This is the database name to be entered in the DBExecute function in Process Designer. |
groupname | (SQL Server only) The SQL Server Group name. |
dbname |
For SQL Server, the database name; for Oracle, the Global Database Name; for DB2, the Database Alias Name. |
authentication |
(SQL Server only) Enter Y to use Windows authentication, or N to specify a dbuser and dbpassword. When using Windows Authentication, the connection to the remote database is performed using the Windows logon credentials of the user logged onto PE. If you don't use Windows Authentication, you must enter a user name and password to be used to log onto the SQL Server. This information is sent across the network in clear text from the PE server to the server hosting the remote SQL Server database. |
dbuser |
The user that PE will use to log on to the specified database. |
dbpassword | The password associated with the dbuser. |
To use the system step's database instruction to call stored procedures, the appropriate database API libraries must be installed and must be visible to PE.
During the installation of PE on a Windows server, DB2, Oracle, or SQL Server was designated as PE's underlying database manager. The appropriate client API libraries for the chosen DBMS should already be present on the PE server. This enables PE to call stored procedures in the chosen DBMS.
If you need to call stored procedures in either of the other database systems, you must install the appropriate database client API software for those database systems on the PE server.
For example, if the original PE installation specified SQL Server as the underlying DBMS, SQL Server stored procedures would be usable “out of the box.” If you need to call DB2 stored procedures from this PE server, you must install the DB2 client software on the PE server. Then, DB2 stored procedures could be called. If you also installed the Oracle client software on the PE server, system steps could call Oracle stored procedures as well.
During the installation of PE on a Unix-based server, either Oracle or DB2 was designated as PE's underlying database manager. The appropriate client API libraries for the chosen DBMS should already be present on the PE server.
If you need to call stored procedures in the other database system (the database system that is not used as PE’s underlying database), you must install the database client API software for that database system on the PE server.
In all cases, you must verify that the appropriate links to the database client API libraries are present. If the links are not present, you must create them as described below.
In all cases, the following commands must be issued while logged on with appropriate privileges and with the appropriate environment variables set. The libraries themselves must be executable from the fnsw logon.
To call DB2 stored procedures (AIX)
ls -alF $DB2_HOME/lib/libdb2.a
ls -alF $DB2_home/lib/libdb2.o
cd $DB2_HOME/lib
ar -x libdb2.a
mv shr.o libdb2.o
ls -alF /fnsw/lib/shobj/libdb2.so.
ln -s -f $DB2_HOME/lib/libdb2.o /fnsw/lib/shobj/libdb2.so
To call DB2 stored procedures (Solaris)
ls -alF $DB2_HOME/lib/libdb2.so
ls -alF /fnsw/lib/shobj/libdb2.so
ln -s -f $DB2_HOME/lib/libdb2.so /fnsw/lib/shobj/libdb2.so
To call DB2 stored procedures (HP-UX)
ls -alF $DB2_HOME/lib/libdb2.sl
ls -alF /fnsw/lib/shobj/libdb2.sl
ln -s -f $DB2_HOME/lib/libdb2.sl /fnsw/lib/shobj/libdb2.sl
To call Oracle stored procedures (AIX)
ls -alF $ORACLE_HOME/lib32/clntsh.o.
ls -alF /fnsw/lib/shobj/liboracle.so
ln -s -f $ORACLE_HOME/lib32/clntsh.o /fnsw/lib/shobj/liboracle.so
To call Oracle stored procedures (Solaris)
ls -alF $ORACLE_HOME/lib32/libclntsh.o
ls -alF /fnsw/lib/shobj/liboracle.so
ln -s -f $ORACLE_HOME/lib32/libclntsh.o /fnsw/lib/shobj/liboracle.so
To call Oracle stored procedures (HP-UX)
ls -alF $ORACLE_HOME/lib32/libclntsh.sl
ls -alF /fnsw/lib/shobj/liboracle.sl
ln -s -f $ORACLE_HOME/lib32/libclntsh.sl /fnsw/lib/shobj/liboracle.sl