This section provides an overview of the steps to follow to deploy an application using encrypted source when you are done developing and testing your application.
1. Encrypt your procedures and include files — Before you can deploy your application, you must encrypt all of your procedures and include files with the XCODE utility. For more information about how to do this, see Encryptingsource code procedures in in DeploymentTopics and Tasks. Before encrypting the files, make sure they are represented with the appropriate code page for the target platform.
2. Dump .df and .d files — As with unencrypted source, you must dump your application schema (.df) and/or data (.d) files into ASCII format. This step copies your data from the application database, which is not portable, into a format that is portable. You do not have to encrypt your .df and .d files.
Like your procedure files and include files, the .d and .df files must be represented with the appropriate code page for the target platform.
3. Transfer text files — You must transfer the resultant .d and .df files to the target platform. This is a preliminary step to creating your distribution media.
There is more than one way to transfer files. For example, you can use FTP or other protocols, or you can put the files on CD or other storage media and physically transport the files.
4. Transfer binary files (encrypted files) — After you encrypt procedures and include files, they become binary files.
5. Rebuild the application database at the user site — You must provide a way for users to build the application database at their site. To do this, users must be able to load your .df and .d files into an empty database.
Any OpenEdge client, server, or stand-alone database product can compile and run encrypted source. However, only those products that can fully compile can load .d files into a database. The 4GL Development System, OpenEdge Studio, Progress Developer Studio for OpenEdge, and WebSpeed Workshop are the only products with this capability.
If you deploy to users whose licensed products do not have this capability, you must provide a way for them to load your .d files. For more information about providing a dump/load facility for users, see Dumping andloading .
Note: The dump/load procedures should be considered part of your application. The decision to distribute encrypted source versions of your application procedures applies to the dump/load procedures as well.
A full development product contains a complete Data Dictionary, which users can use to load the .df and .d files into an empty database. (In character environments, the Data Dictionary contains data administration capabilities. In Windows, these capabilities are provided with the Data Administration tool. Progress Developer Studio for OpenEdge provides the Database Navigator.) However, even though the user can perform these tasks, usually it is a good idea to write a script that automates this process. This not only frees the user from performing this task, but also makes your application easier to use.
Within your script, you can use pre-existing procedures in the install-dir/tty and install-dir/gui directories (installed for full development OpenEdge products). Within these directories are procedures that load .df and .d files, called load_df.p and load_d.p, respectively. Your script can start OpenEdge and run these procedures to load your data definitions and data. To run these procedures at the user site in the case where users do not have a license for a full development product, the procedures must be encrypted or in r-code format. This step is necessary because OpenEdge must be started with the -rx parameter to run or compile the procedures where users do not have a license. When started with this startup parameter, OpenEdge cannot run or compile unencrypted source.
If you decide not to write a script and instead rely on the users' ability to load the data definitions and data, make sure you provide adequate documentation to guide them through the process.
6. Copy an empty database and rename it — To rebuild your application database at the user's site, you must make a copy of the empty database and rename it. An empty database is included in the installation directory of all OpenEdge client, server, or stand-alone database products. Because databases are not portable, you must use an empty database that already is ported to the target platform.
Users can use OpenEdge to copy the empty database and rename it, or you can write a script that does this task for them. This script can call the PRODB command to make a copy of the database and rename it appropriately. OpenEdge also provides a newdb script that creates a database.
If users have an OpenEdge product that provide these capabilities, and you decide to let them perform this step, you must provide them with adequate documentation to guide them through the process.
7. Provide an install utility — You must provide a way for users to install your application. However, OpenEdge must be installed before they can use your application. You can create one install for both OpenEdge and your application. To do this, create an install program using a third-party tool, such as Installshield, and call the OpenEdge Install batch mode from within it.
8. Provide a compilation routine — When you deploy with encrypted source, you typically provide a compilation routine. Though this is not necessary in all cases, it is usually a good idea because it frees the user from performing the task of compiling your application. In the case where you specify unique encryption keys, providing a compilation routine becomes a necessity.
All OpenEdge client, server, and stand-alone database products can compile encrypted source. Therefore, if you use the default encryption key, users can compile your application without a specialized routine. However, if you have users compile your application, you must provide adequate documentation to guide them through the process.
Because encrypted code is not precompiled, your application can take advantage of compile-time functionality. For example, you might want to pass arguments to include files to determine sort order, field lists, and so on. You can take advantage of this behavior at the user site, allowing users to specify their preferences before compilation. This option is not available with r-code, which must be compiled at the development site. Whether you can repeatedly take advantage of compile-time features during the ordinary day-to-day operation of your application depends on what OpenEdge products the users have.
To compile encrypted source code, OpenEdge must be started with the -rx startup parameter. When an OpenEdge session is running with this startup parameter, ABL (Advanced Business Language) can compile encrypted source but cannot compile unencrypted source. If users have a full development product, they will probably want to write and compile their own unencrypted procedures. Thus, in their day-to-day operation of OpenEdge, they must run OpenEdge without the -rx startup parameter. For users with full development products, therefore, you probably want to perform a one-time compilation with the -rx parameter, then restart OpenEdge without this parameter. For users with OpenEdge products that cannot compile ordinary unencrypted source, running permanently with the -rx parameter is not an issue.
OpenEdge provides a template procedure, compile.p, that you can use to compile your application. For more information about compile.p, see Compilation.
9. Provide a startup routine — You must provide a way for users to start the application. You can either write a script to do this or provide adequate documentation.
10. Provide documentation — You must provide users with enough documentation to use your application and to perform the previous tasks if you do not automate them.
11. Provide online help — You might want to provide online help for your application.
12. Prepare distribution media — You must prepare your distribution media. It should include all:
Procedures and include files (encrypted)