Delivering protocols, components, and applications to users and other developers on an AEP server can be very challenging. Accelrys delivers the majority of its AEP services in the form of packages. This talk will discuss the methods that anyone can use to deliver bundled applications in the form of packages and the benefits of doing so. The discussion will include how to create packages, modifying existing packages, deploying packages to servers, and tools that can be used for ensuring the quality of the packages.

1. (ATS6-DEV06) Using Packages for
Enterprise Application Delivery
Steven Bush
R&D, AEP Core Infrastructure
steven.bush@accelrys.com

2. The information on the roadmap and future software development efforts are
intended to outline general product direction and should not be relied on in making
a purchasing decision.

3. Content
• What are packages?
• Using pkgutil
• Creating a new package
• Adding items to packages
– Components and Protocols
– Java, Perl, .Net Modules
– 3rdparty applications
• Editing
• Testing
• Deploying
• Combining with version control (cvs, svn, git, etc.)

4. Documentation
• See Application Packaging Guide in the AEP Server
Developer Help Center

5. Simple!
• Create the package
– pkgutil –n <mycompany/mypackage>
• Create xml directory
– Add “xml” directive to package.conf
• Export Components/Protocols to xml folder
– Folder structure matches trees in Pro Client
• Register package
– Pkgutil –r <mycompany/mypackage>

6. What is it?
• A package is basically a folder used to deploy applications to an AEP server
• Located in <root>/apps/<company>/<packagename>
– Ex. accelrys/customapp
• Can include:
– Protocols, components
– .jars, .pms, .NET assemblies, javascript
– 3rd party applications
– Various web pages
– Data files
– Server configuration
• Global data
• URL mapping
• Static web pages
• Edit directly
• Use pkgutil to manage

7. pkgutil
• Command Line application
• Used to register, unregister, list, create, and test packages
– Windows: <root>/bin/pkgutil.exe
– Linux: <root>/linux_bin/pkgutil
• Note: run “. <root>/linux_bin/ppvars.sh” first
• Install/Register
– pkgutil -i <package> or pkgutil -r <package>
• Commands are equivalent, -r will first unregister if necessary
• Unregister
– pkgutil -u <package>
• List
– pkgutil -l [company]
• Create
– pkgutil -n <package>
• Creates the basic framework of a package
• Validate
– pkgutil -v <package>

8. Creating a package
• Use pkgutil –n <packagename>
– e.g. pkgutil –n mycompany/myapp
– Creates folder under <root>/apps
– Creates “package.conf” text file with basic entries
• Edit package.conf
– Add directives as necessary
• xml, data, java, perl, URL, etc.
• Add folders for each item
– Component and protocol xml
– Data files
– Application dependencies (.jar, .pm, 3rdparty apps)

9. Package structure
mycompany/myapp
bin/
lang/
java/
js/
perl/
dataroot/
data/
docs/
icons/
scheduler/
xml/
Components/
Protocols/
ComponentState.xml
package.conf

10. Adding Items: Components and Protocols
• Folder structure is identical to folders in Protocol DB
– Mycompany/myapp/xml/Components/Data Access and
Manipulation/etc…
• Add “xml” directive to indicate the folder where the items are
stored
• Export item into location
• Install package to see newly added items
• Updated items take effect immediately
– No built in version control! Combine with 3rd party version control on
your package folder

11. Adding Items: Java, Perl, .NET, 3rd Party
• Save in an appropriate folder
– Typically <package>/bin/lang/*
• Add the appropriate directives
– Java:
<java>
CLASSPATH
</java>
– Perl:
<perl>
INC
</perl>
– .NET:
<dotnet platform="windows">
ASSEMBLY
</dotnet>
• Install the package to update

12. Adding Items: other
• “dataroot”
– Adds set of data files for the package
– Adds shortcuts to client file browsers
• <icons>
– Adds custom icons for components
• Icon format is very specific!!! Need multiple files for each icon for different sizes and states
• MyIcon.ico (16x16), MyIcon.png (60x52), MyIcon16x16.png (16x16), MyIconRed.png (60x52)
• <web>
– Static web pages (e.g. index.html)
• <URL>
– Custom URL routing for launching protocols
• <helpdoc>
– Documentation to show in help center
– Typically a pdf
• <require>
– Specifies dependencies on other packages
• “scheduler”
– Folder that contains scheduled tasks such as protocol executions

13. Interface vs. Implementation
• For component SDK items, the implementation might not
be included in the component.
• So, if you have .jar, .pm, or .Net implementation files that
are used by components, OLD components might still
make use of the same file.
• Code your implementation to accept OLD parameter sets.

14. Editing
• Changes to existing components and protocols take effect
immediately
• Added or deleted components and protocols require
reregistering the package
• Other changes require reregistering as well
– .jar, .pm, docs, icons, etc.
• Some changes might require restarting the AEP server
– URL or scheduler changes which change the server’s core
configuration

15. Testing Functionality
• regress.exe
– Create regression protocols to test components
– Use regress to make sure
• protocol runs
• results have not changed
– Suggestion: Create a “MyApp_test” package to store
regressions.
• This way you can uninstall the test package on the production server
– Regression protocols should be self contained.
• Same inputs = same outputs
• Remote calls are tested that they work, but remote data might change

16. Testing Component State
• Validation
– Prevent unintentional changes to component parameters
– Run “pkgutil –q” to create a baseline file called
“ComponentState.txt”
• Stored in <package>/xml folder
– Run “pkgutil –v” to report any differences from the baseline
– Rerun “pkgutil –q” to update the state.

17. Deploying
• (optional) Pkgutil -repackxml <package>
– Changes the registrant of each component and package to
<company/package>
– Cleans up several parameter values
• Check the package with pkgutil –v <package>
• Copy folder to new server
– Use zip file
• Run pkgutil –r <package>
• Run regression tests on the new server

18. Version Control
• No built in versioning of items in packages
– Editing an item is permanent
• Connect 3rd party version control to the package folders
– A package is just a folder structure with a set of files
– Be aware of types of files (binary, text, unicode, etc.)

19. • Creating a package is simple!
• Useful for
– Deploying sets of components and protocols
– Web Applications
– Required for Load-Balanced Deployments
– 3rd party tools
• Take a look at the packages that we ship for examples
Summary