Upgrade to AEM 6.1 forms from AEM 6.0 forms for OSGi

Before you upgrade

Perform the following steps, before upgrading from AEM 6.0 forms to AEM 6.1 forms:

• Install the latest service pack and patches for AEM 6.0 forms.
• (If your AEM 6.0.1 instance is running on CRX2 repository) Open the Web Bundles console http://localhost:4502/system/console/bundles, delete the com.day.crx.sling.server bundle, and shut down the AEM instance.\

Perform the upgrade

Perform the following steps to upgrade from AEM 6.0 forms to AEM 6.1 forms:

Download the AEM 6.1 QuickStart.
Replace the AEM 6.0 QuickStart with AEM 6.1 QuickStart and start the author instance.
Starting the AEM 6.1 QuickStart, upgrades the existing crx-repository to AEM 6.1, automatically migrates the content from older version to newer version, and creates a folder named archived-versions.  
After the server is up and running, shut down the AEM instance.
It might take a few minutes for the AEM instance to be up and running. You can consider the AEM instance is up and running after the [AEM-root]/logs/error.log file becomes stable.
Open the archived-versions folder and copy all the folders inside archived-versions folder to the [AEM_root]\crx-repository folder. Restart the AEM 6.1 QuickStart.  
Download and install AEM forms add-on package.
Note:
Before installing the AEM forms add-on package, ensure that the installation path of the AEM Quickstart does not contain any spaces.  
AEM forms 6.1 add-on package	Download link
AEM forms add-on package for AIX	adobe-aemfd-aix-pkg
AEM forms add-on package for Linux	adobe-aemfd-linux-pkg
AEM forms add-on package for Solaris	adobe-aemfd-solaris-pkg
AEM forms add-on package for Windows	adobe-aemfd-win-pkg
Central Migration Bridge and Send to printer Services	adobe-aemfd-cmb-pkg
Add on package for Geometrixx Finance sample site	cq-geometrixx-finance-pkg
Caution:
After installing the add-on package, you will get a prompt to restart the server. However, do not immediately restart. Ensure that error.log is stable and all bundles (except signatures) are in active mode before you restart the server.
Configure the Doc Assurance Service
The DocAssurance service is not available out of the box. It requires RSA and BouncyCastle libraries installed with AEM forms package. Perform the following steps to bootdelegate these libraries:   
Stop the AEM server.
Open the sling.properties at [AEM installation]\crx-quickstart\conf\ for editing.
Note:
If you use [AEM_root]\crx-quickstart\bin\start.bat to start AEM, then edit the sling.properties at [AEM_root]\crx-quickstart\
Add the following properties to the sling.properties file:
1 2	sling.bootdelegation.class.com.rsa.jsafe.provider.JsafeJCE=com.rsa.* sling.bootdelegation.class.org.bouncycastle.jce.provider.BouncyCastleProvider=org.bouncycastle.*
Save and close the file. Restart the AEM server.

Verify the upgraded instance

Open Web Bundles console and ensure that all the bundles at /system/console/bundle are active. The default address of the Web Bundles is http://localhost:4502/system/console/bundles.
Open the package manager, ensure that a cq-content package with version 6.1 exists.

HOW DISPATCHER RETURNS DOCUMENTS : How DISPATCHER caching Works ?

The Dispatcher always requests the document directly from the AEM instance in the following cases:

• If the HTTP method is not GET. Other common methods are POST for form data and HEAD for the HTTP header.
• If the request URI contains a question mark "?". This usually indicates a dynamic page, such as a search result, which does not need to be cached.
• The file extension is missing. The web server needs the extension to determine the document type (the MIME-type).
• The authentication header is set (this can be configured)

Determining if a document is cached
The Dispatcher stores the cached files on the web server as if they were part of a static website. If a user requests a cacheable document the Dispatcher checks whether that document exists in the web server's file system:

• if the document is cached, Dispatcher returns the file.
• if it is not cached, the Dispatcher requests the document from the AEM instance.

Determining if a document is up-to-date
To find out if a document is up to date, the Dispatcher performs two steps:

1. It checks whether the document is subject to auto-invalidation. If not, the document is considered up-to-date.
2. If the document is configured for auto-invalidation, the Dispatcher checks whether it is older or newer than the last change available. If it is older, the Dispatcher requests the current version from the AEM instance and replaces the version in the cache.

Methods for Caching
The Dispatcher has two primary methods for updating the cache content when changes are made to the website.

• Content Updates remove the pages that have changed, as well as files that are directly associated with them.
• Auto-Invalidation automatically invalidates those parts of the cache that may be out of date after an update. i.e. it effectively flags relevant pages as being out of date, without deleting anything.

Content Updates
In a content update, one or more AEM documents change. AEM sends a syndication request to the Dispatcher, which updates the cache accordingly:

1. It deletes the modified file(s) from the cache.
2. It deletes all files that start with the same handle from the cache. For example, if the file /en/index.html is updated, all the files that start with /en/index. are deleted. This mechanism allows you to design cache-efficient sites, especially in regard to picture navigations.
3. It touches the so-called statfile; this updates the timestamp of the statfile to indicate the date of the last change.

The following points should be noted:

• Content Updates are typically used in conjunction with an authoring system which "knows" what must be replaced.
• Files that are affected by a content update are removed, but not replaced immediately. The next time such a file is requested, the Dispatcher fetches the new file from the AEM instance and places it in the cache, thereby overwriting the old content.
• Typically, automatically generated pictures that incorporate text from a page are stored in picture files starting with the same handle - thus ensuring that the association exists for deletion. For example, you may store the title text of the page mypage.html as the picture mypage.titlePicture.gif in the same folder. This way the picture is automatically deleted from the cache each time the page is updated, so you can be sure that the picture always reflects the current version of the page.
• You may have several statfiles, for example one per language folder. If a page is updated, AEM looks for the next parent folder containing a statfile, and touches that file.

Auto-invalidation
Auto-invalidation automatically invalidates parts of the cache - without physically deleting any files. At every content update, the so-called statfile is touched, so its timestamp reflects the last content update.
The Dispatcher has a list of files that are subject to auto-invalidation. When a document from that list is requested, the Dispatcher compares the date of the cached document with the timestamp of the statfile:

• if the cached document is newer, the Dispatcher returns it.
• if it is older, the Dispatcher retrieves the current version from the AEM instance.

Again, certain points should be noted:

• Auto invalidation is typically used when the inter-relations are complex e.g. for HTML pages. These pages contain links and navigation entries, so they usually have to be updated after a content update. If you have automatically generated PDF or picture files, you may choose to auto-invalidate those too.
• Auto-invalidation does not involve any action by the dispatcher at update time, except for touching the statfile. However, touching the statfile automatically renders the cache content obsolete, without physically removing it from the cache.