Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Customer state v Session state
1. CustomerState vs. SessionState
CustomerState is information associated with an individual mobile user. It should be used to store
permanent information associated with a mobile user, such as their name, their home address, and
other bits of information that is unique to a user and relevant to your eTXT application.
SessionState is information that is temporary, and lasts for approximately 60 minutes since the last
time a user responded to a message from your application. It should be used to track temporary
information that is only relevant for a particular “conversation” between the application and a
mobile user. Examples include the current page in an SMS “wizard”, as well as information
previously collected as part of that dialogue.
SessionState explained
Have you ever left your web-browser open on a secure page for a while not doing anything.....Then
you go back to it and click a link and it says "Sorry, your session has timed out please login again"?
A session in the eTXT API works in the same way. When 60 minutes have passed since the user last
interacted with an application, the system ends their session. When this expires, any temporary
information – such as where you were on a web page, the contents of your shopping cart, and other
temporary information, is gone.
Session information will be passed in the sessionstate member of the request object passed to your
application.
CustomerState explained
CustomerState is like the information that exists after you have logged into a web site. This
“permanent” information would include things like your name, your mailing address, and your credit
card details…something that should remain the same across multiple computers and browser
“sessions.”
CustomerState information in the eTXT API is information that will always be sent to the callback
URL irrespective of which session is currently active. It will be passed in the customerstate member
of the request object passed to your application.
2. Example JSON Code 1
This example demonstrates setting the customer state. Customer state, once set, will cross session
boundaries, and be sent each time until changed. This demonstrates a theoretical restaurant service
which finds restaurants near to a particular street location. It is triggered by sending #restaurant to
30000
Request 1
…HTTP Headers…
{
"customerstate":null,
"id":"09883dc9-a90c-4bb6-b71f-73e94a56e618",
"msg":"#restaurant",
"sessionstate":null
}
Response 1
…HTTP Headers…
{
"customerstate":null,
"id":"09883dc9-a90c-4bb6-b71f-73e94a56e618",
"msg":"Hello, what is your name?",
"sessionstate":null
}
Request 2 (continuation of session)
…HTTP Headers…
{
"customerstate":null,
"id":"09883dc9-a90c-4bb6-b71f-73e94a56e618",
"msg":"John",
"sessionstate":null
}
Response 2
…HTTP Headers…
{
"customerstate":”John”,
"id":"09883dc9-a90c-4bb6-b71f-73e94a56e618",
"msg":"Hello John, Reply with your street address",
"sessionstate":null
}
3. Example JSON Code (new session)
This shows use of session state, which is a temporary store of information that lasts for around 60
seconds. It also shows the persistence of customer state, which is passed again to the application
URL because it was set in a previous session. As before, it is triggered by sending #restaurant to
30000
Request 1 (new session)
…HTTP Headers…
{
"customerstate":”John”,
"id":"09883dc9-a90c-4bb6-b71f-73e94a56e618",
"msg":"#restaurant",
"sessionstate":null
}
Response 1
…HTTP Headers…
{
"customerstate":”John”,
"id":"09883dc9-a90c-4bb6-b71f-73e94a56e618",
"msg":"Hello John, what is street address?",
"sessionstate":null
}
Request 2 (enter street address)
…HTTP Headers…
{
"customerstate":”John”,
"id":"09883dc9-a90c-4bb6-b71f-73e94a56e618",
"msg":"7172 Hawthorn Ave",
"sessionstate":null
}
Response 2
…HTTP Headers…
{
"customerstate":”John”,
"id":"09883dc9-a90c-4bb6-b71f-73e94a56e618",
"msg":"What is your city?",
"sessionstate":”7172 Hawthorn Ave”
}
