Concepts

What OFML data is

European furniture manufacturers publish their ranges as OFML data. It is not a price list and not a product feed. It carries the option groups, the dependencies between options, the finishes, the prices and the 3D geometry, which together mean something a feed cannot express: whether a given combination is actually buildable, and what it costs.

That distinction is the whole reason this integration exists. A shop variant system can store twelve option groups. It cannot know that choosing one arm height rules out two of the base options, so a webshop that rebuilds the product by hand will happily sell something the factory cannot make.

Two things follow, and they decide whether any of this applies to you. The manufacturer has to publish OFML data at all, and they have to have shared that catalogue with your account. Both are their decision, not ours and not yours. If you are unsure, that is the first thing to find out, because nothing else matters until it is answered.

pCon.ui and pCon.basket

Both are EasternGraphics products, both configure the same OFML data, and they are not interchangeable. Licensing one does not give you the other.

pCon.ui is the configurator that runs in a visitor's browser on a page you own. It serves anonymous visitors, which is exactly what a webshop needs, and it is authorised by which domains are allowed to embed it. This is the product behind the webshop side of pconnector.

pCon.basket Online is the full configuration and quoting environment your sales people probably already use. It is licensed per named user and refuses anonymous sessions, so the number of seats you license is the number of people who can configure at the same time. This is the product behind the ERP side.

Everything else in this manual splits along that line. The webshop side has a catalogue import, a domain whitelist and a cart. The ERP side has none of the three and has a login and a seat instead.

What a gatekeeper is

A gatekeeper is your instance of a pCon product: a configuration held at EasternGraphics that decides which catalogues you see, in which currency, with which tax treatment, whether anonymous visitors are allowed, and which domains may embed it. It is identified by an id.

Practically, it means the configurator on your product page is not a generic tool pointed at your data. It is your instance, with your catalogue and your prices, rendered inside your page. Two customers with the same manufacturer see different prices, because they have different gatekeepers.

A gatekeeper id is not a secret in the way a key is, but it is also not public information you should scatter around: it identifies your licence. In this integration it is held centrally per customer and composed into the configurator URL when the page renders, which is why changing instance is an edit in one screen instead of a migration across every product.

An instance is also either a shop instance or a lead instance, and EasternGraphics decides which when they set it up. A shop instance ends in add to cart: the configuration is posted to your shop and becomes an order line. A lead instance ends in a request: the visitor fills in the form inside the configurator and EasternGraphics passes the request to you. One instance does one of the two and never both, and only EasternGraphics can switch it. Your portal reads which one you have straight from them, so this is something you can check rather than assume.

The domain whitelist

The browser configurator is authorised by domain. EasternGraphics keeps a list of the domains allowed to embed your instance, and a page on any other domain is refused.

Three things about that list are worth knowing before you plan an onboarding, because all three regularly surprise people:

• It is maintained by hand, on request. It is not a field you can edit yourself, and it is the one step in the whole process that waits on someone else
• There are no wildcards. Every subdomain is a separate entry, so your staging host and your live host are two requests, not one
• You get a live domain plus two development domains. That is enough for most setups and tight for some, so plan which three before you ask

There is no error message designed to tell a visitor what happened. A page on an unlisted domain simply does not get a working configurator, which is why a whitelist problem so often reads as a bug in your own page. The portal reads the real list back from EasternGraphics, so you can check what is actually on it instead of guessing.

The two separated worlds

This is the part a competent agency asks about first, and the honest answer is short: the catalogue import and the configurator are two separate channels that never share a credential.

The import runs from your server to ours and carries a key issued to you. That key never reaches a browser, because nothing in the browser ever needs it. The configurator runs in the visitor's browser and carries no key, because it is authorised by the domain it is embedded on. And the step where the two meet, adding a configured item to the cart, is a request your own shop receives, verifies and only then acts on.

The practical consequence: a key that leaks cannot be used to configure, and a page that is scraped yields nothing that opens the catalogue. There is no single credential whose loss hands someone the whole integration.

Who supplies what

Four parties, and the onboarding goes wrong most often when two of them each think the other is arranging something.

The manufacturer publishes OFML data and decides whether your account may see their catalogue. Nobody else can grant that.

EasternGraphics licenses your pCon instance and maintains the domain whitelist. You hold that licence directly with them or through your distributor. We do not resell it, and we are not their partner or their reseller.

pconnector is the layer in between: it talks to the catalogue on your behalf, hands your shop or ERP the settings it needs, and ships the adapter that does the platform-specific work. It holds your settings and your keys, and it never holds your pCon credentials inside your shop or your ERP.

You, or the agency that maintains your platform, install the adapter, run the import, and decide how the configurator sits on the page. Most of this manual is written for whoever that is.

What counts as a connection

A connection is one shop or one ERP on one domain. It is also the unit that gets invoiced, which is why it is worth being precise about.

A key is issued for a specific site and is refused from anywhere else. A request that reports no site at all is refused too, because otherwise leaving the field out would be the way around the rule. That makes a key useless to copy into a second shop, which is the point: one breach should not be every shop's breach.

Test and staging environments are connections as well, and they are free when they are registered as such. Register them rather than pointing a staging site at a live key: a key shared between environments is the thing most likely to end up in a public repository.

Language lives in two places

This one causes more confusion than anything else on the list, so it is a concept and not a footnote.

The catalogue import follows a language chain on our side: a list of languages tried in order until one answers. The configurator follows the language of the page it is embedded in. Those are two different settings, and leaving them unequal means the shop shows one language while the configurator shows another.

There is a second trap inside the first. The chain does not fall back per field. If you ask for one language and the manufacturer does not ship it, you do not get a partly translated article: you get the article number and no features at all, while the price and the render still look perfectly fine. That is why a failed import so rarely looks like a failed import. Not every manufacturer ships every language, so this is something to check before onboarding a brand rather than after.