Environment and Terminology

AESWebLink will function in any environment where a third party application can launch a web browser session. This is primarily envisioned as a capability that can be added to existing web-based applications that use a web browser for the interface.

Terminology

AESWebLink Enabled Application: An application that has been certified to pass data to and from AESDirect via AESWebLink

End User: User of an Enabled Application

AESWebLink: The application on the aesdirect.gov web server that receives data from the Enabled Application and facilitates transmission to AES via AESDirect.

AESWebLink Interoperability

AESWebLink is to designed provide for two-way interoperability with the Enabled Application. This entails:

• The initial transfer of SED data from the Enabled Application to AESWebLink
• The ability for AESWebLink to link back to the Enabled Application at certain points in the process (see below).

Links back to the Enabled Application are made to return URLs that can be provided by the Enabled Application. If these return URLs are not (or cannot) be provided by the Enabled Application then AESWebLink will be able to accept the transfer of SED data (and allow submission to AESDirect) but will be unable to link the user back to the Enabled Application. In this case AESWebLink will link to default AESWebLink pages in place of the return URLs not passed by the Enabled Application.

Process Initiation

The End User will begin the process by initiating the Enabled Application and then entering the data required by that application. Under the control of the Enabled Application, the End User is given the option of submitting an SED to AES via AESDirect.

The Enabled Application will be in complete control of the method, and execution of this option. When executed, this option will initiate an HTTP POST request to AESWebLink from within the application. This could be accomplished by a hidden html form with the data or any other means the developer of the Enabled Application wishes to use.

The AESWebLink Application Flow

An explanation of the whole AESWebLink Application flow is provided below. While the Enabled Application is not required to have any detailed knowledge of this process it is described here in order to assist the developer of the Enabled Application to better understand the whole submission process. This appreciation should allow the developer to build a logical and user friendly interface process between AESWebLink and the Enabled Application.

The Enabled Application is in control of the placement, and initiation of the AESDirect option (the AESWebLink process) from within their Enabled Application.

Once the AESDirect option has been executed from within the Enabled Application, AESWebLink takes control of the process and the following will occur.

Step 1 - AESWebLink Log-in Process

The user will be prompted for their AESDirect username and password.

If the username and password entered by the user are not valid on AESDirect, the user will have the option of either trying to log-in again, or canceling the login attempt. This cycle will continue until the user either succeeds in logging in or cancels the login attempt. When the user cancels, they will see a page containing a message that the login attempt was unsuccessful and links to AESDirect registration and support.

If the login is successful, AESWebLink will validate the transaction being transfered.

Step 2 - Initial Transaction Validation

The transaction is checked to ensure that all of the data elements required to initiate AESWebLink are present and valid (See AESWebLink API - System Variables and all data elements that cannot be edited by the End User).

• If all required data elements are not present, the user will see an appropriate error message and return back to the Enabled Application using the "unsuccessful Login URL" return URL provided. A return to this URL signifies to the enabled application that the transaction could not be accepted by AESWebLink.
• If all required data elements are present, the user will enter the AESWebLink application.

Step 3 - AESWebLink Application

Once a user has successfully logged in to AESWebLink, a screen will be dynamically built to request any data elements required by AES that were not transferred from the Enabled Application.

The screen will look and function in the same manner as the full AESDirect Application. From this screen the user will be able to:

• Complete any information missing from the shipment.
• Submit the shipment for validation by AESDirect and submission to AES.
• Return to the Enabled Application by way of the "No SED" return URL (wl_nosed_url). A return to this URL signifies to the Enabled Application that the End User was able to successfully log-in to AESDirect, but did not submit the SED to AES.
• Link to the AESDirect Main menu

If the shipment is accepted by AESDirect, the End User will receive confirmation of the acceptance and be returned to the "Success" return URL (wl_success_url). A return to this URL signifies to the Enabled Application that the End User was able to successfully log-in to AESDirect, and also successfully submit the SED to AES.

In addition, the End User will receive an e-mail from AESDirect confirming the response received from CBP AES.

Notes on Processing of Submission Errors

If there is a problem with any data that is submitted to AESDirect, an error message will be displayed and the user allowed to make corrections. The screen will be dynamically regenerated, based upon errors generated from AESDirect, to show the End User data elements that are identified as being incorrect or missing. This could include elements that had been hidden. Elements that are defined by the API as not editable will not be displayed. Once the End User has fixed any errors, they may resubmit the shipment. If there are other mistakes, this cycle will continue until the shipment is accepted or the End User elects one of the links provided (AESDirect Main menu or "No SED" return URL (wl_nosed_url)).

If an error is found in an element that is not editable then AESWebLink will gracefully terminate and the user will be sent to the "No SED" return URL

Notes on AESDirect User Accounts

As mentioned above, AESWebLink End Users are required to have completed the standard AESDirect registration process and have been issued with a standard AESDirect account. Any AESDirect user will be able to access AESWebLink from any Enabled Application on which they have an account. There are no special requirements for users of AESWebLink outside of those for AESDirect, users will have full access to the standard AESDirect web application. Any SED submitted using AESWebLink will be able to be retrieved, inquired upon, and amended through the standard AESDirect web application