Your SlideShare is downloading. ×
Customer state v Session state
Customer state v Session state
Customer state v Session state
Customer state v Session state
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Customer state v Session state

657

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
657
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. CustomerState vs. SessionStateCustomerState is information associated with an individual mobile user. It should be used to storepermanent information associated with a mobile user, such as their name, their home address, andother 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 lasttime a user responded to a message from your application. It should be used to track temporaryinformation that is only relevant for a particular “conversation” between the application and amobile user. Examples include the current page in an SMS “wizard”, as well as informationpreviously collected as part of that dialogue.SessionState explainedHave you ever left your web-browser open on a secure page for a while not doing anything.....Thenyou 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 lastinteracted with an application, the system ends their session. When this expires, any temporaryinformation – such as where you were on a web page, the contents of your shopping cart, and othertemporary information, is gone.Session information will be passed in the sessionstate member of the request object passed to yourapplication.CustomerState explainedCustomerState 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 creditcard 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 callbackURL irrespective of which session is currently active. It will be passed in the customerstate memberof the request object passed to your application.
  • 2. Example JSON Code 1This example demonstrates setting the customer state. Customer state, once set, will cross sessionboundaries, and be sent each time until changed. This demonstrates a theoretical restaurant servicewhich finds restaurants near to a particular street location. It is triggered by sending #restaurant to30000 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 60seconds. It also shows the persistence of customer state, which is passed again to the applicationURL because it was set in a previous session. As before, it is triggered by sending #restaurant to30000 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” }
  • 4. Request 3 (enter city)…HTTP Headers…{ "customerstate":”John”, "id":"09883dc9-a90c-4bb6-b71f-73e94a56e618", "msg":"Los Angeles", "sessionstate":”7172 Hawthorn Ave”}Response 3…HTTP Headers…{ "customerstate":”John”, "id":"09883dc9-a90c-4bb6-b71f-73e94a56e618", "msg":"Here are the restaurants near 7172 Hawthorn Ave: …", "sessionstate":”7172 Hawthorn Ave|Los Angeles”}

×