[p]This chapter documents the [code]Utility[/code] section in Site Administration, which provides the administrator with tools for managing and maintaining the Lasso Professional Server server. This chapter describes the following: [/p]
- SQL Browser describes how to issue SQL queries to configured databases in Site Administration.
- Email describes managing the email queue, sending a basic email message, and establishing email settings.
- • Events introduces Lasso events, and describes how they can be set and managed.
- Errors describes viewing and setting preferences for the Lasso error log.
- LassoApps describes how to build and manage LassoApps on the Lasso Professional Server server.
- Caches describes how to view and manage developer-defined caches on the Lasso Professional Server server.
[p]The [code]SQL[/code] section provides a Web-based interface that allows one to issue SQL queries to Lasso-accessible SQL databases. A Lasso-accessible SQL database is any SQLite, MySQL, or SQL-compliant JDBC database that has been set up and enabled in the Setup > Data Sources section of Site Administration. [/p]
[p]The [code]SQL Browser[/code] page is where SQL statements can be entered. The results of the query will be presented at the bottom of the page with one column for each field that is returned. The results could contain actual field data from a database search, or could contain synthetic field data which is generated by the database in order to format the results of various SQL statements and functions. See the examples that follow for more information. [/p]

- Select a data source connector from the [code]Connector[/code] pull-down menu. Only connectors to data sources that support SQL will be shown.
- Select a data source host from the [code]Host [/code]pull-down menu.
- Select a database to issue a SQL statement from the [code]Database[/code] pull-down menu. Only databases enabled in the Setup > Data Sources section will be shown.
- Enter a SQL query in the [code]SQL Statement[/code] field.
- [code]5[/code] Select the [code]Issue SQL Statement[/code] button. The results of the statement are shown in the lower panel, which by default shows [code]No Results Found[/code].
[p]A special feature of the SQL Browser is that the last ten statements entered into the [code]SQL Statement [/code]field will be displayed in a pull-down menu that appears to the right of[code] History[/code]. In order to issue a statement stored in the [code]History[/code] pull-down menu, simply select the statement from the pull-down menu, and it will automatically appear in the [code]SQL Query[/code] field. Then select [code]Issue SQL Query. [/code][/p]
[p]Selecting the Export area in the sidebar allows the results of a [code]SELECT[/code] statement to be exported. Setting one or more options and then selecting Export Results will result in a text file being sent to the browser containg the current result set. [/p]
- Format – Specifies what format the export should be in. Options include [code]Tab Delimited[/code], [code]Comma Delimited[/code], [code]SQL Inserts[/code], or or [code]XML Data[/code].
- Field Names – Specifies whether field names should be included as the first line of tab or comma delimited files. For XML data this preference controls whether field names are used as the tag names surrounding each field value or if a generic field container is used.
- Line Endings – Sets the line endings for the export to [code]n[/code], [code]r[/code], or [code]rn[/code].
[p]Selecting the[code] Options[/code] area in the sidebar allows the following options to be set: [/p]
- Show Fields – Allows the maximum number of fields displayed in the results to be selected. The options are [code]4 Fields[/code], [code]8 Fields[/code], [code]12 Fields[/code], [code]16 Fields[/code], and [code]All Fields[/code]. If more than eight fields are selected, then the results panel will expand to the right to accommodate the extra fields.
- Max Records – Allows the maximum number of records displayed in the results to be selected. The options are [code]10 Records[/code], [code]25 Records[/code], [code]50 Records[/code], [code]75 Records[/code], [code]100 Records[/code], and [code]All Records[/code].
- Max Field Lines – Allows the maximum number of lines of text to be displayed per field in the results to be selected. One line consists of approximately 20 characters horizontally. The options are [code]1 Lines[/code], [code]4 Lines[/code], [code]7 Lines[/code], [code]10 Lines[/code], and [code]All Lines[/code]. Selecting [code]All Lines[/code] will display the entire contents of the field.
- Submit on Return – If this option is set then a return in the [code]SQL Statement[/code] field will submit the statement.
[p]The Email section allows the administrator to manage the site Lasso email queue, send email, and set site email options in Lasso Professional Server. Full documentation for sending an email in Lasso Professional Server can be found in the Email chapter in the Lasso 8.5 Language Guide. [/p]
[p]The email queue can be monitored in several different ways. This section provides an overview of the tabs in the Utility > Email section, followed by more in depth information about each sub-section. [/p]
- Email Queue – Provides an overview of messages which are currently being sent by Lasso. Each message in the queue corresponds to one call to the [code][Email_Send][/code] tag. If a message is addressed to users on different SMTP servers then a message may be split into several parts. Information about one part and one error are included inline within each message display.
- Email Parts – Provides an overview of message parts which are currently being sent by Lasso. A message which is addressed to users on different SMTP servers may be split into several parts which are sent independently. Once all of the parts of a message have been sent, the message status is updated. This section allows the parts that currently being sent to be viewed. Either all parts or the parts for a single message are shown.
- Email Errors – The email sending system records errors for each message and part which is being sent. The errors section allows all errors or the errors for a single message to be shown.
- Email Routes – Allows the SMTP routes which have been looked up to be viewed and modified.
- Email Send – Allows an email to be sent through Lasso for testing.
- Setup – The preferences for the email sending system can be configured in this section.
[p]The email queue logs all email messages that are sent from within Site Administration or via the [code][Email_Send][/code] tag. Messages remain in the queue while they are being sent to the SMTP mail server looked up by Lasso or specified in the [code][Email_Send][/code] tag by the developer. For more information, see the Email chapter in the Lasso 8.5 Language Guide. [/p]
[p]Selecting the [code]Stop Queue[/code] temporarily suspends email from sending. This allows the administrator to inspect the state of the email queue without messages sending. The button then changes to [code]Start Queue, [/code]and can be re-selected to start email sending again. Emails are sent when the server is restarted even if the email queue is stopped. [/p]
[p]Each message may include one or more parts depending on the recipients of the message. A message to one recipient always has one part. If a message has several recipients who are in different domains then the message will be split into one part per domain. Information about the first part of a message is shown inline within the message display. The message display also includes the most recent error returned for the message. [/p]
[p]Messages in the queue can be viewed by status by selecting a message category from the pull-down menu in top panel, and then selecting the [code]Select[/code] button. These categories are as listed below. [/p]
- All Messages – Shows all messages in the email queue.
- Queued Messages – Shows messages currently queued in the email queue.
- Sent Messages – Shows all messages that have been sent previously in the email queue.
- Message Errors – Shows all messages that were unable to be sent in the email queue due to an error.

[p]The following actions can be performed on a single message or on multiple messages using the controls to the left. [/p]
- Try Now – Available for queued messages. Instructs Lasso to attempt to send the message now without waiting for the retry delay to pass.
- Requeue – Available for messages which have encountered an error. Instructs Lasso to queue the message again from scratch. Messages should be requeued if there was an issue with the local SMTP server or after modifing Lasso’s email settings to clear up an error.
- Hold – Holds a message indefinitely.
- Resume – Resumes sending a held message.
- Delete – Deletes a message, permanently removing it from the queue. If the message has multiple parts they will be deleted as well.
- Show All – Shows all parts or errors for a message.
- Clear – Clears the errors for a message.
[p]This section lists all of the message parts which Lasso currently has in its queue. The same controls as shown above for the email queue also work in this section. By default the parts of all messages are shown, but if a [code]Show All[/code] link is followed from a message part in the email queue then only parts for that message are shown. [/p]
[p]This section lists all of the errors which the email sending system has encountered. It works similarly to the Utility > Errors section which shows general Lasso errors. By default the errors encountered while sending all messages are shown, but if a [code]Show All[/code] link is followed from a message error in the email or parts queues then only errors for that message are shown. [/p]
[p]When Lasso sends an email message it first looks up the SMTP server for the recipient of the message using a domain name server. The address of that SMTP server is stored as the route for the domain. The email routes section can be used to view the Cached Routes which Lasso has looked up. [/p]
[p]The User Routes allow custom routes to be specified for particular domains. For example, the local domain may need to route to an internal SMTP server rather than the Internet-facing server. The email routes section allows user routes to be created for these special cases. A user route includes the following fields. [/p]
- Domain – The domain must correspond to the domain which will be seen in the recipients of email messages. Email to [code]joe@example.com[/code] has a domain of [code]example.com[/code].
- Host – The host name or IP address of the SMTP server to send messages for the domain to.
- Port – The port to use on the SMTP server. Leave blank to use the default.
- Username – The username to use for SMTP authentication on the SMTP server. This is usually left blank since authentication is not normally required for sending messages to a domain’s target SMTP server.
- Password – The password to use for SMTP authentication.
- Retry Delay – The retry delay for messages to this SMTP server in seconds.
- Timeout – The timeout for connections to this SMTP server in seconds.
- Encryption – If encryption is enabled then SSL/TLS will be used to encrypt all communication to the SMTP server. This setting should be used only when needed since the encryption incurs significant overhead and may slow down mail operations.
- Comment – Allows a comment about the route to be recorded so the administrator can later remember why it was added.

[p]The [code]Send Email[/code] page allows email messages to be sent. After the message is queued, one returns to the [code]Email Queue[/code] page. While Lasso Professional Server provides robust support for custom email sending programmed within your Lasso pages, the [code]Send Mail [/code]form allows the administrator to quickly test email sending. [/p]

- Enter the email host name in the [code]SMTP Host [/code]field and the [code]SMTP Port[/code] and [code]SMTP AUTH Username[/code] and [code]Password[/code] if required.
- Enter the recipient’s email address in the [code]To[/code] field.
- 3 Enter the sender’s email address in the [code]From[/code] field.
- 4 Enter the subject of the email in the [code]Subject [/code]field.
- 5 Enter the body of the email in the[code] Body[/code] field.
- 6 Enter the email address of any carbon-copy recipients in the [code]CC[/code] field (optional).
- Enter the email address of any blind carbon-copy recipients in the [code]BCC[/code] field (optional).
- Select the [code]Send Message[/code] button. The message will be inserted into the email queue database and sent out per settings specified on the [code]Email Setup [/code]page.
[p]The[code] Setup [/code]page allows one to set preferences for the[code] [Email_Send] [/code]tag. This includes setting the administrator email address, default host IP address, message retention, and system automation. [/p]

[p]The following describes the options in the [code]Send Email [/code]page: [/p]
- [def]Send Directly to SMTP Servers[/def] – If set to yes then Lasso will attempt to send messages directly to the recipients SMTP server.
- [def]Ignore [Email_Send] -Host Params[/def] – If set to yes then Lasso will always send messages based on the preferences set on this page and will ignore [code]-Host[/code], [code]-Port[/code], [code]-Username[/code], [code]-Password[/code], and [code]-Timeout[/code] parameters specified in the [code][Email_Send][/code] tag.
- [def]Default SMTP Host[/def] – The default SMTP server for sending email. If this is specified then the [code]Host [/code]field in the [code]Send Email [/code]page and the [code]-Host[/code] parameter in the[code] [Send_Email] [/code]tag are optional.
- [def]Default SMTP Port[/def] – An alternate port to connect to on the SMTP host. This will usually be set to the default of [code]25[/code].
- [def]SMTP Host Timeout[/def] – The number of seconds Lasso should wait before timing out the remote host. This will usually be set to the default of [code]15[/code] seconds.
- [def]SMTP AUTH Username and Password[/def] – Optional username and password to use for SMTP AUTH authentication on the default SMTP host.
- [def]Maximum Retries[/def] – The maximum number of times a message send will be attempted ([code]5 [/code]attempts by default).
- [def]Email Retry Delay[/def] – The number of seconds to pause between retrying a message send ([code]30[/code] seconds by default).
- [def]Email Sweep Delay[/def] – The amount of time the email sender sleeps before it checks to see if there are any messages to send ([code]15[/code] seconds by default).
- [def]Retain Successful Messages[/def] – Retains details about messages that have been successfully sent in the email queue ([code]No[/code] by default).
- •[def] [/def][def]Retain Error Messages[/def] – Retains messages which have an error when sending ([code]Yes[/code] by default).
- [def]Retain Encoded Messages in Log[/def] – Retains the full MIME encoded messages using the options above. Otherwise, only the headers are retained ([code]No[/code] by default).
- [def]Maximum # Queues[/def] – The maximum number of outgoing SMTP connections which should be made (5 by default).
- [def]Send # Messages Per Connection[/def] – The maximum number of messages that should be sent to a single server in one connection (100 by default).
- [def]Override Lasso Service IP [/def]– The IP address which should be sent to remote SMTP servers. If blank (the default) the actual IP address of the machine hosting Lasso Service will be used. This should only be set to a different value for multi-homed servers or if serving from behind a NAT service or firewall.
[p]Email settings can be changed by entering new values for the options above and selecting the [code]Update[/code] button. Selecting the [code]Stop Mail Queue[/code] button stops the email queue while site options are being set. [/p]
[p]The [code]Events[/code] section allows the administrator to list events, get the status of an event, clear the event queue, or delete events that have been scheduled. Additional documentation on events and the [code][Event_Schedule] [/code]tag can be found in the Control Tags chapter in the Lasso Professional Server Language Guide. [/p]
[p]Events in Lasso Professional Server take the form of URL requests. For user-defined URL requests, the event scheduler can operates as a virtual site visitor which visits specific URLs at specific times. The event scheduler can be used to schedule page loads on the local server or even on remote servers. [/p]
[p]Normally, the pages which the event scheduler has been programmed to visit will be pages which perform specific tasks that only the event scheduler has access to. For example, a folder named [code]Events[/code] could be created, and all pages that the event scheduler calls could be placed in it. A file [code]SendEmail.lasso[/code] would then be scheduled as: [/p]
[pre]http://www.example.com/Events/SendEmail.lasso [/pre]
[p]Events can be scheduled to execute at a specific time, but the actual time the event is executed may vary based on server traffic and other conditions. Events can only be certain to execute within one minute of their scheduled time. [/p]
[p]The [code]Event Queue[/code] page provides a list of scheduled events. The events can be filtered by type, and events can be deleted if they have not yet been performed. [/p]
[p]All events that have been scheduled and not performed yet are shown in the queue. If an event repeats over time, then it will remain in the queue until the administrator-defined period for that event has ended. Once an event has ended, it is removed from the queue. [/p]

[p]The last error for each event is shown inline within the event display. Each event also supports the following actions. [/p]
- Pause – Temporarily pauses an event.
- Resume – Resumes executing a paused event.
- Edit – Allows the event to be edited so the URL or frequency of a recurring event can be adjusted. Events are automatically paused when they are being edited and resumes once the editing is complete.
- Delete – Permanently removes the event from the queue.
[p]Selecting the [code]Pause All Events[/code] temporarily suspends all queued events from being executed. This allows the administrator to delete events that are causing problems or schedule a batch of events. The button then changes to [code]Resume Events, [/code]and can be re
-selected to start event execution again. Events are restarted when the server is restarted even if the event queue is stopped. [/p]
[p]The panel shows all queued events for the selected queue that have not been performed yet. The URL, time of next run, start and end dates (for repeating events), options, and username are shown for each event. The administrator may delete an event from the current queue by selecting the [code]Delete[/code] link under [code]Actions[/code] for that event. [/p]
[p]Selecting the [code]Delete All Events [/code]button in the sidebar removes all shown events from the queue shown. [/p]
[p]This section lists all of the errors which the event scheduling system has encountered. It works similarly to the Utility > Errors section which shows general Lasso errors. By default the errors encountered while executing all events are shown, but if a [code]Show All[/code] link is followed from an event in the event queue then only errors for that event are shown. [/p]
[p]The [code]Schedule Event [/code]page provides a convenient interface for scheduling events. Events can also be scheduled programmatically via the [code][Event_Schedule][/code] tag, as discussed in the Control Tags chapter in the Lasso 8.5 Language Guide. All scheduled events can be viewed in the [code]Event Queue[/code] page. [/p]

[p]The [code]Perform Event[/code] pull-down menu specifies how often an event should be run. The remaining fields in the [code]Schedule Event[/code] page will vary depending on which option is selected for [code]Perform Event[/code], and the options are as follows: [/p]
- [def]Once[/def] – Event is performed once at a specified date and time.
- [def]Weekly[/def] – Event is repeated once a week on a specified day and time between the [code]Start Date/Time [/code]and[code] End Date/Time[/code].
- [def]Daily[/def] – Event is repeated once a week on a specified day and time between the [code]Start Date/Time [/code]and[code] End Date/Time[/code].
- [def]Custom Repeat[/def] – Event is repeated at a specified time interval (in minutes) between the [code]Start Date/Time [/code]and[code] End Date/Time[/code].
- Because the input fields vary for each option, scheduling an event to be performed once, weekly, daily, and in a custom repeating fashion are described in separate procedures below.
- Enter the URL address of the event in the [code]Event URL[/code] field.
- [code] [/code]2[code] [/code]Enter the specific date and time on which the event will occur in the [code]Event Date/Time[/code] field ([code]mm/dd/yyyy hh:mm:ss[/code] format).
- Select [code]Yes[/code] or [code]No[/code] from the pull-down menu in the [code]Continue After Restart[/code] field. If set to [code]Yes[/code], the event will continue after the Web server is stopped and restarted.
- Enter any username required to perform the event in the [code]Username[/code] field (optional). An event will require a username if the page to be loaded is protected by Lasso Security, and requires a username for access. For more information on usernames, see the Setting Up Security chapter.
- Enter any password required to perform the event in the [code]Password[/code] field (optional). The same conditions apply to passwords as for usernames.
- 6 Select [code]Schedule Event[/code].
- Enter the URL address of the event in the [code]Event URL[/code] field.
- [def]2[/def] Select a day of the week on which the event will be performed from the [code]Day of Week[/code] pull-down menu (e.g. [code]Sunday[/code], [code]Monday[/code], …).
- Enter the time of day on which the event will be performed from the [code]Time of Day[/code] pull-down menu (24-hour [code]hh:mm:ss[/code] format).
- 4 Enter the start date of the event in the [code]Start Date/TIme[/code] field. The date on which a repeating event is scheduled to start. The format is [code]mm/dd/yyyy hh:mm:ss[/code]. If the start date is specified without a time, the time will default to [code]00:00:00[/code] (12:00 AM).
- Enter the ending date of the event in the [code]End Date/Time[/code] field. The date when a repeating event is scheduled to end. The format is the same as[code] Start Date/Time[/code].
- Select [code]Yes[/code] or [code]No[/code] from the pull-down menu in the [code]Continue After Restart[/code] field. If set to [code]Yes[/code], the event will continue after the Web server is stopped and restarted.
- Enter any username required to perform the event in the [code]Username[/code] field (optional). An event will require a username if the page to be loaded is protected by Lasso Security, and requires a username for access. For more information on usernames, see the Setting Up Security chapter.
- Enter any password required to perform the event in the [code]Password[/code] field (optional). The same conditions apply to passwords as for usernames.
- Select [code]Schedule Event[/code].
- Enter the URL address of the event in the [code]Event URL[/code] field.
- Enter the time of day on which the event will be performed from the [code]Time of Day[/code] pull-down menu (24-hour [code]hh:mm:ss[/code] format).
- 3 Enter the start date of the event in the [code]Start Date/Time[/code] field. The date on which a repeating event is scheduled to start. The format is [code]mm/dd/yyyy hh:mm:ss[/code]. If the start date is specified without a time, the time will default to [code]00:00:00[/code] (12:00 AM).
- Enter the ending date of the event in the [code]End Date/Time[/code] field. The date when a repeating event is scheduled to end. The format is the same as[code] Start Date/Time[/code].
- Select [code]Yes[/code] or [code]No[/code] from the pull-down menu in the [code]Continue After Restart[/code] field. If set to [code]Yes[/code], the event will continue after the Web server is stopped and restarted.
- Enter any username required to perform the event in the [code]Username[/code] field (optional). An event will require a username if the page to be loaded is protected by Lasso Security, and requires a username for access. For more information on usernames, see the Setting Up Security chapter.
- Enter any password required to perform the event in the [code]Password[/code] field (optional). The same conditions apply to passwords as for usernames.
- Select [code]Schedule Event[/code].
- Enter the URL address of the event in the [code]Event URL[/code] field.
- 2 Enter the number of minutes at the beginning of the start date after which you want the event to begin in the [code]Repeat Delay[/code] field. [code]Repeat Delay[/code][def] [/def]is the interval (in minutes) by which an event will repeat.
- 3 Enter the start date of the event in the [code]Start Date/Time[/code] field. The date on which a repeating event is scheduled to start. The format is [code]mm/dd/yyyy hh:mm:ss[/code]. If the start date is specified without a time, the time will default to [code]00:00:00[/code] (12:00 AM).
- Enter the ending date of the event in the [code]End Date/Time[/code] field. The date when a repeating event is scheduled to end. The format is the same as[code] Start Date/Time[/code].
- Select [code]Yes[/code] or [code]No[/code] from the pull-down menu in the [code]Continue After Restart[/code] field. If set to [code]Yes[/code], the event will continue after the Web server is stopped and restarted.
- Enter any username required to perform the event in the [code]Username[/code] field (optional). An event will require a username if the page to be loaded is protected by Lasso Security, and requires a username for access. For more information on usernames, see the Setting Up Security chapter.
- Enter any password required to perform the event in the [code]Password[/code] field (optional). The same conditions apply to passwords as for usernames.
- Select [code]Schedule Event[/code].
[p]The [code]Errors[/code] section allows the administrator to view and delete errors, warnings detail messages, deprecated functionality warnings, and action statements that have been logged both internally in Lasso Professional Server and via the [code][Log][/code] tag, as well as set site logging options. For more information on the [code][Log][/code] tag, see the Files and Logging chapter in the Lasso 8.5 Language Guide. [/p]
[note][b]Important: [/b]Configuring error logging in Site Administration is not the same thing as configuring page-level error handling, such as for syntax errors and security errors. Page-level error handling is described in the Error Reporting chapter of the Lasso 8.5 Language Guide. The default Lasso error page can be configured in the Setup > Site > Syntax section of Site Administration. [/note]
[p]The [code]Lasso Errors[/code] page lists all errors and system messages stored in the [code]Lasso_Internal[/code] database. Errors and system messages can also be deleted within this interface. [/p]

[p]The[code] Lasso Errors [/code]page contains a list of all error messages received by their date, time, level, and message. The list is navigable via the[code] Prev[/code] and [code]Next [/code]buttons at the bottom of the panel. [/p]
[p]The[code] Lasso Errors[/code] pull-down menu allows messages to be filtered by level, which includes [code]Critical Errors[/code], [code]Warnings[/code], [code]Details[/code], [code]Action Statements[/code], and [code]Deprecated[/code]. Each error level is described individually in the following Error Log Setup section. Individual Lasso page and database errors are not logged here, but are rather controlled using the [code][Error…][/code] tags. For more information, see the Error Control chapter in the Lasso 8.5 Language Guide. [/p]
[p]Selecting the [code]Delete Errors Shown[/code] button deletes only the errors shown in the current panel, while selecting the[code] Delete All Errors [/code]button deletes all errors in the current selected category. Aconfirmation dialog box will be displayed upon selecting either of these buttons. [/p]
[p]The [code]Setup[/code] page allows the administrator to set site logging options for Lasso Professional Server. These logging options are not limited to errors, and any feedback that occurs within the Lasso Service console can be logged for display in the [code]Lasso Errors[/code] page. [/p]

[p]The [code]Error Setup[/code] panel allows the administrator to set unique log routing for the five log levels: [/p]
- Critical Errors – This includes fatal errors that affect the overall functionality of Lasso Professional Server. This can include startup errors, module and connector errors, and system-related errors that cause Lasso Professional Server not to function properly.
- Warnings – This includes non-fatal errors that do not affect the overall functionality of Lasso Professional Server, but the administrator should be aware of. This can include non-fatal startup errors, duplicate module or connector errors, SQL status errors, and logging errors.
- Details – This logs all processes performed by Lasso Service, which are not limited to errors.
- Deprecated – This logs warnings when deprecated tags or other functionality are used. Any deprecated tags or functionality may not be supported in a future version of Lasso.
- Action Statements – This logs the action statements (e.g. SQL statements) from inline database actions.
[p]For each feedback type, the administrator can choose to log or display feedback in any of the following three places: [/p]
- Lasso Service Console – If selected, feedback will be displayed in the Lasso Service console window when Lasso Service has been started as an application. For more information on starting Lasso Service as an application, see the configuration chapters of this guide.
- Error Database – If selected, feedback will be logged to the [code]_Errors[/code] table in the [code]Lasso_Internal[/code] database and displayed in the [code]Lasso Errors[/code] page in Site Administration.
- [note][b]Note: [/b]The _Errors table will store a maximum of 10,000 records. Once this limit has been reached, the oldest records will automatically be deleted. [/note]
- LassoErrors.txt – If selected, feedback will be logged to the [code]LassoErrors.txt[/code] file in the [code]Lasso Professional Server[/code] folder in the hard drive.
[p]Options are changed by checking or unchecking the desired values in the [code]Error Setup[/code] panel and selecting the [code]Update[/code] button. The [code]Reset[/code] button returns all options to their default values. Selecting the [code]Refresh [/code]button reloads the[code] Setup[/code] page with its currently stored values. [/p]
[note][b]Note: [/b]For information on how to programmatically log custom data to the logs described above, see the Files and Logging chapter in the Lasso 8.5 Language Guide. [/note]
[p][code]The [/code]Utility > LassoApps[code] [/code]section in Site Administration allows administrators to create and manage LassoApps. The following is an introduction to LassoApps, and describes how they can be used. [/p]
[p]LassoApps (short for “Lasso Applications”) allow entire Lasso solutions—including Lasso pages, html pages, images, and any other files—to be compiled into a single file called a LassoApp. Once a LassoApp has been compiled, the original Lasso code can no longer be viewed (client-side or server-side). LassoApps are served from a Web server using Lasso Professional Server, and are capable of the same functionality as traditional Lasso pages. [/p]
[note][b]Important [/b]– Although it is difficult to extract the original LassoScript from a LassoApp it is possible to see the strings that are referenced within the LassoApp. LassoApps should be used to protect your LassoScript code, but are not a recommended method of storing passwords or other sensitive data. [/note]
[p]LassoApps are useful for hiding implementation details, locking Lasso pages, selling locked solutions, and installing pre-compiled solutions. Just like regular Lasso pages, LassoApps are portable and cross-platform compatible. LassoApps also offer the following advantages over regular Lasso pages. [/p]
- Performance – Performance is enhanced over regular Lasso pages due to the file existing as a single, cohesive unit. Once a LassoApp is read by Lasso once, it is cached in the RAM memory of the Web server and is no longer accessed from the hard disk until it is dumped from memory or the system is restarted.
- Size – LassoApps take up less disk space than the sum of its Lasso pages since the overhead associated with multiple files (file headers, image files, etc.) is reduced.
- Security – The code within a LassoApp is stored securely into a single file and cannot be viewed in a text or HTML editor. There is no way to extract Lasso pages from a LassoApp.
- Portability – LassoApps are easily portable since they consist of only one file, and all file paths to the different parts of the solution are retained internally.
[p]LassoApp file names end with the [code].LassoApp[/code] extension, instead of [code].html[/code] or [code].lasso[/code]. The ability to serve LassoApps must be enabled within Lasso Professional Server site settings in order to serve LassoApps. If LassoApp serving is not enabled in Site Administration, then the user will receive a security error. [/p]
[p]The functionality within LassoApps is only effective if the functions being performed by the LassoApp are permitted by Site Administration. LassoApp developers have the ability to create routines for checking whether or not the necessary permissions and settings are enabled, and instruct the administrator on what to do to configure Lasso Professional Server settings for use with specific LassoApps. For further information on LassoApps, see the LassoApps chapter in the Lasso 8.5 Language Guide. [/p]
[p]LassoApps can be created by the Lasso site administrator in the Utility > LassoApps > Build section of Site Administration. Creating a LassoApp involves supplying three pieces of information: [/p]
- The LassoApp root folder, which is the folder that contains all Lasso pages, HTML pages, images, and any other files to be compiled.
- The LassoApp root file, which is the default page or start page for the Lasso solution to be compiled.
- The file name for the compiled LassoApp.
[p]Before building a LassoApp, all links to files within the LassoApp root folder must be replaced with the [code][LassoApp_Link][/code] Lasso tag. The [code][LassoApp_Link] [/code]Lasso tag is what allows internal navigation between pages in a LassoApp. Links to files outside of the LassoApp root folder do not need to be formatted with this tag. Below are examples of how to express links within Lasso pages contained within a LassoApp. [/p]
- Links to files within the LassoApp root folder:
[pre]<a href="page.html">Link</a> [/pre]
[pre]
<a href="[LassoApp_Link:'page.html']">Link</a> [/pre]
- Forms within the LassoApp root folder:
[pre]<Form Action="page.html"> … </Form> [/pre]
[pre]
<Form Action="[LassoApp_Link:'page.html']"> … </Form> [/pre]
- Images within the LassoApp root folder:
[pre]<Img src="/folder/picture.jpg"> [/pre]
[pre]
<Img src="[LassoApp_Link:'/folder/picture.jpg']"> [/pre]
[p]All links to files within the LassoApp root folder need to be formatted as shown above before using [code]LassoApp Builder[/code]. Not doing this will prevent the LassoApp from being created. For more information on preparing Lasso pages to be converted into a LassoApp, see the LassoApps chapter in the Lasso 8.5 Language Guide. [/p]
[note][b]Note: [/b]Adding these tags in regular Lasso pages will not affect how the links, forms, and images function. Lasso will ignore these tags until they are compiled into a LassoApp using [code]LassoApp Builder[/code]. [/note]
[p]The Utility > LassoApps > Build[code] [/code]section of Site Administration is where LassoApps can be compiled. [/p]

- Format all links to files within the LassoApp source files using the [code][LassoApp_Link][/code] tag as shown previously.
- The folder containing the LassoApp should be located within your Web server root. Note the URL that would be used to access these LassoApp files. For example:
[pre]http://www.example.com/myLassoApp/default.lasso [/pre]
- Go to the Utility > LassoApps > Build section of Site Administration.
- Select [code]Custom Root…[/code] from the [code]LassoApp Folder[/code] pop-up menu. Specify the path to the folder containing your LassoApp from the root of the Web server. The for the example URL shown above the path would be:
[pre]/myLassoApp/ [/pre]
- Enter the name of the default page for the solution in the [code]Entry File[/code] field. The [code]Entry File[/code] is the first page the user will see when accessing the LassoApp. For the example URL shown above the entry file would be::
[pre] default.lasso [/pre]
- Select [code]Create LassoApp[/code]. This will create a LassoApp with the same name as the folder that contains the LassoApp files within your Web server root. The LassoApp created using the instructions above would be located at this URL:
[pre]http://www.example.com/myLassoApp.LassoApp [/pre]
- Alternately, select [code]Download LassoApp[/code]. This will create the LassoApp with the same name as the folder that contains the LassoApp files within your Web server root. The LassoApp is then downloaded by your Web browser and can be moved from the download location into the Web server root.
[p]For more information on creating LassoApps, see the
LassoApps chapter.
in the Lasso 8.5 Language Guide. [/p]
[note][b]Note: [/b]It is also possible to create LassoApps by placing the LassoApp folder in a [code]BuildLassoApps[/code] folder within the [code]LassoAdmin[/code] folder of the current site. The current site must have been granted permission to access this folder by the server administrator. For the default site the full path to this folder would be: [/note]
[pre]…/Lasso Professional 8/LassoSites/1-default/LassoAdmin/BuildLassoApps/ [/pre]
[p]When a LassoApp is first called in a Web browser, it gets cached in the computers’s RAM for efficient serving. If a new version of a particular LassoApp is loaded to the Web server, then the LassoApp will need to be removed from the system cache before the new version can be accessed. [/p]
[p]The Utility > LassoApps > List section is where the administrator can view the names of LassoApps that have been loaded on the server, and dump them from the system cache. [/p]

[p]In the [code]LassoApp Cache[/code] panel, select the [code]minus (-)[/code] button next to the name of the LassoApp (e.g.[code] MyLassoApp.LassoApp[/code]) to dump from memory. This panel contains all LassoApps that have been served by Lasso Professional Server since startup. [/p]
[p]Selecting [code]Dump All LassoApps[/code] will remove all LassoApps from the system cache. After LassoApps have been dumped from the system cache, new versions of the LassoApps may be loaded. [/p]
[p]The Utility > LassoApps > Setup section is where the administrator can enable or disable LassoApps in Lasso Professional Server. [/p]

[p]Disabling LassoApps prevents the execution of any custom or third party LassoApp not included with Lasso Professional Server. The LassoApps that cannot be disabled are [code]Admin.LassoApp[/code], [code]GroupAdmin.LassoApp[/code], [code]LassoScriptReference.LassoApp[/code], and [code]Setup.LassoApp[/code] in the [code]LassoStartup [/code]folder. [/p]
- In the [code]Settings[/code] panel, select [code]Enabled[/code] or [code]Disabled[/code] from the [code]LassoApps[/code] pull down menu.
- Select the [code]Update[/code] button.
[p]New caching tags in Lasso Professional Server make it possible for developers to cache content in their pages using the [code][Cache] … [/Cache][/code] tags. These custom caches are stored in memory on the server. These caching tags allow developers to reduce database and server load by having Lasso only recalculate various portions of a page periodically. [/p]
[p]The Lasso site administrator has global control over all caches stored on the Lasso Professional Server server. The Utility > Cache section of Site Administration provides information about all current caches, allows caches to be reset, and allows preferences for the caching mechanism to be set. [/p]
[p]The Utility > Cache > List page in Site Administration provides a list of active caches on the server, including cache name, the size of cached data, and the efficiency of the cache. This page also provides total cache usage statistics since Lasso was started (cache statistics always reset when Lasso Service is restarted). [/p]

[p]The [code]Cache List [/code]panel displays a list of all caches that have been served by Lasso Professional Server since startup, the size and data type of cached data, and an efficiency score. A cache’s efficiency score is the number of times the cache has been loaded minus the number of times it has been refreshed or expired, then divided by the number of loads (loads - stores / loads). Clicking the [code]Refresh[/code] button updates the panel with the latest information. [/p]
[p]Clicking on the name of a cache shows the[code] Cache Detail [/code]panel to the right, where statistics about the cache may be viewed, and the cache can be deleted or refreshed. Refreshing a cache allows cache statistics to persist, whereas deleting a cache does not. [/p]
- Select the name of the cache to reset from memory in the [code]Cache List [/code]panel. This panel contains the names of all caches that have been loaded on the Lasso Professional Server server.
- In the [code]Cache Detail[/code] panel, Select the [code]Expire Now[/code] button. Once a cache is manually expired, its contents will be refreshed the next time it is loaded.
- Select the name of the cache to delete from memory in the [code]Cache List [/code]panel.
- In the [code]Cache Detail[/code] panel, Select the [code]Delete[/code] button. Once a cache is deleted, it is completely removed from the system memory (including the statistics for the cache) until it is loaded again.
[p]The Utility > Cache > List page in Site Administration allows site cache preferences to be set. These preferences apply to all caches loaded on the server, and will override any preferences set by developers. [/p]

[p]The following cache preferences may be set: [/p]
- Allow Caching – Globally enables or disables the [code][Cache_…][/code] tags on the Lasso Professional Server server.
- Maximum Expiration – A global option for the maximum length of time (in minutes) that any cached content can be stored before it is automatically reset.
- Maximum Cache Size – Specifies an upper limit on the amount of data (in kilobytes) that can be stored in a cache. Defaults to [code]32[/code].
- Host Specific Caches – Specified whether or not caches may be accessed across different host names (as output by the [[code]Server_Name][/code] tag).