Zulu

Zulu is an application that keeps your calendar events in sync with FileMaker records. It is able to sync with Apple Calendar, Google Calendar, and Exchange Outlook Calendar. You can manipulate the events in your calendar, and Zulu will write these changes to FileMaker records. The opposite is also true, updates to FileMaker records will be written to your calendar's events. Zulu will even respect FileMaker’s record level access privileges and record locking, so you can filter records based on privilege set.

If the answer you are looking for is not found in this documentation, please feel free to email us at support@360works.com, or give us a call at (770) 234-9293.

To Demo and Purchase

See the 360Works Zulu page to download a demo of 360Works Zulu, view pricing, or purchase it.

Quick Start

Run the Mac or Windows Installer included with the download on the same machine running FileMaker Server. See here for more details: Zulu - Installation
Upload the Zulu2SampleData.fmp12 file to your FileMaker Server.
Open the hosted Zulu2SampleData.fmp12.
- username: admin
- password: admin
Go to the ZuluCalendarList layout
Press the "Publish" button
- You will be prompted for the databases credentials, use the above credentials to log in

Apple Calendar

Set up your Apple Calendars with Zulu: Integrating With Apple Calendar
In those instructions, your parameters will be:
- Server Path: /zulu/calendars/Zulu2SampleData
- Username: admin
- Password: admin

Google Calendar

See this section for instructions to set up a Google Calendar sync

Exchange Calendar

Set up an Exchange Outlook Calendar sync: Zulu - Syncing with Exchange Outlook Calendars

Upgrading From Zulu 2

There have been many backend changes to Zulu starting in Zulu 3 so if you are upgrading from Zulu 2 to a later version, you will likely need to take steps to get your calendars working again. Instructions vary depending on the type of calendars you are syncing. Please see the appropriate section below for your use case.

When Using Apple Calendars

Install the new version of Zulu, and register your application again.
You will need to re-publish your calendars in order to get Apple Calendars working again. See here for more details: Calendars and Publishing

When Syncing with Google or Exchange Calendars

Install the new version of Zulu, and register your application again.
You will need to re-publish your calendars, as the field mapping data has changed since Zulu 2: Calendars and Publishing
After re-publishing, you will need to re-create your syncing configurations again. Refer to these links for more info on how to set up a syncing configuration:
- Google: Syncing with Google Calendars
- Exchange: Syncing with Exchange Outlook Calendars

Zulu.xml Customization

The Zulu installer will not overwrite an existing zulu.xml file. This is good because if you had customizations here, they will not be replaced if you were to install a new version of Zulu. The downside to this is that we have added a few more customization options to the zulu.xml file that you may want to take advantage of. You can see a list of customization options available in the zulu.xml file here: Zulu - Advanced Settings

You can download the latest version of the zulu.xml file here: zulu.xml

Compare this file with the one you are using, and you can copy parameters into your own zulu.xml file if you want the customization option.

Installation

Setup and Installation

Standard Installation

Prerequisites

Zulu requires FileMaker Server, be sure this is installed.
Zulu uses the XML Web Publishing engine. See more about enabling that, and allowing accounts to use XML here: Enable XML FileMaker 17
FileMaker Server 18.03 no longer automatically installs Java, and the XML Web Publishing Engine needs to be manually configured. See more about enabling that here: Changes to Java in FileMaker Server 18.03
FileMaker Pro 16 or later
Note: If you are upgrading from Zulu 2, you will need to re-publish your calendars and re-create your sync configurations
Note: FileMaker Cloud does not have a web publishing engine which is a requirement for Zulu and thus is not a supported environment.

Installation Steps

Mac and Windows

Unzip the package downloaded from the Zulu product page.
Run the installer provided in the package.
Follow the installer prompts, entering a username and password when prompted. (this is your sync admin password, write it down!)

Linux

Please see the instructions here

Post Installation

Register Zulu when the Welcome Page launches. (if you're using other 360Works products, and would like to try the demo license, simply restart the Tomcat Application Server using the 360Works Admin tool. To see more about registration, see here: Registration
Zulu expects to be installed on the same machine as FileMaker Server. If you are running Zulu on a different machine, see Zulu - Advanced Settings
If you are syncing with Google calendars we recommend setting up your own Google Api Key, so you are not using the 360Works shared key that's included by default. See this video for instructions: Google Generate API Key

Custom Installation

Users who need a more customized solution may choose to perform a manual installation of the Zulu software. Zulu runs on your server as an Apache Tomcat application, so you will need to download and install the Apache Tomcat server application for your operating system. (this may involve setting Tomcat up to start automatically with your system, as well as configuring your web server to forward traffic for Zulu to port 80). Installing Zulu inside the FileMaker Server Web Publishing Engine is no longer supported.

Prerequisites

Check your Java version to make sure you are running at least Java 6
Be sure FileMaker Server is installed and running with XML Custom Web Publishing enabled. (FMS does not need to necessarily run on the same machine as Zulu, but is required for Zulu to function.)
Download and install Apache Tomcat 9.x from https://tomcat.apache.org/, for Windows make sure to download the installer
Follow Tomcat documentation for running Tomcat as server, for Windows make to make the service selection during installation
Start up Tomcat (this usually happens automatically when using the installer, otherwise you will need to run the Catalina shell script with a 'start' command).

Installing Zulu 3

Copy the Zulu.war file from the Installer Data folder into the $TOMCAT_HOME/webapps folder in your Tomcat instance.
(Tomcat 6) Modify the zulu.xml file located in the $TOMCAT_HOME/conf/Catalina/localhost/ folder.
(Tomcat 7) Modify the context.xml file located in the $TOMCAT_HOME/webapps/zulu/META-INF/ folder.
- Specify your username and password on these two lines of the zulu.xml file:
  - <Parameter name="zulu.adminUsername" value="" override="false" />
  - <Parameter name="zulu.adminPassword" value="" override="false" />
If necessary for your configuration, set up URL forwarding from IIS / Apache to your Tomcat connectors. See Tomcat documentation on how to do this.

URL Redirection

Windows

FileMaker Server uses the URL Rewrite module of IIS to redirect traffic from standard web traffic through port 80 to our default HTTP Tomcat port 42424 (or port 16020 if installed in the FMS WPE).

Launch the IIS Manager, expand the Sites folder, then click on the FMWebSite site. You will see a collection of modules in the center pane of IIS Manager.
Double-click the module that reads URL Rewrite.
In the right hand pane, click Add Rule(s) at the very top of the list of actions.
From here, choose Blank rule and press OK
Set up the rule to match the pattern for the requested URL using regular expressions.
Set the pattern as ^zulu(.*)
Scroll down to the action section and be sure the action type is set to Rewrite
Set the Rewrite URL as http://localhost:8080/zulu{R:1}
Be sure Append query string and Stop processing of subsequent rules are both checked, then apply the settings.
Go to the ARR proxy settings (they're hidden under IIS -> Application Request Routing Cache -> Server Proxy Settings) and uncheck the "Reverse rewrite host in response headers" checkbox.
Finally, test the zulu URL in your browser at http://localhost/zulu

Mac

If Zulu is installed in its own instance of Tomcat (Default Installation)

Navigate to FileMaker Server/HTTPServer/conf/ and open the httpd.conf file with a text editor. You will need elevated permissions to modify this file.
Add these lines to the end of the httpd.conf file:
- ProxyPass /zulu http://127.0.0.1:8080/zulu retry=1 timeout=7200
Save the file back to its original location.

Restart Web Server

After setting up a URL rewrite rule, you will need to restart the web server for the change to take effect. Restart with web server with the following command:

fmsadmin restart httpserver -y

Troubleshooting Installation

Can not access the Zulu admin page

The Zulu admin page should be accessible using the url. First, check whether Zulu is running. On the machine where Zulu is installed, go to the below url. This will bypass any firewalls or web servers in the way:

http://localhost:42424/zulu

If you can see the admin page, Zulu is running. This means web server configuration may have been removed, or a firewall is blocking the port. If you have installed or updated FileMaker Server after installing Zulu, the FileMaker Installer will clear out the web server configurations that Zulu sets up. To get these back, just re-run the Zulu installer.

If you can't see the admin page, Zulu is down. Try running the installer again to bring it back up. If that still does not work, contact 360Works support - support@360works.com

Shell execution failed. Verify that Java is installed and run setup again.

This error means that the installer did not find a suitable Java installation. Download and install Java 8 from here: Java 8 Downloads. After that is installed, run the installer again and see if the issue persists.

Could not configure web server forwarding because of an error

This error occurs when the installer could not communicate with the web server. Usually when you see this error message, Zulu has been successfully installed, but was unable to set up a rewrite with the web server. To see if Zulu was successfully installed, open this url in a browser and see if the admin console comes up:

http://localhost:42424/zulu

If you do not see the admin page, another issue has occurred, and you should contact 360Works support at support@360Works.com.

If the admin page loads correctly, then your web server is the problem. This means that Zulu is up and running, but you will need to access it over port 42424. If you require that Zulu be accessed over the standard ports, you will need to get your web server to cooperate. Here are some things you can try:

If FileMaker server is also installed on this machine, you can restart the webserver with this command line command:

fmsadmin restart httpserver -y

If FileMaker Server is not installed on this machine, you will need to configure your own web server.

Calendars and Publishing

How does Zulu correlate FileMaker records to Calendars and Events?

In order to represent Calendars and Events as records in FileMaker, Zulu uses a pre-defined table structure. Zulu uses 2 tables to represent these:

Calendars
- In the Zulu2SampleData file, this is the ZuluCalendarList table. Records in this table represent individual calendars in the service you are integrating with (Apple Calendar, Google...). For example, if you had two records in the ZuluCalendarList table, you would see two calendars in Apple Calendar. To see all components of this table and their functionality, see Zulu Calendar Properties
Events
- In the Zulu2SampleData file, this is the ZuluSampleEvents table. Records added to this table will create new events in the calendar application you have integrated with. To see all components of this table and their functionality, see Zulu Event Properties
- The ZuluSampleEvents layout is customizable, and to see more about integrating your existing events table with Zulu see: Zulu - Integrate Into FileMaker Solution.

Why Do I Publish My Calendars?

Publishing calendars constructs a Field Map that Zulu stores in the ZuluCalendarList::zulu_properties field. This Field Map tells Zulu which fields contain which event property (Event properties like: Start Date, End Date, Summary...). This Field Map is necessary for Zulu to write the correct data to the correct field when syncing events to Google, or inserting them into Apple Calendar.

How To Publish Calendars

When Using the Zulu2SampleData File

In the Zulu2SampleData file, the object mapping is already set up for you, and you can just press the "Publish" button on the ZuluCalendarList layout, or run the script "Publish Calendar". You will be prompted to log in, and for the Zulu2SampleData file, use these credentials:

Username: admin
Password: admin

The default script assumes that Zulu is installed on the same machine as FileMaker server, if this is not the case, see the section Customizing The Publish Script

When Integrating Zulu Into Your Own Solution

If you are integrating Zulu into an existing solution with an events table in place, follow the instructions here to set up the Field Mapping needed for Zulu: Zulu - Integrate Into FileMaker Solution

After the Field Mapping has been set up and the Zulu scripts are imported, run the "Publish Calendar" script. You will be prompted for credentials, these should be the FileMaker credentials for the database. These don't need to be Full Access, but they do need read and write privileges to the ZuluCalendarList and event tables.

Customizing The Publish Script

Zulu needs to send your FileMaker Field Mapping to the Zulu server in order to process your Field Mapping. If you are using a non-default install, you may need to modify this script so that the request is sent to the right server. The "Publish Calendar" script has 4 script parameters you can use to customize where the publishing request is sent:

$zuluApplicationName - the context name of the Zulu
- Customize this parameter if you have used the "Hosting Provider" option during installation, and Zulu is running under a different context name. This will likely only apply to hosting providers, or people running more than one Zulu installation on the same machine.
$webPubEngineHost
- If you're using a Multiple Machine Server Deployment, edit this parameter, making $webPubEngineHost the IP address of your Web Publishing Engine. For Single Machine Deployments, this should point to the main FileMaker Server machine.
$zuluHost
- If Zulu is running on a different machine than FileMaker Server, customize this parameter to point to the IP address where Zulu is installed.
$useSSL
- If you want the publish request to go over SSL, set this parameter to True. This will only affect the publishing request.

Confirm That The Calendars Were Published

After publishing your calendars, you should see the ZuluCalendarList::zulu_properties field populated with a Field Map that describes the `field configuration you want Zulu to use.

Publishing Notes And Troubleshooting

If you ever modify the fields included in the Field Map (change field name or delete fields), you will need to re-publish your calendars in order for Zulu to pick up the change.
If you modify these fields, and you are syncing with Google or Exchange, you will need to republish, and also step through the sync configuration again in order to pick up the field changes.
If the publish request fails, first ensure that the publishing request is hitting your Zulu installation. You may need to customize the publish script: Customizing The Publish Script. If the issue persists, contact 360Works support at support@360works.com.
If you are getting an XML Web Publishing error when publishing, it may be that the XML Web Publishing engine is not enabled or configured correctly. See this page for details on how to set that up: Enable XML FileMaker 17

This page provides instructions on how to integrate Zulu into a pre-existing solution. If you prefer to use the Zulu2SampleData file, you only should be concerned about the Prerequisites section.

Integrate Into Your FileMaker Solution

Prerequisites

Install Zulu - Follow these instructions to install Zulu on your FileMaker Server: Zulu - Installation
Host Your Calendar Database - If you haven't already, upload your calendar database to FileMaker Server and work on it there.
Backup your file - You'll be creating a new table in the steps that follow, and you should always make a backup before making such changes.
Enable XML Web Publishing - Zulu uses the XML Web Publishing engine, and you may need to check that it is enabled, and your accounts have the privileges to use it. See here for instructions: Enable XML FileMaker 17
Avoid periods (.) and hyphens (-) in your database & layout names.

Components to Import

You will need to import the following scripts, tables, and layout components into your FileMaker solution.

Scripts

In the ZuluSampleData.fmp12 file, under the Scripts Workspace you'll need to copy the following scripts to your own solution on FileMaker Server:

Publish Calendar
Validate Events
Zulu_PostEdit
Zulu_PreDelete

ZuluCalendarList Table

In short, import the ZuluCalendarList table into your solution, and create a plain layout for it that is also named "ZuluCalendarList".

While the events table is customizable, the calendar table is not. Zulu requires you to have a table and layout named ZuluCalendarList in your database. This table must also contain the same fields as the ZuluCalendarList table in the ZuluSampleEvents file. Set this up in your solution with one of the following options:

Copy the “ZuluCalendarList” table to your solution. This will create a layout with the same name and all the table's fields on it. You may hide the ZuluCalendarList layout, but do not rename it, or add/remove fields from this layout.
If you don't have FileMaker Advanced (which lets you copy and paste tables from file to file) you'll need to recreate the “ ZuluCalendarList” table in your solution by hand, and then add all the fields from it to the default layout the FileMaker creates for you when you create a new table. There are only 14 simple fields here so this won't take long, but make sure you get the auto enter field options exactly the same as they are in the sample file.
You can also import the table if you don't have Advanced, but take your file off the server first. From your file select File / Import Records... / File and then select the Zulu sample file. Select the ZuluCalendarList table to import and for the target, select "New Table". FileMaker will create the new table and calculations for you.

Events Table And Field Mapping

Overview

When integrating into your own file, understand that Zulu derives the event Field Mapping through FileMaker Layout Object Names. The Field Mapping tells Zulu which fields map to which event properties. If you check the ZuluSampleEvents layout in the Zulu2SampleData file, you will see all the fields have object names that correspond to a particular Field Mapping. You need to recreate this setup in your own file, setting the proper object names to the right fields. If you don't already have an events table in your file, copy our "ZuluSampleEvents" table to your solution.

Setup Event Field

The tab panels on the ZuluSampleEvents layout contain all the fields you will need for Zulu. Also, the object names are already set up for these objects. So the quickest way to accomplish this setup is to:

Create a new layout based on your events table. There should be no script triggers, and no other named objects on this layout. This layout can be named anything you want, but avoid special characters (spaces, hyphens, apostrophes) if possible.
Copy the tab panels from the “ZuluSampleEvents” layout, and paste it into your solution onto the new layout. Don't be alarmed if you see <Field Missing> on the pasted tab panels, this is normal and will be fixed in the next step.
Assign each pasted field to an actual field in your database. Do this by double-clicking the fields in layout mode and selecting a field that best fits their purpose.
You can see more about what these fields are for here: Zulu Event Properties

Notes

You may need to create a couple new fields in your events table if you don't have creation and modification timestamps, and you'll almost certainly need to create the zulu_UUID and zulu_ICAL_DATA fields.
Use unique fields for each calendar property. For example don't use the same field for Date Start as Date End.
Make sure the fields you create are of the same type (number, text, or timestamp) as they are in our sample file, and that your creation and modification timestamps auto enter.
You can copy any missing fields from the ZuluSampleEvents table in the Zulu2SampleData file included with the download.
The zulu_UUID is not the unique ID in your table (even if you have a UUID), this is iCal's UUID for the event, so be sure to create a field for this. Your unique ID gets mapped to "Event ID". Zulu handles this field and populates it as needed, so don't worry if it doesn't have a value right away.
The zulu_UUID also has an auto-enter definition you'll want to preserve (we auto-enter a blank value). Make sure you set this up exactly as it is in our sample file and that the option "Do not replace existing value of field..." is unchecked.

Publish your calendar

Navigate to the field mapping layout in your file and run the "Publish Calendar" script which you pasted into your solution.
Enter your FileMaker account and password when prompted. This doesn't have to be the full access account and password, but it does need to have write access to the ZuluCalendarList table. The account and password entered aren't stored anywhere. Note: this account must have a password. Apple Calendar will refuse to authenticate an account with only a username and no password.
The "Published..." page will contain your new calendar's URL and instructions for viewing your calendar in iCal, follow these instructions to see the calendar(s) on your iPhone: configuring your iPhone.
If you have issues running your Publish Calendar script, you may need to modify it for your own server, see this section for more details: Customizing The Publish Script

Going Further

See how to set up your calendar database with the following services:

Integrating with Apple Calendars
Syncing with Google Calendars
Syncing with Exchange Outlook Calendars

To see more about filtering the events for each calendar, refer to: Zulu - Filtering

To see more about the components of the ZuluCalendarList table, see Zulu Calendar Properties

The Admin Console

The Zulu Admin Console lets you set up Registration information, as well as set up sync configurations to Google and Exchange.

Accessing The Zulu Admin Console

The admin console can be accessed using the following url scheme:

http://<your server address>/zulu

If you are on the same machine as where Zulu is installed, you can use "127.0.0.1" for your server address:

http://127.0.0.1/zulu

If you are having problems accessing the admin console, try appending the port "42424". Zulu runs natively on port 42424, and a web server is responsible for rewriting requests from the standard ports to port 42424:

http://127.0.0.1:42424/zulu

Registration

To register your Zulu installation, access the Admin Console, and click the Registration link. You will be able to enter the License Key and Registered To name that you received when you purchased a Zulu license.

You can view and purchase the licensing options for Zulu on our store: Zulu Store Page

Sync Admin

Google and Exchange configurations will be managed in the Sync Admin section of the Zulu Admin Page. When you click the "Sync Admin" link, you will be prompted to log in using the credentials you supplied during installation.

Configuration List

For each configuration, you have the following options available:

Edit

Click this button to edit an existing sync configuration. You may need to do this if the database has changed, or some other sync component needs updating. Additionally, if you have changed certain settings in the zulu.xml file, you will need to edit your configurations to apply the change. See more about the zulu.xml field here: Zulu - Advanced Settings

Remove

Click this button to completely remove a configuration. Removed configuration will no longer be able to be synced.

Reset Sync Data

Click this button to reset the sync data for a configuration. This wipes out Zulu's internal sync database for this configuration, and any sync history will be lost. It will be as if the configuration is brand new after resetting the sync data. This is useful when troubleshooting sync data issues. Only use this if you know what you are doing, or you were recommended to do this by 360Works support.

Sync Now

Click this to immediately run a manual sync. Running a manual sync will display the modified record count, and any errors that occurred during the sync at the top of the page. When initially setting up a sync configuration, it's good to run a few manual syncs first to see what issues may occur.

Auto Sync

Auto Sync will run automatically run syncs at the set interval. Checking the box will display a field you can input a number of seconds into.

The interval specified will determine how long Zulu should wait after the last sync finishes before starting a new sync. For example, if you had an Auto Sync value of 60, Zulu would wait 60 seconds after a sync finishes before triggering the next one.

Add New Sync Configuration

This is the starting point for setting up a Google or Exchange Sync Configuration. Clicking this button will open the workflow for creating new Sync Configurations. To see more about setting up sync configurations, see the following:

To see more about setting up Google Sync Configurations: Zulu - Syncing with Google Calendars
To see more about setting up Exchange Sync Configurations: Zulu - Syncing with Exchange Outlook Calendars
Apple Calendar Integrations are not configured here, and must be added in Apple Calendar. See more here: Zulu - Integrating with Apple Calendars

Email Log File

Use this link to send a log file to 360Works support. This will also open a ticket in our support system. Please include a description of the problem, and some steps we could take to reproduce. We should be able to respond within a day or two.

Filtering Calendars

Overview

Filtering lets you limit the records that are synced to a calendar based on search criteria, or a day range. This will allow you to have multiple calendars that do not share events. A good example of this is having a calendar for each employee, and each employee's calendars only show the events that belong to them.

Each calendar in your calendar application is represented by a record in the ZuluCalendarList table. To see more about how the calendar records work, see: Zulu - Calendars And Publishing

Filtering By Value

Consider the following calendar record:

To get the events that belong to this calendar, Zulu will do the following:

Go to the "ZuluSampleEvents" layout
Search the "Status" field for the value "Urgent"

The resultant found set are the events that Zulu will sync for this calendar.

Notes

Events that are created in a calendar application will be inserted into FileMaker with the appropriate filterKey and filterValue values. For example, if this calendar were configured with Apple Calendar, and a user inserted an event into this Apple Calendar, it would be inserted into FileMaker with "Urgent" in the "Status" field.
When specifying a field in the zulu_filterKey field, you do not need to include the table name, just the name of the field on the 'events' layout.
If the events are not showing on your calendar, double check that the field targeted by zulu_filterKey has same value as zulu_filterValue. A lot of times when events don't show up on a calendar, it's because the filter field does not have a value in it, or has the wrong value.
If you are using a list of filter values in your filter field, to share events between multiple different calendar records, if the event is edited on one calendar, the event will have the other calendars' filter values removed from the filter field, and will then be viewable only on the calendar that edited it. This behavior is caused by the fact that when Zulu inserts or updates an event in FileMaker, Zulu writes the filterValue for the calendar record to the filterKey field specified. This behavior can be modified using the Zulu_PostEdit script. See here for more details on the Zulu_PostEdit script and event hooks: Zulu - Event Hooks

Filtering Todos

Filtering Todos works the exact same way as filtering events. Consider the following calendar record:

To get the todos that belong to this calendar, Zulu will do the following:

Go to the "ZuluSampleTodos" layout
Search the "TodoStatus" field for the value "Urgent"

Since this calendar supports both events and todos, it will also filter the events. To get the events that belong to this calendar, Zulu will do the following:

Go to the "ZuluSampleEvents" layout
Search the "EventStatus" field for the value "Urgent"

Filtering By Day Range

Consider the following calendar record:

To get the events that belong to this calendar, Zulu will do the following:

Go to the "ZuluSampleEvents" layout
Search for records that have a Start Date between 30 days in the past, and 60 days in the future. This is a dynamic search criteria, and will advance the search values as the current date advances.
- For example, if the current date was 1/30/2019, Zulu would search the Start Date field for "1/1/2019...3/31/2019". On the next day, 1/31/2019, Zulu would change the search criteria to "1/2/2019...4/1/2019". Records that started on 1/1/2019 would be deleted from your calendar application, and records that started on 4/1/2019 would be added.

The resultant found set are the events that Zulu will sync for this calendar.

Notes

Day Range Filtering is a one way operation from FileMaker to your calendar application. If you have year old events in your calendar application, then you apply this filter, the events will be removed from the calendar application. However, these events will persist in FileMaker. Zulu never deletes records from FileMaker, but it will delete records from your calendar application.
If you are filtering todos by date range, they will be filtered by the creation timestamp of the record.

Filtering By Record Level Access Privileges

When you set up a sync configuration or add an account to Apple Calendar, you provide a FileMaker account in the process. Zulu will always use this FileMaker account when querying FileMaker for calendar and event records. The benefit of this is that Zulu will obey the FileMaker Record Level Access Privileges. So you can filter the event records based on FileMaker privileges, and records the account does not have access to will not be pushed to the calendar application.

Filtering Calendars By FileMaker Account

The easiest way to accomplish this, is to use Record Level Access Privileges on the ZuluCalendarList table, so that a user can only see the calendar that belongs to them. This takes advantage of the order that events are fetched:

First, Zulu queries FileMaker for which calendars it should sync.
Then, it queries for the events that belong to each of the calendars returned.

If a calendar is not returned by the first calendar query, the calendar will not be synced, and its events will not be fetched. You may have business logic that requires a more complex setup, but this example is the bare minimum that you need.

Walkthrough

Here are the basic configuration details of this privilege set:

The privilege set will need custom privileges for records. Also, be sure that "Access via XML Web Publishing" is also checked while you are here

Select Access via XML Web Publishing
Limited record "View" privileges are needed for the ZuluCalendarList table:
Set the privilege calculation to:

zulu_filterValue = Get(AccountName)

**Custom privilege calculation dialog box**

Event Hooks

The following event hooks are called after Zulu modifies records in FileMaker. These scripts are already in the Zulu2SampleData file, and should be imported if you are integrating Zulu into your own solution, as shown here: Zulu - Integrate Into Your FileMaker Solution. These scripts are executed by name, so you don't necessarily need to copy these scripts, and you could create your own, what is important is that the names match. You should have a script named "Zulu_PostEdit", and a script named "Zulu_PreDelete" in your FileMaker solution.

Zulu_PostEdit

This script is invoked after an event record is inserted or updated. The found set will be the event being inserted/updated. The script need not contain any steps, but you can use this to do things like enforcing new record creation rules.

This script would be useful for updating other portions of your database after a calendar user updates or creates an event in their calendar application.

For example, you could have this script send you a notification email so that you would be notified if an event was inserted or updated into a particular calendar.

Zulu_PreDelete

This script is invoked before an event record is "deleted". The found set will be the event being deleted. Zulu does not actually delete events but puts a 1 in the Deleted field. This script need not have any steps, but you can use this to enforce deletion rules.

One way to prevent an event from being removed from a calendar is to use the Omit Record script step to remove this record from the found set before it is deleted.

Zulu_PostEdit_Todo

This script is invoked after a todo record is inserted or updated. The found set will be the todo being inserted/updated. The script need not contain any steps, but you can use this to do things like enforcing new record creation rules.

This script would be useful for updating other portions of your database after a calendar user updates or creates an event in their calendar application.

For example, you could have this script send you a notification email so that you would be notified if a todo was inserted or updated into a particular calendar.

Zulu_PreDelete_Todo

This script is invoked before a todo record is "deleted". The found set will be the todo being deleted. Zulu does not actually delete todos, instead, it puts a 1 in the Deleted field. This script need not have any steps, but you can use this to enforce deletion rules.

One way to prevent a todo from being removed from a calendar is to use the Omit Record script step to remove this record from the found set before it is deleted.

Integrating with Apple Calendars

Zulu can integrate with Apple Calendars, allowing you to view your FileMaker calendars on Apple computers or iPhone.

Prerequisites

Zulu must be installed: Zulu - Installation
Your calendars must be published: How To Publish Calendars
Recent versions of Apple Calendar require an SSL certificate installed on the Zulu server. You may need to install a valid certificate on your server in order for Apple Calendars to work with Zulu: Troubleshooting Adding Calendars

Setting Up AutoDiscovery

New in Zulu 4, AutoDiscovery lets your users set up your Zulu calendars on their Apple device with far fewer settings required. To set up AutoDiscovery, you need to modify the zulu.autodiscover.database parameter in your zulu.xml file. This parameter should hold the name of the database where your calendar records live. After you have changed this xml parameter, you will need to restart Zulu for this change to be picked up: Restart Zulu using the 360Works Admin.jar - Restart Tomcat

Once AutoDiscovery is set up, you can add your calendars using the "Automatic" account type in OSX, and you only need to supply a hostname on iOS devices.

Note:

AutoDiscovery will not work with databases that have spaces (" ") in the database name. If your database has a space in the name, you may want to rename your database, or create a wrapper database for use with Zulu.

Adding Calendars to Apple Calendar

For OSX (Apple Computers)

Adding a CalDAV Account With AutoDiscovery

Open System Preferences -> Internet Accounts
In the list of account types the right, scroll down until you see "Add Other Account...". Click this.
Now look for the account type "CalDAV Account" and click this.
The format for the credentials is:
- Username: <FileMaker Username>@<Zulu Server>
- Password: <FileMaker Password>
The Zulu Server is the domain where you have installed Zulu.

Adding a CalDAV Account Without AutoDiscovery

Open System Preferences -> Internet Accounts
In the list of account types the right, scroll down until you see "Add Other Account...". Click this.
Now look for the account type "CalDAV Account" and click this.
In the new menu, click the "Account Type:" dropdown menu and set it to "Advanced". This will show some additional fields we can use.
Now we need to populate each field with the correct values:
- User Name: The FileMaker account username that Zulu should use when fetching events
- Password: The FileMaker account password that Zulu should use when fetching events
- Server Address: The ip address or domain name where Zulu is running
- Server Path: This is the path to your calendar database, and should be of the format:

/zulu/calendars/<your database name>

Port: The port to access Zulu over. For http, use port 80. For SSL, use port 443.
Use SSL: Checking this box will make Apple Calendar use SSL for communication with Zulu. This will only work if the server running Zulu has an SSL certificate installed.
Use Kerberos v5 for authentication: Leave this unchecked.
Press the "Sign In" button

If the account is able to authenticate and connect to Zulu, you will see the screen close. Open Apple Calendars and confirm that your calendars were added. They may take a minute to load, as everything is being downloaded from the server.

If you see an error message, adding the calendars did not work, and you should refer to the troubleshooting section below.

For iOS (iPhone)

Adding a CalDAV account with AutoDiscovery

Open "Settings"
Find and Open: "Passwords & Accounts"
Press: "Add Account"
In the Account Type list, select: "Other"
Select: "Add CalDAV Account"
Now we need to populate the required fields:
- Server: This is the address or hostname of the server where Zulu is running
- User Name: The FileMaker account username that Zulu should use when fetching events
- Password: The FileMaker account password that Zulu should use when fetching events
- Description: Optional, used to describe the calendar account.
Click the "Next" button in the top right to validate the settings.
If Apple Calendar cannot connect over SSL, you will see a prompt saying "Cannot Connect Using SSL". Press "Continue" to try connecting without SSL.
If Apple Calendar still cannot connect, you will see an additional menu item show up called "Advanced Settings" This will allow you to customize the SSL option, the port number, and the Account URL.

Adding a CalDAV account without AutoDiscovery

Open "Settings"
Find and Open: "Passwords & Accounts"
Press: "Add Account"
In the Account Type list, select: "Other"
Select: "Add CalDAV Account"
Now we need to populate the required fields:
- Server: This is the calendar URL to access Zulu over. See Constructing Calendar URL
- User Name: The FileMaker account username that Zulu should use when fetching events
- Password: The FileMaker account password that Zulu should use when fetching events
- Description: Optional, used to describe the calendar account.
Click the "Next" button in the top right to validate the settings.
If Apple Calendar cannot connect over SSL, you will see a prompt saying "Cannot Connect Using SSL". Press "Continue" to try connecting without SSL.
If Apple Calendar still cannot connect, you will see an additional menu item show up called "Advanced Settings" This will allow you to customize the SSL option, the port number, and the Account URL.

Constructing Calendar URL

Whenever you publish your calendars, the resultant page has a section called "Add your calendar to iCal, iPhone, or iPad", which displays the calendar URL that Apple Calendar needs. This section is about how to construct that URL on your own, so you understand the components of it.

The format of the calendar URL is:

http<s>://<your Zulu address>:<port>/zulu/calendars/<your database name>

You may notice that calendar URL reaches out to Zulu. Zulu intercepts requests from Apple Calendar, converts it into FileMaker requests, reads the result from FileMaker, then converts it to the Apple Calendar format. This is important because your Apple Calendar devices must be able to communicate with Zulu in order to work properly.

To give an example, say I had Zulu running on a machine with the address: "example.com", the database I have my calendars in is: "Zulu2SampleData", and I have a valid SSL certificate installed on that machine, which allows me to use https instead of http. The url for my calendars would be:

https://example.com/zulu/calendars/Zulu2SampleData

Another example, with the same server and database as above, but in this case, I had Zulu running on port 8080, and I was not using an SSL certificate of any kind. The calendar url would be:

http://example.com:8080/zulu/calendars/Zulu2SampleData

Note:

Apple Calendar has gotten very picky in later versions about servers without SSL certificates. Frequently Apple Calendars will refuse to send credentials to Zulu, and the request will fail. To resolve this, try installing a valid SSL certificate on your Zulu server. If this is not an option for you, you can use the default FileMaker certificate, but you will need to add this certificate to the trust store on each device communicating with Zulu. See more on that below.

Troubleshooting Adding Calendars

Unable to verify account name or password (SSL Certificate Requirement for Apple Calendars)

Apple Calendars has gotten very picky about servers that do not have valid SSL certificates. Sometimes Apple Calendar will refuse to connect to a server without one. The best way to get around this is to install a valid SSL certificate on the machine where Zulu is running. Another option is to add the default FileMaker server certificate to a devices trust store, this assumes that Zulu and FileMaker server are running on the same machine.

Option 1: Install a Valid SSL Certificate

An SSL certificate can be purchased from companies like GoDaddy, RapidSSL or Let's Encrypt, and then installed onto the machine where FileMaker server is running. Acquiring an SSL is out of the scope of this guide, but you should be able to reach out to a certificate provider for more instructions. If you are running Zulu on a machine other than FileMaker Server, refer to your web server's documentation for how to import a certificate. 360Works offers SSL certificate installation services as well. Reach out to us at (770) 234-9293 for more information.

Option 2: Add The Default FileMaker Certificate To Your Trust Store

This option is not meant for many users, as you would need to follow these instructions on each device. This is mainly meant for testing and development.

For iPhones: iPhones will prompt you add the SSL cert to your phones trust store during the CalDAV account setup, so you shouldn't need to go through these steps on iPhone.

For OSX machines, you can add a certificate to your trust store using Safari.

Open Safari, and input the url for Zulu, specifying https:

https://<your Zulu address>/zulu

You should see a page saying this connection should not be trusted:
Click "Show Details"
Then click the "View Website Anyway"
You will be prompted again if you want to visit the website, click "Visit Website"
You will be asked to authenticate with the dialog: "You are making changes to your Certificate Trust Settings". Type your credentials and click "Update Settings" to apply.
Now the server's certificate has been added to your default trust store, and your computer will trust the certificate as if it was valid.
Return to the section above, and try to add your Zulu calendar account again: For OSX (Apple Computers)

Option 3: Allow Unauthenticated Requests (Calendars can be viewed without credentials)

This option gets around the SSL certificate requirement of Apple Calendars, but your calendars could be viewed by anyone that has your Calendar URL.

Locate the zulu.xml file using the instructions here: Locate the zulu.xml file

Modify the following 3 parameters:

zulu.allowUnauthenticatedRequests - Set this to "true", so that Zulu will know that you want to allow unauthenticated requests to the database.
jdbc.username - Set this to the FileMaker Account Name that you want your calendar users to be automatically logged in as.
jdbc.password - Set this to the FileMaker Account Password, this should correspond to the FileMaker Account Name above.

Restart Zulu using the 360Works Admin.jar - Restart Tomcat

Note: After setting up Unauthenticated Requests, Apple Calendar still requires a username and password, but these can be gibberish, as they are not used.

Contact Support

If you are still having issues connecting to Zulu with Apple Calendar, feel free to open a ticket in our support system: Zulu - Email Log Files

Working With Todos/Apple Reminders

This page describes how to work with todos in Zulu, and shows examples of how they will appear in Apple Reminders

Prerequisites

Zulu must be installed: Zulu - Installation
Your calendars must be published: How To Publish Calendars
A Todo Layout must be specified in at least one of your calendar records.
Recent versions of Apple Calendar and Apple Reminders require an SSL certificate installed on the Zulu server. You may need to install a valid certificate on your server in order for Apple Calendars to work with Zulu: #Troubleshooting Adding Calendars
Enable reminders for your calendar
- Go to System Settings -> Internet Accounts
- Click on a CalDav account you have already added to your Calendar, or add a new CalDav account
- Enable the toggle for Reminders

Todo Components

The Simplest Todo

The only thing a todo needs to be created, is the summary field filled out:

A todo record on the Field Mapping (todos) layout — **A todo record**

Once this todo is marked complete, you will see the zulu_STATUS and zulu_COMPLETED fields populated automatically:

Using The Note and zulu_DUE Fields

The Note field allows for a bit more description about this todo, and this description will show in the Apple Reminder interface. The zulu_DUE allows you to specify a date when the todo is expected to be complete.

Using The Priority Field

The zulu_PRIORITY allows you to specify the urgency of this todo. Apple reminders uses numbers to correspond to the level of urgency:

1 - High
5 - Medium
9 - Low
(empty field) - No Priority

Using The Activity Field

The zulu_ACTIVITY is used to give the todo an actionable icon that can be clicked to perform some activity. This is best described through examples.

You can initiate a phone call from a todo by storing the value: "tel:7702349293" in the zulu_ACTIVITY field:

**Storing a phone number in the activity field**

You can open a web page by storing the value https://www.google.com/.

You can use an FM Pro URL (fmp://...) to open a FileMaker database:

**Storing an FMP URL in the activity field**

Alarm Components

Timestamp Alarms

Timestamp alarms allow you to trigger a notification to the user at a specific date and time. You can supply a timestamp in the zulu_ALARM_TRIGGER_TIMESTAMP.

Only the timestamp needs to be supplied. When the alarm is created in Apple Reminders, Zulu automatically populates the alarms uuid back to FileMaker in the zulu_ALARM_TIMESTAMP_UUID.

Proximity Alarms

Proximity alarms allow you to trigger a notification to the user they arrive or depart a location.

Bare Minimum Proximity Alarm

At the minimum, the zulu_ALARM_PROXIMITY, zulu_ALARM_LATITUDE, and zulu_ALARM_LONGITUDE need to be filled out. This will create a valid proximity alarm, but you will likely want to add some more details. As you can see from the screenshot, some of the fields show "null" and would look a little confusing to users.

Adding More Detail To Proximity Alarm

Using the zulu_ALARM_LOCATION_TITLE, we can supply a title for this location. This could be an address or some user-friendly data that we want to show on the alarm.

This is a little better, but there is still that annoying "null" value, showing on both the Todo List, and the info panel. We can add something here using the zulu_ALARM_COMPLEX_TITLE.

This field takes a URL Encoded string, and will display the result. Simple values like "Work" or "My%20Home" will display. But we can take advantage of the fact that url encoding is used to get a number of symbols to show up here, including emojis.

For example, take this string of text:

🏢Work

When URL-encoded, this becomes:

%F0%9F%8F%A2Work

If we supply this in our zulu_ALARM_COMPLEX_TITLE field, we can see the emoji and the work "Work" in our todo.

Syncing with Google Calendars

Zulu can sync with a Google Calendar account, allowing users to view FileMaker events through the Google Calendar interface.

Prerequisites

Zulu must be installed: Zulu - Installation
Your calendars must be published: How To Publish Calendars
You will need a Google Account, as you will need to log into this as part of the configuration.
We recommend that you set up your own Google API Key, so you are not sharing an API quota limit with other users: Google Generate API Key

Set up a Google Sync Configuration

Go to the Zulu Admin Console, and navigate to the Sync Admin Page. See here for more info: Zulu - The Admin Console
Click the "Add New Sync Configuration" button
Name your configuration. This name has no particular significance except to help you keep track of which configurations do what. For example, you might name your configuration "Office Google Sync".

Naming your Config
On the next screen, supply a FileMaker username and password that Zulu will use to fetch events for this sync.
Type the name of the database that has your calendar events in it, if you type the first few letters, Zulu should auto-populate this list if it is able to communicate with FileMaker Server.

Choosing the Source Database
On the next screen, select the FileMaker calendars that you want to include in this sync:
Next, select the Google option and click the "Authenticate Google Account" button. This will open up a Google prompt to authenticate Zulu's access to your calendars.
Select the Google Account that you want Zulu to sync with, and login to Google for that account
Click the "Allow" button to give Zulu access to your Google Calendars
You should be redirected back to the admin console page, and the account showing as Authenticated. Click the "Next" button.
Use the dropdown menu to select the calendar that you want Zulu to sync with. This screen allows you to pair FileMaker calendars with Google ones. Optionally, you can select "Create one for me" to have Zulu create a calendar in your account.
You can change the directionality individually for each of your calendars included in your sync configuration by clicking on the directionality graphic between the FileMaker calendar name and the Google calendar name. Zulu 2 offers three different sync directions:
- Bidirectional (insert/update/delete on both sides of the sync)
- Read From Hub (insert/update/delete only in the Google Calendar)
- Read From Spoke (insert/update/delete only in the FileMaker Calendar)
Minimum Start Date: This field takes a date. The date should be in the format: 1/13/2019
- Events in Google will be completely ignored by Zulu if their Start Date falls before the Minimum Start Date specified here

Note:

Google calendar can only create 25 calendars per day, according to their documentation. Keep this in mind if you have over 25 calendars, as you may want to create them manually.

Hit the "Finish" button. This will save the configuration and return you to the Sync Admin menu.

Success!
Test your configuration out by hitting the "Sync Now" button. This will immediately run a sync, and return warnings or errors if there are any additional problems with the sync.

Additional Tips for Google Syncs

Set up your own Google API key. This will let you have your own Google API Quota, and not have to share a quote with other users.

Generate Your Own Google API key (Optional)

Overview

Originally, users were advised to create their own Google API key for use with Zulu due to concerns about reaching the daily limit of API calls with the default 360Works key. However, the recommendation has since evolved. The quota for the 360Works Google API key has been significantly increased, ensuring that it is highly unlikely for users to encounter any issues due to limit constraints. Therefore, it is now recommended to use the 360Works API key. This change simplifies the process, as there is no longer a need to generate a separate API key. However, should there be specific needs or unique requirements, users still have the option to generate their own Google API key.

Generate your own keys

Step 1 Go to https://console.cloud.google.com/ . If you do not already have a Google account, you will need to create one. It is recommended that if you are setting this up that you go ahead and create a new account with a username and password that you are comfortable sharing with your users/co-workers

Step 2 Click Create Project. On the next screen name the project. You do not need to select an organization. Click Create.

Google APIs web page, with 'Select a project' and 'create project' buttons circled — **Click 'Create Project'**

Google APIs dialog asking for a project name — **Name Your Project**

Step 3 Back on the Dashboard, click on Enable APIs And Services. On the next page, scroll down the page till you see Google Calendar API, click it, and on the next page click Enable

Google APIs web page, with 'Enable APIs and Services' circled — **Click 'Enable APIs and Services'**

Google APIs web page, with 'Google Calendar API' visible — **Click 'Google Calendar API'**

Step 4 On the Overview page, look for the Google Calendar API, click on Create Credentials

Google APIs web page, with 'Create Credentials' circled — **Click 'Create Credentials'**

Step 5 You should be prompted to set up the OAuth Consent screen, select that option and this should open in a new window/tab.

Google APIs web page, with 'Set up OAuth consent screen' visible — **Name your client ID and Set Up Consent Screen**

Step 6 On the OAuth consent screen, you will have a choice of User Type: Internal or External. We suggest External. Internal users are available to GSuite users, and this setting is limited to users within an organization. External users are available to any test user with a Google Account. If you do not have a GSuite account, you must select External, and this documentation will follow the External User set up.

Google APIs web page, with 'User Type' selection visible — **Choose User Type**

On the OAuth consent screen, Enter Zulu as the Application name. You do not need to include an Application logo, the support email should be set as the email you logged into Google with.

Google APIs 'edit registration' web page — **Enter Zulu as your App name**

For Authorized Domains, enter "360works.com". For Application homepage enter "https://360works.com/filemaker-calendar/". Leave the Privacy policy and Terms of Service fields blank.

Google APIs web page, with 'App Domain' input visible

For Developer contact information, this should be an email address for you to receive alerts and updates about your own copy of Zulu. This is not 360Works development or support email addresses.

Google APIs web page, with 'Authorized Domain' input visible

Next you will be taken to Scopes. Click "Add or Remove Scopes".

Google APIs web page, with 'Add or Remove Scopes' visible — **Click Add or Remove Scopes**

You will need to select the following Scopes and save them to your project: auth/calendar & auth/calendar/events. Once you have selected and saved the Scopes, you should see a summary of added Scopes similar to the screen below. Save and continue.

Google APIs web page, with a scope creation form visible — **Add the Two Necessary Scopes**

You will be taken to a Users section. You will need to add user email addresses for your Zulu calendars. You will be given the chance to add 100 users while in "Test Mode". You do not need to add them all immediately, you are able to edit this list. You can fully use Zulu in test mode, however if you would like to add additional users beyond the initial 100, you will need to authenticate your app and usage with Google.

Interface to add users — **Add Users' Email Addresses**

Step 7 Once you have saved the OAuth consent screen information, you will be taken back to a summary page. On the left side of the page, please navigate to "Credentials" to complete setting up your keys.

Google APIs page with 'Credentials' focused — **Click 'Credentials'**

Under the "Create Credentials" heading, select "OAuth Client ID".

Google APIs page with 'Create Credentials' circled — **Click 'OAuth client ID'**

The Application type should be set to "Web Application". The Name can be anything as it is only used to identify the Client ID in the Google console. You do not need to add Authorized JavaScript Origins. You do need to enter https://zuluauth.360works.com/zuluauth/auth for Authorized Redirect URIs.

Step 8 You will be given a screen with a Client ID and a Client Secret. These are your keys that will ensure your access to the Google Calendar API for your own Zulu account. These will continue to be available in your Google Developer Console, however it is a good idea to save a copy somewhere safe. Do not share this key between other applications. Keep it secret, keep it safe.

Step 9 Open the Zulu.xml file on your machine in a text editor. The Zulu.xml file is found at /Library/360Works/Applications/conf/Catalina/localhost/zulu.xml on Mac and C:\Program Files\360Works\Applications\conf\Catalina\localhost/zulu.xml on Windows . Look for the section that says "Customize these parameters to use your own Google Calendar API key"

Step 10 Copy the value for "client_ID" and paste it in for the value for the "google.client.id" parameter in the zulu.xml file. Copy the value for the "client_secret" and then paste it in for the value of the "google.client.secret" parameter in the zulu.xml file. and then save the zulu.xml file

Step 11 Restart Zulu using the 360Works Admin utility found in /Applications on Mac and C:\Program Files\360Works on Windows. Launch the file, select Zulu and click Stop and then Start.

Note:

If you have a pre-existing Google sync with Zulu, you will need to edit your configurations to apply these new Google API Keys. Step through the configuration, and on the step where you authenticate to Google, do this:

Select "Sync with Exchange"
Select "Sync with Google" again

This will allow you to re-authenticate your Google account, and store this new authentication as part of the sync configuration.

Syncing with Exchange Outlook Calendars

Zulu can sync with an Exchange Outlook Calendar account, allowing users to view FileMaker events through the Exchange Outlook Calendar interface.

Note:

Due to a limitation in the Microsoft Exchange Web Service API, the OAuth implementation does not support personal outlook.com accounts or on-premise Exchange servers.

Prerequisites

Zulu must be installed: Zulu - Installation
Your calendars must be published: How To Publish Calendars
You will need an Exchange Account, as you will need to log into this as part of the configuration.

Set up an Exchange Sync Configuration

Go to the Zulu Admin Console, and navigate to the Sync Admin Page. See here for more info: Zulu - The Admin Console
Click the "Add New Sync Configuration" button
Name your configuration. This name has no particular significance except to help you keep track of which configurations do what. For example, you might name your configuration "My Exchange Sync".

On the next screen, supply a FileMaker username and password that Zulu will use to fetch events for this sync.
Type the name of the database that has your calendar events in it, if you type the first few letters, Zulu should auto-populate this list if it is able to communicate with FileMaker Server.

Choose Source Database
On the next screen, select the FileMaker calendars that you want to include in this sync:
Next, select the Exchange option.
You will be re-directed to a Microsoft Outlook Login page, fill out the fields for your Exchange email address and password. Once your email address and password have been entered, wait for the account to be authenticated.
Once the account is authenticated, click the "Next" button.

Use the dropdown menu to select the calendar that you want Zulu to sync with. This screen allows you to pair FileMaker calendars with Outlook/Google ones. Optionally, you can select "Create one for me" to have Zulu create a calendar in your account.
You can change the directionality individually for each of your calendars included in your sync configuration by clicking on the directionality graphic between the FileMaker calendar name and the Exchange calendar name. Zulu offers three different sync directions:
- Bidirectional (insert/update/delete on both sides of the sync)
- Read From Hub (insert/update/delete only in the Google Calendar)
- Read From Spoke (insert/update/delete only in the FileMaker Calendar)
Minimum Start Date: This field takes a date. The date should be in the format: 1/13/2019
- Events in Exchange will be completely ignored by Zulu if their Start Date falls before the Minimum Start Date specified here

Hit the "Finish" button. This will save the configuration and return you to the Sync Admin menu.

Sync admin page showing that the configuration wizard is completed

Test your configuration out by hitting the "Sync Now" button. This will immediately run a sync, and return warnings or errors if there are any additional problems with the sync.

Recurrence

Recurring events are partially supported with Apple Calendar integrations, and fully supported with Google and Exchange configurations. Recurring events are difficult to manage without a calendar interface, and Zulu uses the RRULE and EXDATE properties from the CalDAV specification to accomplish this. You can see more examples of RRULE here: 3.8.5.3. Recurrence Rule

Again, Recurring events are very tricky to deal with, and should probably be managed in the calendar application you are integrating with. This page is meant as a guide for those who want to better understand how recurring events work and want to manage them from FileMaker.

Recurring Event Components

RRULE

The RRULE defines how the recurring event should iterate, and is best documented in the original spec, shown here: Recurrence Rule
You can see more examples of RRULE here: 3.8.5.3. Recurrence Rule
In FileMaker, the RRULE is stored in the parent event in the recurrence field.

EXDATE

EXDATEs are children of a recurring series that have been deleted.
These manifest as EXDATEs in the ICAL_DATA field for Apple Calendar, and the "exdates" property for Google and Exchange
EXDATEs are a date-time property for standard events with times, and a date only property for all-day events.
You can read more about EXDATE documentation here: Exception Dates
EXDATEs are stored in the parent record in the recurrence field.

Overrides

Overrides are children of a recurring series that have been modified. They are still part of the series, but they do not obey the RRULE as some property has been modified.
These are the most complicated thing to deal with in recurring events.
In FileMaker, these will be represented as a new record for the event, but they will have a recurrence-id that links them back to the parent in some way.
In most cases, it will be easier to write an EXDATE to the parent event to delete the event you want to override, then create a new event that represents the override.

Recurrence in Apple Calendar

Zulu has partial support for recurring events in Apple Calendar. These are the abilities and limitations:

If you create a recurring event in Apple Calendar, you will see the RRULE show up in the iCAL_DATA field in FileMaker.
You can delete occurrences from Apple Calendar, and you will see EXDATEs show up in the ICAL data
However, if you try to modify an occurrence, the event will revert back to the series definition. Overridden events are not allowed in Apple Calendar integrations.

Recurrence in Google and Exchange

Google and Exchange have almost identical implementations when handling recurring events.

Consider the following:

A recurring event is created in Google with the rule that it should recur daily, ending after 4 times
We can see in the recurrence field the RRULE is: RRULE:FREQ=DAILY;COUNT=4
Now if an event is deleted in the series we see an EXDATE show up:
This is all well, but what happens if we modify a child? Changing its start time, end time, and summary:
As you can see, there is now an "Override" added to the parent. This "override" value contains the recurrence id of the child that was overridden. If we search on the recurrence id field for that value, we find the modified child:
In order to capture overridden children properly, a new event record is necessary. As any piece of information changed will constitute an override. In addition to capturing changing values, by using a new record we can take advantage of Zulu's time zone conversion processes for these child events.

Calendar Properties

The ZuluCalendarList layout is required for Zulu to work. It holds fields that correlate to calendar values. To see more about the Calendar and Event concepts, refer to: Zulu - Calendars and Publishing

zulu_displayName

This field determines the name of the calendar as it is viewed in Apple Calendar, Google, or Exchange. For Apple Calendar integrations, If you were to change the value of the zulu_displayName field, you would see the name of the calendar change in Apple Calendar. For Google and Exchange configurations, these values are set when you first make the configuration and will not reflect changes you make afterward.

zulu_databaseName

This field determines which database Zulu will access for the events. In most cases this should be the same database that contains the ZuluCalendarList layout.

zulu_layoutName

This field determines which layout Zulu will fetch events from. The layout specified by this field should have its fields mapped according to the instructions here: Zulu - Integrate Into FileMaker Solution.

It is possible to have different calendars look at different layouts for events. Keep this in mind when trying to determine how best to filter your calendars. This is a more maintenance heavy approach however, as you will need to maintain multiple events layouts as opposed to just one.

zulu_color

This field will alter the color applied in Apple Calendar. It requires a HEX color value. There are many HEX color pickers to choose from online, googling for "color picker" will yield numerous results. When you find the color you want, get the HEX value, and input it into the zulu_color field preceded by a "#".

This value in the zulu_color field will produce a calendar with a red color:

##FF0000

However, it is much easier to change the color in iCal. Simply right-click on a calendar's name in iCal and select "Get Info". You'll see a color selector to the right of the layout name. You can of course change the name the same way.

zulu_filterKey

The value in this field should be the field name that you want to search on when filtering calendars. See here for more details: Zulu - Filtering

zulu_filterValue

The value in this field will be searched for when filtering calendars. See here for more details: Zulu - Filtering

zulu_showDaysInPast

This field expects a number value, and will put a revolving lower limit on the events that are returned when filtering calendars. See here for more details: Zulu - Filtering

zulu_showDaysInFuture

This field expects a number value, and will put a revolving upper limit on the events that are returned when filtering calendars. See here for more details: Zulu - Filtering

zulu_uuid

This field is auto-populated, and contains a unique id. It is used in the background by Zulu when searching for a specific calendar.

zulu_dateCreated

The date this calendar record was created

zulu_createBy

The account that created this calendar record

zulu_dateModified

The date this calendar record was last modified

zulu_modifiedBy

The account that last modified this record

zulu_properties

This field stores the Field Mapping for the calendar record. It determines which fields on the events layouts should be mapped to which event properties.

This field is populated by publishing your calendars. See more information here: Zulu - Calendars and Publishing

Event Properties

These are the Event Properties that Zulu uses when dealing with events. For sanity, they are organized here by the FileMaker field name in the Zulu2SampleData database.

DateEnd

Event Property: END_DATE
Field Name: ZuluSampleEvents::DateEnd
Field Type: Date

The end date of the event.

DateStart

Event Property: START_DATE
Field Name: ZuluSampleEvents::DateStart
Field Type: Date

The start date of the event.

Event ID

Event Property: PKEVENT
Field Name: ZuluSampleEvents::Event ID
Field Type: Number

The primary key for this record. This will be used when updating events in FileMaker after an event has been edited in your calendar application. This field should be indexed.

Exchange_Attendees_Optional

Event Property: EOPTIONALATTENDEES
Field Name: ZuluSampleEvents::Exchange_Attendees_Optional
Field Type: Text

Exchange_Attendees_Required

Event Property: EREQUIREDATTENDEES
Field Name: ZuluSampleEvents::Exchange_Attendees_Required
Field Type: Text

Google_Attendees_Optional

Event Property: GOPTIONALATTENDEES
Field Name: ZuluSampleEvents::Google_Attendees_Optional
Field Type: Text

Google_Attendees_Required

Event Property: GREQUIREDATTENDEES
Field Name: ZuluSampleEvents::Google_Attendees_Required
Field Type: Text

Note

Event Property: DESCRIPTION
Field Name: ZuluSampleEvents::Note
Field Type: Text

The event description is a body of text including additional details about the event. This could also be considered the event note, or details.

Status

Event Property:
Field Name: ZuluSampleEvents::Status
Field Type: Text

This field is not required, and is only included in the Zulu2SampleData file as a means to demo filtering.

Summary

Event Property: SUMMARY
Field Name: ZuluSampleEvents::Summary
Field Type: Text

This is the title of the event.

TimeEnd

Event Property: END_TIME
Field Name: ZuluSampleEvents::TimeEnd
Field Type: Time

The end time of the event.

TimeStart

Event Property: START_TIME
Field Name: ZuluSampleEvents::TimeStart
Field Type: Time

The start time of the event.

zulu_ALARM_EMAIL_RECIPIENTS

Event Property: ALARM_EMAIL_RECIPIENTS
Field Name: ZuluSampleEvents::zulu_ALARM_EMAIL_RECIPIENTS
Field Type: Text

Return-separate list of email addresses to send alarm notifications. Only applicable when ALARM_TYPE=EMAIL.

zulu_ALARM_TRIGGER_MINUTES

Event Property: ALARM_TRIGGER_MINUTES
Field Name: ZuluSampleEvents::zulu_ALARM_TRIGGER_MINUTES
Field Type: Number

The number of minutes before the event that an alarm should be triggered. Takes priority over zulu_ALARM_TRIGGER_TIMESTAMP when determining when to trigger the alarm.

zulu_ALARM_TRIGGER_TIMESTAMP

Event Property: ALARM_TRIGGER_TIMESTAMP
Field Name: ZuluSampleEvents::zulu_ALARM_TRIGGER_TIMESTAMP
Field Type: TimeStamp

The date and time on which to trigger the alarm.

zulu_ALARM_TYPE

Event Property: ALARM_TYPE
Field Name: ZuluSampleEvents::zulu_ALARM_TYPE
Field Type: Text

Return-separate list of alarm types. Possible values are MESSAGE, AUDIO, or EMAIL. This field must be mapped in order for other alarm-related fields to have any affect.

zulu_CREATION_TIMESTAMP

Event Property: CREATION_TIMESTAMP
Field Name: ZuluSampleEvents::zulu_CREATION_TIMESTAMP
Field Type: TimeStamp

The timestamp on which this event was created.

zulu_DELETED

Event Property: DELETED
Field Name: ZuluSampleEvents::zulu_DELETED
Field Type: Number

A number field Zulu uses to tag an item to be deleted. When an event is deleted in you calendar application, Zulu does not delete the record in FileMaker. Instead, Zulu puts the value "1" in this field.

zulu_ICAL_DATA

Event Property: ICAL_DATA
Field Name: ZuluSampleEvents::zulu_ICAL_DATA
Field Type: Text

iCal data dump text field. This is populated by the server, and contains a text dump of all calendar data for an event. You will likely need to add a new field to your event table for this.

zulu_LOCATION

Event Property: LOCATION
Field Name: ZuluSampleEvents::zulu_LOCATION
Field Type: Text

Location of the event.

zulu_MODIFICATION_TIMESTAMP

Event Property: MODIFICATION_TIMESTAMP
Field Name: ZuluSampleEvents::zulu_MODIFICATION_TIMESTAMP
Field Type: TimeStamp

The timestamp on which this event was last modified.

zulu_RECURRENCE

Event Property: RECURRENCE
Field Name: ZuluSampleEvents::zulu_RECURRENCE
Field Type: Text

A json payload describing the recurrence rules for this event.

zulu_RECURRENCEID

Event Property: RECURRENCEID
Field Name: ZuluSampleEvents::zulu_RECURRENCEID
Field Type: Text

The recurrence id will have common values for every event in a recurrence series.

zulu_URL

Event Property: URL
Field Name: ZuluSampleEvents::zulu_URL
Field Type: Text

URL pertaining to the event. You can also include a URL in the description if you’d like.

zulu_UUID

Event Property: UUID
Field Name: ZuluSampleEvents::zulu_UUID
Field Type: Text

Text field which contains the Zulu UUID for an event. You will need to add a new field to your event table for the UUID. This field is populated by the Zulu. You should enable indexing on your UUID field, as it is searched on often.

Todo Properties

These are the Todo Properties that Zulu uses when dealing with todos.

Auto-Populated Fields

It's important that these fields are mapped, but they don't need to be modified by end users. These typically hold values that are only important for Zulu.

Event ID

Layout Object Name: PKEVENT
Field Type: Number

The primary key for the todo record.

zulu_UUID

Layout Object Name: UUID
Field Type: Text

zulu_CREATION_TIMESTAMP

Layout Object Name: CREATION_TIMESTAMP
Field Type: Timestamp

The timestamp on which this event was created.

zulu_MODIFICATION_TIMESTAMP

Layout Object Name: MODIFICATION_TIMESTAMP
Field Type: Timestamp

Modification timestamp of the event. This is used for caching purposes by calendar clients. This must be a timestamp field, not a date.

zulu_ALARM_TIMESTAMP_UUID

Layout Object Name: ALARM_TIMESTAMP_UUID
Field Type: Text

The internal UUID for the timestamp alarm. Zulu populates this when creating alarms in Apple Reminders.

zulu_ALARM_PROXIMITY_UUID

Layout Object Name: ALARM_PROXIMITY_UUID
Field Type: Text

The internal UUID for the proximity alarm. Zulu populates this when creating alarms in Apple Reminders.

zulu_ICAL_DATA

Layout Object Name: ICAL_DATA
Field Type: Text

The ICal text dump of the todo from Apple Reminders. This does need to be stored in FileMaker, but you shouldn't need to edit it.

zulu_DELETED

Layout Object Name: DELETED
Field Type: Number

A number field Zulu uses to tag an item to be deleted. You will likely need to add a new field to your event table for this. Enable indexing.

Basic Todo Fields

These fields are the bare minimum fields needed to get todos to show up.

Summary

Layout Object Name: SUMMARY
Field Type: Text

The SUMMARY is the title or name of the todo. Do NOT use a calculation here. Switch to auto-enter calculations if you have to, once Zulu is up and running.

zulu_STATUS

Layout Object Name: STATUS
Field Type: Text

This defines the current status of a to-do. Valid values are: NEEDS-ACTION, COMPLETED, IN-PROGRESS, and CANCELLED

zulu_COMPLETED

Layout Object Name: COMPLETED
Field Type: Timestamp

This field will hold the timestamp when a to-do was marked completed.

Optional Fields

These fields are optional, but provide some extra functionality that is worth using.

Note

Layout Object Name: DESCRIPTION
Field Type: Text

A more complete description of the event than is provided by the SUMMARY field. On OSX, this shows up under the summary for the todo.

zulu_DUE

Layout Object Name: DUE
Field Type: Timestamp

This specifies when the todo is expected to be completed. Apple Reminders will display this as the due date.

zulu_PRIORITY

Layout Object Name: PRIORITY
Field Type: Number

This represents the priority of the todo. Reminders show this as Low/Medium/High/None, but represented as a number here. You can create a calculation field that translates to more human-readable.

zulu_ACTIVITY

Layout Object Name: ACTIVITY
Field Type: Text

This field is multipurpose. A specific value in the field will be represented as an actionable icon on the Reminder. Some examples are:

tel:7702349293 - this will allow the user to call a phone number from the reminder.
https://www.google.com/ - this will open a web page.
fmp://127.0.0.1/Zulu2SampleData - this will open a FileMaker database.

Timestamp Alarm Fields

These are the fields used to create a timestamp alarm. A timestamp alarm will show a notification to the user at a specific date and time.

zulu_ALARM_TRIGGER_TIMESTAMP

Layout Object Name: ALARM_TRIGGER_TIMESTAMP
Field Type: Timestamp

The date and time the alarm should go off.

Proximity Alarm Fields

These are the fields used to create proximity alarms. Proximity alarms will show an alert to the user when they arrive or depart a certain location.

zulu_ALARM_PROXIMITY

Layout Object Name: ALARM_PROXIMITY
Field Type: Text

How the proximity alarm should be triggered. Valid values are ARRIVE and DEPART. This will determine if the proximity alarm is triggered when arriving or departing the location described by the latitude and longitude coordinates.

zulu_ALARM_LOCATION_TITLE

Layout Object Name: ALARM_LOCATION_TITLE
Field Type: Text

Title of the location for the proximity alarm.

zulu_ALARM_COMPLEX_TITLE

Layout Object Name: ALARM_COMPLEX_TITLE
Field Type: Text

URL Encoded title, which will show as a friendly name for the location of the proximity alarm.

zulu_ALARM_RADIUS

Layout Object Name: ALARM_RADIUS
Field Type: Number

This field determines the distance in meters from the coordinates that should trigger the proximity alarm. This defaults to the value 400.

zulu_ALARM_LATITUDE

Layout Object Name: ALARM_LATITUDE
Field Type: Number

The latitude of the location for the proximity alarm.

zulu_ALARM_LONGITUDE

Layout Object Name: ALARM_LONGITUDE
Field Type: Number

The longitude of the location for the proximity alarm.

Logging Properties

If you're running into large log files or just want to limit the size of your log files in general, you may edit the logging properties in Zulu.

Step 1

Navigate to the following directory for your respective systems and open up logging.properties in your text editor of choice.

Windows

C:\Program Files\360Works\Application\webapps\zulu\WEB-INF\classes\

Mac

Library/360Works/Application/webapps/zulu/WEB-INF/classes/

Other

If you cannot find either directory, you may have a custom installation of Zulu. Please contact the system administrator who installed Zulu for assistance finding this installation location.

Important

If you did a hosting provider installation of zulu, the "zulu" in the filepath will instead be the name you gave to your hosting provider installation.

Step 2

With logging.properties open, do a search for the 1catalina.org.apache.juli.FileHandler.level property. You want to change the text after the property to the level you want to log. By default, it is INFO, please revert your logging level to INFO if you require support.

Primary Logging Levels

FINEST
FINER
FINE
CONFIG
INFO
WARNING
SEVERE

To change the logging level, simply change the last word to match the level you want to log. FINEST is the most granular and verbose level and will log everything. SEVERE is the least verbose and will log only SEVERE level errors.

Example

1catalina.org.apache.juli.FileHandler.level = SEVERE

Once you've set it to the level you'd like, go ahead and save the file.

Step 3

Restart Zulu in the 360Works Admin Tool to begin logging at the level you've set. This utility is found in /Applications on Mac or C:\Program Files\360Works on Windows

Reasons to change logging level

For a single-instance of Zulu changing the level will likely be unnecessary, but for multiple instances (which you will need to change the logging properties for each instance) your log file can build up, fast. Changing the log level can save disk space on your system, especially if you have Zulu refreshing at a short interval.

Increasing Memory Allocation

Zulu has a default memory allocation of 1024 MB. This memory allocation is shared across all 360Works web apps that are installed on the machine. If you are getting out of memory errors, you will need to increase the memory allocation for Zulu. Please follow the instructions below to do so.

Allocate more memory for Zulu

If you need to increase the memory allocation, modify the setenv file in a text editor. The file is located here:

Mac: /Library/360Works/Applications/bin/setenv.sh
Windows: C:\Program Files\360Works\Applications\bin\setenv.bat

Look at the line that begins:

CATALINA_OPTS="-Dcom.prosc.tomcat=true -Xmx1024M

Modify the -Xmx parameter to allocate the desired amount of memory. Below is an allocation of 1 Gigabytes

CATALINA_OPTS="-Dcom.prosc.tomcat=true -Xmx1G

The new memory settings won't take effect until Tomcat is restarted, which can be done using the 360Works Admin utility, which you can restart using the instructions here: Restart_tomcat

Advanced Settings

Zulu uses an XML file named zulu.xml to store additional configuration settings. These settings are outlined here, as well as the location of the xml file in default installations.

Locating The zulu.xml File

Mac default location:

/Volumes/Macintosh HD/Library/360Works/Applications/conf/Catalina/localhost/zulu.xml

Windows default location:

C:/Program Files/360Works/Applications/conf/Catalina/localhost/zulu.xml

Modifying The zulu.xml File

Any modifications to this file will not be picked up until the Zulu service is restarted. In some cases, such as "zulu.admin.email" and "google.client.id", changes will not be picked up until your sync configurations have been edited, and stepped through to the end to apply the changes. In this case, you will need to modify the zulu.xml file, restart zulu, then step through the configurations to apply the changes.
Sometimes on Windows, a user does not have permissions to modify the zulu.xml file. To get around this, save a copy to the desktop, modify it there, then paste it back into the original location, overriding the original file.
The Zulu installer will not overwrite a zulu.xml file if one exists already. In most cases this is beneficial, as customizations will not be lost when a new version of Zulu is installed. However, for the few times when you want to do a completely fresh install, make sure that there are not old customizations in the zulu.xml file causing issues, as a new install will not wipe out the old xml file.
If there have been newer settings added in later versions of Zulu, but you are not seeing those settings in your xml file, you can add them manually. Here is an example of adding the zulu.autodiscover.database parameter inside the zulu.xml file:

<Parameter name="zulu.autodiscover.database" value="Zulu2SampleData" override="false"/>

zulu.xml File Parameters

jdbc.username

jdbc.username and jdbc.password are the default values to try if the user does not supply any username or password. In most cases, these should be left to these (presumably wrong) values, so that the world will not have access to your calendar data. However, if you would like to allow non-authenticated requests to access the calendar without providing a username and password, enter credentials that correspond to a FileMaker account with whatever privilege set you want to grant. This is useful for creating a public calendar where users would not need to enter credentials in order to access.

Zulu will need to be restarted for changes to take effect.

jdbc.password

See jdbc.username above.

Zulu will need to be restarted for changes to take effect.

jdbc.host

This is the address that Zulu will use when communicating with FileMaker Server. Zulu expects to be installed on the same machine as FileMaker Server, so by default this value is 127.0.0.1. If you have Zulu running on a different machine, you can customize this value to point to your FileMaker Server's endpoint.

Zulu will need to be restarted for changes to take effect. Configurations will need to be re-stepped through in order to apply changes.

jdbc.ssl

Setting this to "true" will cause Zulu to read and write records to FileMaker Server over SSL. This only affects traffic between Zulu and FileMaker server, and has no effect on traffic between calendar clients and Zulu. To enforce SSL between calendar clients and Zulu, you will need to install an SSL certificate in the web server where Zulu is running. Setting this to "true" when Zulu and FileMaker Server are on the same machine is not generally useful, as traffic never leaves the machine.

360WorksDirectory

This is where MirrorSync stores all of it settings and internal sync data. Ideally, this should be on a fast SSD drive. If this parameter is empty, it will use the default location:

Windows: C:\Program Files\360Works
Mac: /Library/360Works
Linux: /var/lib/360works

You can copy the folder from the default install location and then change this setting to point to the new location.

Zulu will need to be restarted for changes to take effect.

google.client.id

This parameter is for supplying your own Google Api Key. The Google Client ID will go here.

Supplying your own Api Key allows you to get your own Api Quota, one that is not shared by other Zulu users.

Zulu will need to be restarted for changes to take effect. Configurations will need to be re-stepped through in order to apply changes.

google.client.secret

This parameter is for supplying your own Google Api Key. The Google Client Secret will go here.

Supplying your own Api Key allows you to get your own Api Quota, one that is not shared by other Zulu users.

Zulu will need to be restarted for changes to take effect. Configurations will need to be re-stepped through in order to apply changes.

zulu.admin.email.level

This will customize when you receive emails if there are issues with the sync. Valid options are:

WARNING - Receive emails when there were warnings and records could not be written, but otherwise a successful sync.
SEVERE - Only receive emails when the sync failed outright and encountered an error it could not recover from.

Zulu will need to be restarted for changes to take effect. Configurations will need to be re-stepped through in order to apply changes.

internalDatabaseCache

Increase this value if you have a very large internal sync database and get this error message: "Data cache size limit is reached: 10000

Zulu will need to be restarted for changes to take effect.

adminUsername

The adminUsername and adminPassword parameters will be the credentials used when logging in to the Zulu Admin Console. The values here will override the ones set during installation.

The username and password for administering Zulu are normally set via the installer. However, in a hosted environment, Zulu is installed manually. You will need to enter a username and password here for administering Zulu if you do a manual installation.

Zulu will need to be restarted for changes to take effect.

adminPassword

See adminUsername above.

adminPasswordHash

If you prefer not to enter your password in plaintext, you can generate an MD5 hash of it using utf-8 encoding, BASE64 encode it, and enter it here instead of zulu.adminPassword. If both values are entered, the zulu.adminPasswordHash will take precedence.

Zulu will need to be restarted for changes to take effect.

zulu.timezone

Zulu uses this value when evaluating events in FileMaker. Since FileMaker does not store any time zone information, Zulu applies this time zone value to the date and time values it receives from FileMaker. If this value is empty, Zulu will use the time zone of the system it is installed on.

You can optionally specify a TimeZone for this application. The default value is whatever time zone the computer running Zulu is set to. This is useful if the computer running Zulu is in a different time zone than most of your users. See here for the list of valid timezone names: https://joda-time.sourceforge.net/timezones.html

Zulu will need to be restarted for changes to take effect.

zulu.autodiscover.database

This parameter is needed for AutoDiscovery to work, which lets your users setup Apple Calendars and Reminders quicker.

This parameter should be the name of the database that contains your records for calendars, events, and reminders.

Zulu will need to be restarted for changes to take effect.

com.prosc.caldav.publishUrl

This controls the url that is displayed when calendars are published. This should only be changed in unusual cases.

Zulu will need to be restarted for changes to take effect.

zulu.enforceStrictWrites

Change this parameter to "true" to enforce strict one-way syncing for newly created configurations. Strict one-way syncing will revert events back to how they are in FileMaker if there are any changes made in the calendar application.

Zulu will need to be restarted for changes to take effect.

zulu.allowUnauthenticatedRequests

This parameter determines whether Zulu will use the credentials in the jdbc.username and jdbc.password to automatically authenticate requests to FileMaker.

Change this parameter to false to prevent Zulu from attempting unauthenticated requests. Setting this to false will also prevent Zulu from using the default credentials jdbc.username and jdbc.password above.

Zulu will need to be restarted for changes to take effect.

com.prosc.caldav.datasource.DataSourceFactory

This is for internal use and should generally not be changed

jdbc.driver

This is for internal use and should generally not be changed

Reporting an issue

You typically should not need to know the location of Zulu log files, Zulu comes with a bug reporting feature. From the Sync Admin Page (located at http://yourServerAddress/zulu), click on the link in the page header titled Email Log File. This will take you to a bug reporting form which will automatically zip up and send your log file along with your problem report to 360Works support.

Shows the location of the 'send logs' button in the zulu admin page

Using the zulu admin to send a problem report

Log Files

If you are not able to submit a log file using the "Email Log File" link, you can still open a support ticket with us by emailing support@360works.com. If possible, retrieve the log files from the locations below and include them in the email.

In all log locations 'xxxx-xx-xx' refers to the date the log was written in yyyy-mm-dd format.

Windows

C:\Program Files\360Works\Applications\logs\Zulu.xxxx-xx-xx.log

Mac

/Library/360Works/Applications/logs/Zulu.xxxx-xx-xx.log

Zulu

Table of Contents:

To Demo and Purchase​

Quick Start​

Apple Calendar​

Google Calendar​

Exchange Calendar​

Upgrading From Zulu 2​

When Using Apple Calendars​

When Syncing with Google or Exchange Calendars​

Zulu.xml Customization​

Installation​

Standard Installation​

Prerequisites​

Installation Steps​

Mac and Windows​

Linux​

Post Installation​

Custom Installation​

Prerequisites​

Installing Zulu 3​

URL Redirection​

Windows​

Mac​

Restart Web Server​

Troubleshooting Installation​

Can not access the Zulu admin page​

Shell execution failed. Verify that Java is installed and run setup again.​

Could not configure web server forwarding because of an error​

Calendars and Publishing​

How does Zulu correlate FileMaker records to Calendars and Events?​

Why Do I Publish My Calendars?​

How To Publish Calendars​

When Using the Zulu2SampleData File​

When Integrating Zulu Into Your Own Solution​

Customizing The Publish Script​

Confirm That The Calendars Were Published​

Publishing Notes And Troubleshooting​

Integrate Into Your FileMaker Solution​

Prerequisites​

Components to Import​

Scripts​

ZuluCalendarList Table​

Events Table And Field Mapping​

Overview​

Setup Event Field​

Notes​

Publish your calendar​

Going Further​

The Admin Console​

Accessing The Zulu Admin Console​

Registration​

Sync Admin​

Configuration List​

Edit​

Remove​

Reset Sync Data​

Sync Now​

Auto Sync​

Add New Sync Configuration​

Email Log File​

Filtering Calendars​

Overview​

Filtering By Value​

Notes​

Filtering Todos​

Filtering By Day Range​

Notes​

Filtering By Record Level Access Privileges​

Filtering Calendars By FileMaker Account​

Walkthrough​

Event Hooks​

Zulu_PostEdit​

Zulu_PreDelete​

Zulu_PostEdit_Todo​

Zulu_PreDelete_Todo​

Integrating with Apple Calendars​

Prerequisites​

Setting Up AutoDiscovery​

Adding Calendars to Apple Calendar​

To Demo and Purchase

Quick Start

Apple Calendar

Google Calendar

Exchange Calendar

Upgrading From Zulu 2

When Using Apple Calendars

When Syncing with Google or Exchange Calendars

Zulu.xml Customization

Installation

Standard Installation

Prerequisites

Installation Steps

Mac and Windows

Linux

Post Installation

Custom Installation

Prerequisites

Installing Zulu 3

URL Redirection

Windows

Mac

Restart Web Server

Troubleshooting Installation

Can not access the Zulu admin page

Shell execution failed. Verify that Java is installed and run setup again.

Could not configure web server forwarding because of an error

Calendars and Publishing

How does Zulu correlate FileMaker records to Calendars and Events?

Why Do I Publish My Calendars?

How To Publish Calendars

When Using the Zulu2SampleData File

When Integrating Zulu Into Your Own Solution

Customizing The Publish Script

Confirm That The Calendars Were Published

Publishing Notes And Troubleshooting

Integrate Into Your FileMaker Solution

Prerequisites

Components to Import

Scripts

ZuluCalendarList Table

Events Table And Field Mapping

Overview

Setup Event Field

Notes

Publish your calendar

Going Further

The Admin Console

Accessing The Zulu Admin Console

Registration

Sync Admin

Configuration List

Edit

Remove

Reset Sync Data

Sync Now

Auto Sync

Add New Sync Configuration

Email Log File

Filtering Calendars

Overview

Filtering By Value

Notes

Filtering Todos

Filtering By Day Range

Notes

Filtering By Record Level Access Privileges

Filtering Calendars By FileMaker Account

Walkthrough

Event Hooks

Zulu_PostEdit

Zulu_PreDelete

Zulu_PostEdit_Todo

Zulu_PreDelete_Todo

Integrating with Apple Calendars

Prerequisites

Setting Up AutoDiscovery

Adding Calendars to Apple Calendar

For OSX (Apple Computers)

Adding a CalDAV Account With AutoDiscovery