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?

CHILI GraFx is a software as a service platform, which means all hosting and management is done by the CHILI team. For each environment purchased, you are given a URL to access those environments.

On the backend, the product is quite different as we build it to utilize the maximum out of the Azure platform. Therefore, CHILI GraFx will be the most performant experience of CHILI publisher.

Will you also act as an IIS server?

When it comes to IIS, we are not providing a server. CHILI GraFx differs greatly from the traditional Windows server setup. Behind the scenes, CHILI is running on an Azure platform and is structured differently.

Don't worry though, for the frontend, API, and most workflows, the experience is the same.

Instead, you are given a URL for each environment (with properly setup SSL). Your template designer, integrators, and your web applications will use that URL to communicate with CHILI GraFx.

How do I transfer my data?

Transferring data from an on-premises version of CHILI is done using a tool called AZCopy. A URL is given to your team, and the tool will securely transfer all files to that URL endpoint. You can read more about the technical details here: Transferring Data

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

Yes, the transfer is a 1:1 transfer for each environment so IDs, users, settings, etc. will be the same after the transfer.

How do I access my environment?

A URL on a subdomain of chili-publish.online or chili-publish-sandbox.online will be created for every environment purchased in your contract.

So for example, the customer success team has a production environment at

https://ft-nostress.chili-publish.online

and a sandbox environment at

https://ft-nostress.chili-publish-sandbox.online

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.