Molu Software Update

From Mophilly Knowledge Base
Jump to: navigation, search



With Molu Software Update Services you can update your client installations as often as you need. Instead of making them wait four to six months for "cost effective" delivery of fixes and enhancements, the update cycle can be weekly, monthly or whatever makes sense for your business. The Software Update Service is a simple, secure update way to drive down deployment costs by eliminating the need for update installers, extra CD's, special FTP downloads and the technical support that goes along with these methods.

The Molu Registration Service provides automated registration and activation of client installations. Integrating delivery of software licenses into your existing sales order and accounting systems is simple and straightforward.

The Molu Developers Tool manages your software updates and release notes for your account with Molu Software Update Services. It supports one or more of your products. The Molu Developers Tool is included with each Molu Client distribution.

The Molu Software Update is available as a service or a pre-configured server product. Each plan includes the Developer Tool for managing your product deployment and the client library to be included in your product distribution.

The Molu Software Update software was made possible by the contributions of Jorge Arias of Valhalla Systems, Mark Robillard of Clients & Profits, and Walter Venable of Alternative Engineering. Patrick Insko of Corporate Services provided copy editing and invaluable critique.

Hosted Service

Set up takes about 30 minutes or less. The server is hosted in our data center, backed up on a weekly basis. All data is encrypted using unique keys before being uploaded to the server. The update process is completely under your control.

Fees are a base rate per month for up to 1 GB data transfer volume. Higher volume is automatically accommodated and charged to your account in 1 GB blocks. High volume rates are available.

Server Appliance

The server host is available in either a 1U rack mount or small form factor device. Standard server operating system options are Linux, Mac OS X server operating systems. Windows server can be configured upon request.

Hardware configuration for the minimum server is 2.4 GHz Pentium class processor, 2 GB RAM, 10/100/1000 Mbps ethernet card, CD/DVD reader, 7200 rpm 80GB hard drive.

Molu Software Update FAQ

What’s Included

The release includes files for the current release of Omnis Studio, version 5.1.1 as of this writing. Molu Software Update for older versions of Omnis Studio are available upon request.

  • MoluClient.lbs
    This is the sub system module to include in your Omnis Studio based application
  • MoluDeveloper.lbs
    This is the tool used to create and release updates

The oXML component is essential to the proper operation of the Molu Software Update system. Check with TigerLogic as to whether your developer support contract includes the license codes for oXML. Please contact us if you have any questions or concerns.

Sample Application Code

The first Omnis Studio library is "Sample.lbs" which shows you how to implement the Molu Client in your application library. Sample.lbs is a working library, however it will not provide a live demonstration library until you have set up the Molu Developer Tool and uploaded your application to Molu Services.

Sample.lbs contains the code you need to integrate the Molu Client with your application. You can simply drop the window class into your library and amend one of your existing menus to open it, and you are ready to go. When the user selects the menu command they are presented with the Software Update dialog.

You may alter this window to match your application user interface motif.

Please note that the Sample.lbs may not be up to date with the current release. Please compare the class "wSoftwareUpdate" in the Sample.lbs with that class found in the MoluDeveloper.lbs. The copy in MoluDeveloper.lbs is the most recent in all cases.

Molu Client

The library "MoluClient.lbs" is the Molu Client for Omnis Studio "runtime" and should be included as part of your standard deployment. The client also requires that the oXML component is enabled; please contact TigerLogic for any necessary licensing. Instructions for setting up the Omnis Runtime can be found later in this document.

The Molu Client does all the work of determining if an update is available, downloading and installing the update. There isn’t a user interface for the Molu Client module. Rather, there are example windows you can use in the Sample.lbs file. The sample windows and menu found in Sample.lbs can be added to your application library, and they will handle the interaction with the Molu Client. In addition to running the update from a window, the check for updates can be run from your startup or shut down methods.

Molu Developer Tool

The third library "MoluDevTool.lbs" is to be used by you to manage the contents of the updates and release notes hosted by the Molu Service. This tool can be placed wherever is convenient for you. It is used within the Omnis development environment and is compatible with the Omnis SDK.

The Developer Tool requires access to a "product" database. The SQL scripts to set up the database, aka the "DDL", is provided for the PostgreSQL DBMS.

Setup Instructions

The first step is to install PostgreSQL. When you subscribe to Molu Software Update service you receive DDL script to create your "product" database. With this done, you are ready to launch the developer tool.

Developer Tool

The file MoluDevTool.lbs can be placed anywhere that is convenient. We put it in the "startup" folder of the Omnis SDK. The first time you open the tool in Omnis SDK, you will be prompted to enter log on parameters for the database you set up. This profile is saved and can be edited via the Preferences dialog.

The developer library you received is configured with all the necessary server access keys. Simply open the library and start working. The tool appears on the Omnis SDK menu Tools/Add-ons/ as Molu Software Update. Selecting it opens the Release Manager window.

The Molu Developer Tool offers a variety of features organized on tabs in the Release Manager window.

  • Add or delete a product
  • Add, update or delete a "release" for a selected product
  • Add Omnis classes and external files to a selected release
  • Deploy the release to the Molu Server

The Developer Tool controls have "tool tips" to help you learn and remember what each control does.

The two screen shots on the rigth show the Release Manager with the "release header" and "manifest contents" tabs selected.

Molu Client

In the text below, the words "directory" and "folder" are synonymous. The term "directory tree" refers to a given directory and all of its sub-directories; that is, the hierarchy of nested directories.

You will modify your application to include the calls to Molu Client. The Sample.lbs file includes all the code you need to implement the check for updates procedure in your application.

  1. Create a directory for the "end user" test installation.
  2. Install the Omnis runtime in this directory.
    Test that the Omnis runtime is working properly before continuing.
  3. Place the Molu Client library in the "startup" directory in the Omnis directory tree.
  4. Copy the window class "wSoftwareUpdate" from MoluDevelor.lbs or from the Sample.lbs into your master library.
  5. Modify the appropriate menu or window class in your application to open the "wSoftwareUpdate" window.

In the $construct method of the class "wSoftwareUpdate", you will find notes about product code and user registration information. When you add a product in the Developer Tool, you create product code. you will return to the $construct method to add the product code so the Molu server will know which product your client is trying to update.

Support Files Used By Client

The Molu Client uses three files to control the behavior, baseline.txt, receipt (plist or ini), and the preferences file. The following are used for the Pops product.

  • Application support directory
    • POPS3REL_baseline.txt
    • POPS3REL-msc4-1-receipt.plist (or .ini)
    • PopsRoyaltyManager.lcl
  • Preferences directory
    • com.mophilly.PopsRoyaltyManager3.plist (or .ini)

The application support directory provides an area for many application specific files, such as digital documents, database update scripts and so on, as well as the files listed in this section. On Windows, that begins in AppData, and on the MacOS that begins at Application Support. The path on MacOS is "~/Library/Application Support/Mophilly/POPS3REL/msu/" where "POPS3REL" is the product code. These files manage the MSU revision IDs. The "receipt" contains the last update applied and the "baseline" contains the ID from which the original install was built.

The preference file is found at "~/Library/Preferences/com.mophilly.PopsRoyaltyManager3.plist". This file contains the local connection data and other user specific information.

Test Environment Setup

Before you use Molu services, setup a test environment for your project. The test environment, or "test bed" is your standard runtime deployment installed on a machine dedicated to testing. The typical set up is the Omnis Studio runtime with a valid serialization for the Omnis Studio engine and the oXML component. It also includes the baseline libraries and files for your application.

The client test bed must be completely separate from your development tools and libraries, the "working copy". If you attempt to test the download using your working copy, the Molu Software Update client will raise errors. These errors are spurious and do not reflect the correct "live" circumstance.

The first time you run the Software Update, the client sub-system will generate local files used to manage and coordinate updates from the server. This may take a minute or so if your Omnis library is large. However, this process is only run once typically. Thereafter, the update preparation process is very quick. When updates are installed, the local files are updated to reflect the additions.

During development it may be necessary to "reset" the test. For this purpose, make a complete copy of your baseline installation that can be copied into place. There are several support files that also need to be deleted or replaced in this case. Please contact us for more specific information.

Operating Instructions

The basic work flow is...

  • Add a product
  • Create a new "release"
  • Add classes and files "release manifest", saving the "release" each time.
  • Run out a new build of the Omnis library and files.
  • Open the Omnis libraries and Molu Developer Tool, and "deploy to the server".
    This last step copies the necessary files up to the Molu Server, and makes it available to your end users.

Each release includes a "manifest" of the Omnis classes and files to be included in the release. You can create and save as many "pending" releases as you like, each with its own manifest. The pending releases can be deployed at your convenience. This means you can knock out a quick release while working on a larger update.

As you work through your development and maintenance issues you can add items to the manifest of a selected release. In practice, updating the release notes to reflect the newly added items is recommended.

QA and GM Releases

In production environments, it is wise to create a "quality assurance" (QA) release for testing by internal staff or beta users. This step can be accomodated by creating two "products", one for QA release and one for general release. For example, you may create a product code "V01" and a product code "V01QA".

In the class wSoftwareUpdate, you will need to enter the proper product code to differentiate your QA product from your general product.

Testing the End User Installation

When the upload is deployed you are ready to use the end-user installation to verify the system is working. This is an important step before announcing an update to the end-users.

NOTE: Do not attempt to update your working copy with the MoluClient module. Doing so will generate spurious errors. You must use a separate runtime for testing the "downstream" update.

If you implemented Molu Client as it is in the Sample.lbs library then this is no more difficult than opening the end user application, selecting the Software Update menu item and letting it run. Allow the update process to complete, then verify that the modifications you made have been added to the application.

  1. Open the Omnis Runtime or SDK, and launch the End User test installation.
  2. Select Software Update from the menu (that you modified for this purpose). The MoluClient module will check for updates. If it finds some it will present the release notes in the window. Otherwise, it will present a user alert saying no updates are available.
  3. If there is an update available, click “Install” to commence the updates. After downloading the update data for your application, it should complete the installation gracefully and close the Software Update window.
  4. Check the application to be certain the updated classes were installed.

If there are any errors, the MoluClient module records these in a log file that is stored in an appropriate place for the client operating system. On Windows, this is in the "AppData" directory. Mac OS X stores these in "Application Support" directory. The log will contain important information and should be sent to your support team, who can forward it to support at mophilly.

Personal tools