Difference between revisions of "360Deploy"
Line 2: | Line 2: | ||
+ | ==Overview== | ||
− | + | 360Deploy is a product aiming to simplify the tedious process of deploying a development database onto a production server at the click of a button. Developers working on a file can now deploy changes made to database structure at the click of a button while avoiding the traditional downtime and labor associated with the process. All that is required is the use of our plug-in, opening our deployment file, arranging IP addresses to the appropriate servers, and click go! | |
+ | |||
+ | What 360Deploy does is it make an empty clone of the production database, moves it to the deployment database, and then import all existing data into the new clone. | ||
+ | Development Server: The server where designers are making | ||
+ | |||
+ | Required database changes | ||
+ | - Enable fmapp and fmurlscript in Extended Privileges | ||
+ | - Database should be password protected (required by default in FileMaker Server) | ||
+ | - Comment out script steps in triggers that automatically make any write operations in startup scripts (set fields, new records). | ||
+ | |||
+ | If [Get ( FoundCount ) = 0] | ||
+ | New Record/Request | ||
+ | End if | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ==Why use 360Deploy?== | ||
+ | |||
+ | When reworking a live database, traditionally a development copy is worked on first. | ||
+ | |||
+ | 3 Choices to deploy DB changes: | ||
+ | Make a log of all changes made to development server, then reflect changes onto production server while it's down. | ||
+ | Separation model - creates compromises, involves workarounds, has trade-offs. | ||
+ | Import all data from old data into empty clone of new file, make sure serial numbers are manually adjusted, tedious process | ||
+ | |||
+ | Problem it solves: Let's say you create a big database for your client and need to add more features, current methods are problematic. Working on databases can be slow, interfering, and testing is problematic. | ||
+ | |||
+ | |||
+ | |||
+ | ==Technical Description== | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ==Overview== | ||
+ | MirrorSync is an elegant synchronization product that can sync between any combination of FileMaker Pro, FileMaker Go, FileMaker Server, SQL database (MySQL, Oracle, SQL Server, or any database that supports JDBC), Salesforce, and Amazon RedShift. For mobile devices, users can sync the hosted file with their FMGo or Pro clients, go off network to make changes, and sync again when a connection is available. For servers, MirrorSync allows a database to run in multiple locations, or to integrate different databases and make sure that changes to each server are reflected in the other server. | ||
+ | |||
+ | MirrorSync is only installed on the server computer. It is not a plug-in, and does not require any software installation on client devices. | ||
+ | |||
+ | MirrorSync is extremely easy to set up. The only required database changes are: | ||
+ | # Enabling the FMXML and FMXDBC extended privileges in your security configuration | ||
+ | # Making sure that every table you want to sync has a primary key, modification timestamp, and creation timestamp. | ||
+ | # Creating a layout for each table. | ||
+ | # Four copy and paste operations. | ||
+ | |||
+ | <center> [[File:MirrorSyncTwitterFeed.jpg| 478 px |link=https://twitter.com/360Works |alt= @360Works on Twitter |@360Works on Twitter]] </center> | ||
+ | |||
+ | ==Why use MirrorSync?== | ||
+ | # For mobile users who access the database with FileMaker Go on their iOS device, MirrorSync allows these users to work efficiently with limited or no connectivity to the server network. Each user can take a local copy on their iPad or iPhone, input the information from the field, and then sync when they regain a network connection. Depending on their workflow, they could even specify a one-way sync where their information is pushed to the server, but no data is pulled down, or vice versa for users who need fast read-only information. | ||
+ | # For remote users who work on laptops, MirrorSync solves the problem of how to work productively on a hosted FileMaker database, regardless of network speed. If, for example, you have multiple users connecting to FileMaker Server over a wide area network (WAN) you could notice a substantial slowdown, as every change is immediately written back to FileMaker Server. MirrorSync allows each user to take a local copy of the database which would run on the user's machine and not be affected by the WAN performance. The user could sync when they first came into the office, work on their local copy throughout the day, and sync at specified times (or on demand) to push and pull the latest data to the server. | ||
+ | # For groups of users at multiple locations, MirrorSync should be used in server-to-server mode, where an identical copy of the database is installed on FileMaker Server in each location. Each workgroup works at full LAN speed on their own FileMaker Server, and MirrorSync takes care of keeping the servers in sync with each other, so that each workgroup can see and edit changes made by the other group. In this configuration, MirrorSync should be set to sync very often, such as every 30-60 seconds. | ||
+ | # To maximize performance and reliability, MirrorSync can be used in a clustering configuration, where two or more servers are running at the same data center and synchronized so that they all contain the same set of data. This means that each server only needs to work with 1/2 or less of the total users, and if one server goes down, the other server can take over the entire workload seamlessly. For a video demo of this, see https://www.youtube.com/watch?v=bQlGHrNtHCg | ||
+ | # For integration with non-FileMaker databases, MirrorSync is the simplest and most efficient way to accomplish this. For instance, if you have an online storefront running with MySQL or Oracle at a remote data center, but you need to have instant access to all of the orders in a database running on FileMaker Server, MirrorSync can selectively sync certain SQL tables to FileMaker, even if the table and field names do not match. In this configuration, MirrorSync should be set to sync fairly often, such as every 5-10 minutes. | ||
+ | |||
+ | == Require |
Revision as of 02:41, 19 July 2017
360 Deploy Documentation
Overview
360Deploy is a product aiming to simplify the tedious process of deploying a development database onto a production server at the click of a button. Developers working on a file can now deploy changes made to database structure at the click of a button while avoiding the traditional downtime and labor associated with the process. All that is required is the use of our plug-in, opening our deployment file, arranging IP addresses to the appropriate servers, and click go!
What 360Deploy does is it make an empty clone of the production database, moves it to the deployment database, and then import all existing data into the new clone. Development Server: The server where designers are making
Required database changes - Enable fmapp and fmurlscript in Extended Privileges - Database should be password protected (required by default in FileMaker Server) - Comment out script steps in triggers that automatically make any write operations in startup scripts (set fields, new records).
If [Get ( FoundCount ) = 0]
New Record/Request
End if
Why use 360Deploy?
When reworking a live database, traditionally a development copy is worked on first.
3 Choices to deploy DB changes: Make a log of all changes made to development server, then reflect changes onto production server while it's down. Separation model - creates compromises, involves workarounds, has trade-offs. Import all data from old data into empty clone of new file, make sure serial numbers are manually adjusted, tedious process
Problem it solves: Let's say you create a big database for your client and need to add more features, current methods are problematic. Working on databases can be slow, interfering, and testing is problematic.
Technical Description
Overview
MirrorSync is an elegant synchronization product that can sync between any combination of FileMaker Pro, FileMaker Go, FileMaker Server, SQL database (MySQL, Oracle, SQL Server, or any database that supports JDBC), Salesforce, and Amazon RedShift. For mobile devices, users can sync the hosted file with their FMGo or Pro clients, go off network to make changes, and sync again when a connection is available. For servers, MirrorSync allows a database to run in multiple locations, or to integrate different databases and make sure that changes to each server are reflected in the other server.
MirrorSync is only installed on the server computer. It is not a plug-in, and does not require any software installation on client devices.
MirrorSync is extremely easy to set up. The only required database changes are:
- Enabling the FMXML and FMXDBC extended privileges in your security configuration
- Making sure that every table you want to sync has a primary key, modification timestamp, and creation timestamp.
- Creating a layout for each table.
- Four copy and paste operations.
Why use MirrorSync?
- For mobile users who access the database with FileMaker Go on their iOS device, MirrorSync allows these users to work efficiently with limited or no connectivity to the server network. Each user can take a local copy on their iPad or iPhone, input the information from the field, and then sync when they regain a network connection. Depending on their workflow, they could even specify a one-way sync where their information is pushed to the server, but no data is pulled down, or vice versa for users who need fast read-only information.
- For remote users who work on laptops, MirrorSync solves the problem of how to work productively on a hosted FileMaker database, regardless of network speed. If, for example, you have multiple users connecting to FileMaker Server over a wide area network (WAN) you could notice a substantial slowdown, as every change is immediately written back to FileMaker Server. MirrorSync allows each user to take a local copy of the database which would run on the user's machine and not be affected by the WAN performance. The user could sync when they first came into the office, work on their local copy throughout the day, and sync at specified times (or on demand) to push and pull the latest data to the server.
- For groups of users at multiple locations, MirrorSync should be used in server-to-server mode, where an identical copy of the database is installed on FileMaker Server in each location. Each workgroup works at full LAN speed on their own FileMaker Server, and MirrorSync takes care of keeping the servers in sync with each other, so that each workgroup can see and edit changes made by the other group. In this configuration, MirrorSync should be set to sync very often, such as every 30-60 seconds.
- To maximize performance and reliability, MirrorSync can be used in a clustering configuration, where two or more servers are running at the same data center and synchronized so that they all contain the same set of data. This means that each server only needs to work with 1/2 or less of the total users, and if one server goes down, the other server can take over the entire workload seamlessly. For a video demo of this, see https://www.youtube.com/watch?v=bQlGHrNtHCg
- For integration with non-FileMaker databases, MirrorSync is the simplest and most efficient way to accomplish this. For instance, if you have an online storefront running with MySQL or Oracle at a remote data center, but you need to have instant access to all of the orders in a database running on FileMaker Server, MirrorSync can selectively sync certain SQL tables to FileMaker, even if the table and field names do not match. In this configuration, MirrorSync should be set to sync fairly often, such as every 5-10 minutes.
== Require