Binary file rules are one form of static content — rules that do not depend on clipboard values. When you save this form or check in a binary file rule, any previous file on the Web server corresponding to the rule name and the ruleset and version is deleted.
The first time a requestor asks for this file (for example, with <IMG SRC= > HTML reference), the file is extracted from the rule into an appropriate Web server directory. The directory name is based on a hash code derived from the requestor's ruleset list. Later requests are served directly from the file system.
Standard binary file rules define the appearance of icons and navigation elements on the harness forms for work items in your application. You cannot modify the standard rules, but you can override them with your images of the same size if you choose. This approach doesn't requiring finding or overriding the HTML references to the images.
For example, you can override the Designer Studio home image (logo_metal.gif) with your company or application logo. Copy the standard rule and upload a replacement GIF that is 81 pixels wide and 46 pixels tall.
Use the Image Library landing page (Designer Studio > User Interface >Image Library to review the images stored in binary file rules.
When you use the Save As toolbar operation to copy a text file rule that contains CSS styles into a different ruleset, a warning appears if the CSS text references images (that is, binary file rules) that are not available to you. Note the names of these images and copy or create them into your application ruleset.
When you save a flow rule, the system automatically creates a related binary file rule containing the JPG image of the flow diagram. These rules support the initial display of static flow diagrams on the Diagram tab of the Flow form. To save storage space, the system does not retain history for these generated flows. The latest version of the diagram image is contained in the rule, overriding any older image.
When you upload a binary file into this rule, the system converts and stores it internally in a Base64 format. Oracle and Microsoft SQL Server can process this value in an endian-independent, character-set independent way. When extracted or downloaded, the file is reconverted to its original format.
When a requestor session first requests this binary object, the image file is extracted from the rule into an appropriate Web server directory on the server. It determines the destination directory from the second key part of the rule, the ruleset and version, and the Use latest version check box. If an older copy of the file exists, the older copy is overwritten.
Later HTTP requests for the same binary object (and the same ruleset and version) are served from the directory copy, for fast response.
Browsers use a workstation cache of recently received files. By default, static content such as images are marked to remain in the cache for 24 hours. To make a newly updated or overridden binary file rule containing an image reach users, you can do any of the following:
defaultcachingtimeout element in the prconfig.xml file to a value lower than the default of 86,400 seconds (24 hours). This affects the expiration date in HTTP header sent to the browser. For example: <env name="http/defaultcachingtimeout" value="6000" />
A lower value causes more HTTP traffic and so can adversely affect response time.
As an alternative to updating the prconfig.xml file, you can use Dynamic System Settings to configure your application. See Dynamic System Settings data instances.
If authorized, you can use the System Management application to delete all extracted static files from the HTTP server directory structure (on a specified node), forcing them to be extracted again on demand.
The binaryfile JSP tag allows a binary file to be included in a stream sent to the browser through the static JSP tag.