IBM WebSphere Commerce represents the state of a user session using cookies. To understand the synchronization of a users state across both systems you need to understand how those cookies may flow through the system. Take a closer look at Figure 5.10, “Content-led integration scenario with cookies”. In addition to the request flow, the dashed green and blue arrows represent the flow of cookies.
You can see that cookies may flow nearly everywhere. No matter where a request starts and where it ends, either between the browser and the CAE or between the CAE and the WCS, every node may be the source as well as the receiver of cookies.
Two things that need explanation. First, two kinds of cookies flow from the browser to the CAE, cookies which were originally created in the commerce system and cookies that are created by the CAE. This is necessary because the CAE must send the commerce cookies to the commerce system as part of its back-end calls. Second, for fragment requests (labeled with 6), no CoreMedia cookies are needed, hence, the browser does not need to send the CAE cookies to the commerce server.
Hence, CoreMedia had to answer the following questions:
How can the CAE render fragments without the need to receive its own cookies?
How can the user's browser be enabled to send cookies received from the commerce system to the CAE?
How can the CAE be seen as the source of WCS cookies without actually creating them by itself?
How can the CAE synchronize its own user session with the one of the commerce system?
The following section will answer all four questions.
 |  |  |
 |