Introduction

Welcome to CHILI GraFx (formerly CHILI publisher Online).

CHILI GraFx is a SaaS platform powered by Microsoft Azure. It differs greatly from our previous on-premises solutions. While CHILI publisher was a file-based http://ASP.NET and Windows Services application, CHILI GraFx is a new type of product that is containerized and optimized for the Azure platform.

We will not host your CHILI instances on a single Windows virtual machine. Instead, we host CHILI in a tenant made up of multiple containers that shrink and grow based on usage. Potentially, each environment may exist in different tenants and in different regions.

Common General Questions

What is the big technical difference between CHILI GraFx and older legacy products?

 Will you also act as an IIS server?

How do I transfer my data?

Will my document, assets, etc. IDs and names stay the same after transfer?

How do I access my environment?

What is the difference between sandbox and production environments?

 Can we have our own domain?

 Can I RDP or FTP into my server?

Will there be any extra development required to transfer to CHILI GraFx?

Common Integration Roadblocks

In theory, connecting your integration to CHILI GraFx is as simple as changing a URL endpoint, but there may be some technical changes to keep in mind.

The following changes need to be known before connecting your old integration to CHILI GraFx.

• REST API replaces SOAP

• There is no Admin environment

• Each environment is its own URL

• The environment is public

• There is no direct access to the data folder

• ResourceGetTree not supported

Change 1: REST API replaces SOAP

Old Workflow

Every integration created prior to 2019 or 2020 used our SOAP API for interactive with a CHILI server.

New Workflow

Our SOAP API has been replaced with our REST API. While it may still be available in CHILI GraFx, it is considered deprecated, and can be removed at any time without notice.

See: SOAP to REST - GraFx Publisher Documentation - Confluence (atlassian.net)

Change 2: There is no admin environment

Old Workflow

A common workflow for some clients was to create one user in the Admin environment and then use the SOAP call SetWorkingEnvironment to switch the API key of that user to whichever environment the integration needed.

New Workflow

The Admin environment does not exist in CHILI GraFx, and each environment can exist across multiple regions or tenants.

Instead of having one Admin user, each CHILI GraFx environment will have a unique user that your API integration will use. To make the workflow easy, it is suggested that the users on each environment match in both name and password. By having them match in both username and password means you can recycle the same code across your different sites.

Change 3: Each environment is its own URL

Old Workflow

When dealing with CORS, it was commonplace to set up one subdomain or one reverse proxy to your on-prem CHILI publisher site.

The CHILI Editor runs in a <iframe> tag, which means that the content loaded is subject to the same-origin policy. In short, this means that trying to interact with the CHILI Editor using JavaScript will cause the browser security to block the interaction if the domains do not match.

New Workflow

With CHILI GraFx you can no longer just change a path on your URL and change the environment as each environment has its own URL.

You have two solutions:

• Use the library Publisher Interface Library

• Use a reverse proxy, which if you are ready using, you need to just change the configuration.

Change 4: The environment is public

Old Workflow

Some integrations had their CHILI server on an internal networking, meaning that their environment was not public. Some integrations had their CHILI server communicating with internal networks for external assets or external data sources.

New Workflow

All environments on CHILI GraFx are public. If you purchase a private cloud, we can whitelist certain IPs which basically makes the CHILI instance "private" because it blocks out all other connecting IPs. However, most clients do not purchase a private cloud, so there is nothing that can be done to block external IPs.

For internal servers providing external assets or external data sources, we can provide the static IP addresses for our CHILI instances. Then you can make those internal servers have a public connection which whitelists our static IP addresses for communication.

Change 5: There is no direct access to the data folder

Old Workflow

With direct access to the data folder, it was common to set up PDF Export Settings that output to a folder on the server or a shared data folder.

With direct access to the data folder, it was common to transfer files from one environment to another for testing purposes.

New Workflow

Since direct access to the data folder is no longer available, you can no longer have PDF Export Settings that output to a folder. Instead, you will need to develop a service that will poll the task XML returned from output API functions (DocumentCreatePDF and DocumentCreateImages) and download the results to a server to then be placed in a folder.

Since direct access to the data folder is no longer available, you can no transfer files from one environment to another using Windows IO calls. Instead, you will need to develop a service the will use the API endpoints: SetNextResourceItemID, ResourceItemAdd, ResourceItemSave. These API endpoints will allow you to transfer files from one environment into another environment.

Change 5: ResourceGetTree not supported

Old Workflow

ResourceGetTree can be utilized to get an entire tree structure - every single subfolder and file.

New Workflow

CHILI publisher Online utilizes a different file system, which means ResourceGetTree is no longer as performant. Instead, ResourceGetTreeLevel with level set to 1, must be used it its place. However, the call should be used recursively to go down each level of the tree.