Skip to main content
Via the ASSE interface (Asynchronous Server-Side Events), arbitrary data can be transmitted asynchronously from the shop via HTTPS to external systems (e.g. newsletter, search, or tracking services). The transmission takes place on the server side (shop server → recipient server) and independently of the client. There is no classic API endpoint that is “called” externally. Instead, a configured event in the shop is triggered, which executes an asynchronous HTTP request to a defined target URL.

​
Provision in the shop

The ASSE interface is a standard part of every WEBSALE shop and can generally be used. OR ASSE must be enabled/activated in the shop (optionally per subshop).

​
How it works

  • The transmission takes place on the server side from the shop server to the recipient server (not from the client/browser)
  • Communication takes place exclusively via HTTPS
  • The execution is asynchronous: triggering does not block the shop process, even if the target system does not respond
  • Multiple events/targets can be configured
  • For each event, the transmission can be carried out via an HTTP request with a different method (e.g. GET/POST/PUT)

​
Event configuration

Any number of events can be configured for the ASSE interface. Each event is uniquely addressed via an event ID (this ID is used when triggering). The configuration is done via the configuration node general.asse

​
Use in templates (brief overview)

In templates, the module $wsAsse is available. With $wsAsse.fire(<eventId>, <data>), an event is triggered and an asynchronous HTTP request is executed based on the stored event configuration.
  • Return: true if the event was successfully triggered; false in case of configuration problems. However, true does not mean that the request has already arrived successfully at the recipient (asynchronous).
  • data is not URL-encoded (must be done manually if needed)
  • If a list or an object is passed, it is converted as JSON

​
List configured events (determine event IDs)

If the event ID is not known or you do not want to look into the configuration. 
{{
  foreach $event in $wsAsse.asseConfigs:
    print $event.id;
  /foreach
}}

​
Trigger event (fire)

An event can only be triggered if it was previously created in the configuration general.asse.

​
Example

{{
  var $eventData = "userid=" + $userAccount.id;
  var $triggered = $wsAsse.fire("myevent", $eventData);
}}
  • A payload is built: userid=<ID of the logged-in user>
  • The configured event myevent is triggered
  • The return value true only means: the event was triggered — not that the HTTP request was already successful at the target.
  • $eventData is not automatically URL-encoded (so special characters/spaces, for example, must be encoded yourself beforehand if needed)
  • Depending on the configured HTTP method, $eventData is transmitted as part of the URL (e.g. with GET) or as a request body (e.g. with POST/PUT/PATCH) (according to ticket text)
For more information, see the module reference $wsAsse.

​
Success criteria, retries, and timeouts

Since the transmission is asynchronous, transmission errors are not necessarily immediately visible in the shop. In order for the delivery to be considered “successful”, check mechanisms / conditions can be defined (e.g. HTTP status code, content type, or response contents). If conditions are not met, retry attempts with delay and timeout are carried out — depending on the configuration.

​
Log manager

Content to follow.