Hi Everyone, We have a requirement where we need to Store data in Session O

Hi Everyone,
We have a requirement where we need to Store data in Session Object. I tried to fetch session object but i am getting error while fetching it.
So I tried storing data in servicecontext object using a custom function by using the following methods
sc.setAttribute(attributeName,AttributeValue) and sc.getAttribute(attributeName) . But they are not working as expected.Can any one suggest me how to fetch a session object or Any other alternate approach to store data in a session...

OriginalPostID-81082

OriginalPostID-81082

  Discussion posts and replies are publicly visible

  • Why do you need to store session data? The best practice is to store process info via design. For e.g. using Write to Data Store node etc.,
  • Our project works on multiple database Instances(Say Db1,db2,db3,db4 etc). At home page user can choose the database instance he wants to work using dropdown and then he goes to the application . In the application all the transactions/work is done on the databaseInstance which user has selected. Most of the DB interactions are done using Executestoreprocedure Smartservice.We are storing the database names and their respective datasourcenames in constants. So based on the Database selected we are fetching the runtimedatasource from the constants.
    Now the problem is user wants to open a session and select one database(db1) and simultaneously he wants to open a new session and select another database(db2) and work on both of them at the same time. Initially we planned to store the “Selected database” in user’s custom fields but this approach doesnot work with multiple sessions.
    So we are planning to store the selected databaseInstance in Appian’s session. i hope i make the question clear.
  • I think you've explained the issue you're having already. Using session may not guarantee your scenario.
    Depending on session to manage database connection is not a good design practice in a session independent framework. By that, I mean that the sessions do not dictate the process. The Appian Engines persists data between events/transactions. Your architecture should focus on this feature.

    I suggest that when the user initiates the process, you pass in the preferred database as a parameter and use this within your design. This is the most straight-forward and easy way of handling your scenario. This will eliminate the need to manage sessions and avoid issues that may arise if a session times-out. No matter what session a user is on, the info about the selected database is now held as a process variable and you can use Expression builder to dynamically do operations.
    Hope this helps.
  • We have 3 applications in our project. The database selected in Homepage should be used in all the 3 applications. Each application has several PortalPages/Processmodels. How can we pass the database name as a parameter to every Processmodel?
    Do you mean that ,In all the pages we have to use a common processmodel where user selects a database instance and then redirect to the respective processmodel with database as a parameter? I think this is not possible because client doesn’t want to select a database everytime he navigates to another page/application.He prefers to choose the database only once at login page/homepage.
    Even in User’s CustomFields/Session approach we are fetching database name when the processmodel starts and storing it in processvariable and then passing it to all subprocesses.
    And regarding your “session Independent Framework” comment , I think it wont be a big problem in our project because most of our usecases are like “Searching a particular table(say Contact/claims/XXX) and Performing actions on that table like Add a new xxx/Update XXX/delete XXX” or Importing Zip/sql/dump files to import data into tables or Changing Table constraints like primary key,unique validations etc.What I want to say is there are no tasks assigned to any users and all the processmodels are completed by the initiator himself in a single run. As of now there are no long time running processes and almost all the processes are short(Activity chained with 1 or 2 forms) and are expected to be completed in a single run and are not supposed to be running between multiple logins
  • Have you thought about considering a session as a process instances and using the actions that you allow a user to do - to be done on that process-instance and finally killing the instance (similar to a session)? This will allow you to model things OOTB without having to intercept the session.
  • we are actually redeveloping an existing legacy application(java based) in Appian.Client wants the new application look similar to the old one from frontend(atleast from navigational prespective).The existing appliction is divided into multiple modules(similar to the applications in Appian apps portal ) and in each module(application) we have several tabs(pages in appian) and each tab have several subtabs. As of now we have 3 modules(applications) and in each module we have 5-8 tabs(pages) and in each tab we have 2-8 subtabs.And each subtab corresponds to a particular functionality .All this hirerachy is based on the business functionalities.
    We had already looked into that single parent processmodel (similar to what you have suggested) and expose Individual functionalites as quicktasks but in that approach it is hard to maintain the hirerachy and also it will completly change the navaigation.We are trying to maintain the existing structure as much as possible.So we are trying to find if using session is possible in appian or not.
  • From my perspective it is very questionable to rebuild an application running on a totally different plattform to look&feel the same on Appian. Maybe you try to rebuild the functional processes in Appian and get an application that might be different to the old but is native to Appian and provides greater benefit on the longer run.

    Just my two cents ...
  • I agree with these concerns. Might make sense to have the business speak with an Appian contact to get a better alignment here so that there is a maintainable application that maximizes the benefits of the platform.
  • We are just looking into all possible alternatives (which may keep the original navigation intact) before going with a new design of navigation . I think its better to go with a new navigation. Thanks very much