Skip to main content
With an Asynchronous Server Side Event, the shop sends data to an external system without waiting for its response. Page rendering continues, and the transfer takes place in the background. Only two tags are needed in the template for this: ASSE-Fire() triggers an event, ASSE-LastErrorCode tells you whether it worked. Guide: Asynchronous Server Side Events

​
What actually happens when an event is triggered

The tag does not send the data itself. It stores the event as a file in a spool directory, and a separate process delivers it from there, with retries if the recipient cannot be reached. This has two consequences for template work:
  • Page rendering is not held up, even if the target system responds slowly or not at all.
  • The template does not learn whether the transfer was ultimately successful. ASSE-LastErrorCode only reports whether the event could be accepted and stored at all.
These tags are therefore not suitable for feedback to the visitor. They are intended to notify another system, not to fetch a response.

​
Prerequisites

Three things must be in place before an event can be triggered at all: An entry in the <ASSE> section defines, among other things, the ID under which the event is addressed in the template, the recipient’s address, the HTTP method, the name of the payload parameter, the content type, and the conditions under which a response is considered successful. Reference: Section ASSE

​
Triggering an event

The tag itself outputs nothing. It only triggers, and can therefore only be used as a single tag, but in all templates.

​
ASSE-Fire()

Triggers the event with the specified ID and passes it the specified data. Both parameters support tag-in-tag, so the data can be assembled from other tags.
Both parameters are mandatory. If the second is missing, the tag is invalid and triggers nothing. If no content is to be sent, explicitly pass an empty value instead of omitting the parameter.
The tag triggers on every page render in which it appears. Therefore, wrap it so that it only takes effect in the desired case, for example on the order confirmation page only if an order has actually been placed. Otherwise, a page reload by the visitor triggers the event a second time.
In the payload, watch out for characters that have a meaning in the tag itself. Otherwise, a comma in the payload separates parameters that are not meant to be separated.

​
Checking whether it worked

​
ASSE-LastErrorCode

Outputs the result code of the most recently triggered event. As an area tag, it applies if an error has occurred.
As a single tag, ASSE-LastErrorCode always outputs a number, 0 in case of success. Therefore, only use it within the bracket. Otherwise a lonely 0 appears on the page.
The tag only ever holds the result of the most recently triggered event. If you trigger several on one page, check each one individually directly after its ASSE-Fire(), otherwise you only see the last result.

​
Meaning of the codes

Not every error is a case for WEBSALE support. Some of them originate in the template itself.
Code 4 is the most common and also the one you can fix yourself. It almost always means a typo in the ID or an entry that is still missing in shop.config. First compare the spelling in the tag with that in the <ASSE> section.
Codes beyond this list concern writing the event file and are a case for your WEBSALE contact person.
  • Guide: Asynchronous Server Side Events
  • Guide: Exchanging data with external systems
  • Reference: Section ASSE