一、SmartBI会话机制
在日常使用SmartBI时是否遇到过"尚未登录或会话已超时"的提示框，是否疑惑为什么会出现这一个问题。这里我们来解读一下SmartBI的会话机制，在系统集成时我们也需要围绕SmartBI的会话机制进行开发。
1、会话超时的控制者
SmartBI的请求都是有状态的请求，请求状态由中间件（Tomcat、weblogic、WebSphere等）的session机制进行管理和存储，所以请求登录状态的保持实际上受到服务器中间件的控制，中间件的session保留时长由smartbi.war\WEB_INF\web.xml中的“session-timeout”属性进行控制，以tomcat服务器为例，具体位置如下图，如下的配置会在用户不操作5分钟之后出现会话过期，即会话超时。
 
2、SmartBI会话保持机制
为了避免用户长时间未操作后继续操作时出现的会话丢失问题，当我们浏览器访问SmartBI完成登录之后，且不关闭SmartBI界面的情况下，SmartBI会每隔2分钟会自动发起一次noop.jsp的请求来刷新会话超时的时间，这样就能不断的保持住SmartBI的会话，理想情况下会话永远不会超时。
3、会话超时扩展包
若依旧希望用户的会话到达一定时间后超时，如半小时未操作则让用户重新登录，这类需求则需要使用autologout.ext（10.5.15版本及以后，产品已内置会话超时扩展包）扩展包来进行处理。
旧版本（V10.5.15以前的版本，不包含V10.5.15）：
手动添加扩展包后，默认不操作的情况下5分钟就会出现超时，如需修改超时时间，可修改smartbi.war\WEB_INF\web.xml中的“session-timeout”属性，可将SmartBI会话超时时间延长，比如设置30，则表示会话可保持30分钟，30分钟后自动超时。
新版本（10.5.15版本及以后）：
在系统选项的用户管理中默认就有一个会话超时的配置项，在启用会话超时的情况下，到达指定的时候后就会出现超时
二、"尚未登录，会话超时"是如何产生的
前端会话超时场景
1、会话冲突
（1）应用服务器会话存储原理
应用服务器是会话（Session）的存储与标识逻辑如下：
服务端为每个会话创建一个Session 对象，存储在服务器内存中。
每个 Session 有一个唯一的 Session ID。
服务器通过 Cookie 将这个 Session ID 返回给客户端，默认的 Cookie 名称在 Java 技术栈中是 JSESSIONID。
会话冲突的根本原因是：浏览器中 Cookie 的存储和发送在多个系统、多会话之间互相冲突、覆盖。而如何让浏览器存储正确的Cookie，我们需要先了解一下Cookie的关键特性。
同域名共享：同一域名下的不同路径、不同端口（部分情况）共享 Cookie。
同名覆盖：同一个域名下，相同名称的 Cookie 会被后来的覆盖。
自动发送：浏览器在请求该域名时会自动携带该域名下所有匹配的 Cookie。
2. 会话冲突重灾区
（1）同时集成相同域名不同端口的SmartBI系统
冲突点原理：
如果多个 SmartBI 部署在同一个域名下（如同一域名不同端口但浏览器视为同源），它们的 JSESSIONID Cookie 是相同的，就会导致冲突。浏览器不会将端口作为区分条件。
现象表现：
- 用户访问A系统（ http://smartbi.com.cn:8080/smartbi ) 完成登录，同时又在当前浏览器访问B系统（ http://smartbi.com.cn:8888/smartbi ) 完成登录
此时再切回 A 系统操作时，请求携带的是 B 系统的 JSESSIONID。
A 系统服务器找不到这个 Session ID，就会出现会话超时要求用户重新登录。
（2）登录多个用户后登录用户覆盖前面登录用户的会话
冲突点原理：
对于一个系统而已 JSESSIONID Cookie 是相同的，多个用户登录时后登录的用户持有的新cookie会被存储到JSESSIONID 中，虽不会提示会话超时，但是可能因为用户权限不同，导致访问时出现无权限提示等异常现象。常出现在用户登录后又访问share.jsp的公共连接（公共连接默认会使用公共用户登录）。
现象表现：
- 使用同一个浏览器用户使用管理员用户访问了系统，然后又访问了公共连接
- 再切换回到管理员访问系统的页签时，可能会出现资源数资源加载不出来、操作时时出现权限异常，都是会话被覆盖的体现
（3）集成时同时登录相同用户或不同用户
冲突点原理：
与冲突点2类似，同时登录时会导致后面的会话覆盖前面的会话，如果在短时间内被覆盖，就会导致部分资源正常部分不正常甚至全部异常的现象。
现象表现：
- 如下代码中登录时都拼接了&user=admin&password=admin此时集成时每个链接都会创建一个会话，导致会话冲突最终全部跳转到登录页面。
 
3、浏览器跨域问题
由于SmartBI的登录状态依赖于应用服务器的会话管理，在客户端浏览器则是通过cookie来存储会话信息，若使用ifarme集成SmartBI资源时则需要注意浏览器跨域问题，由于浏览器不支持跨域传递cookie，此时就可能导致SmartBI一直处于未登录的状态，导致集成失败。解决跨域问题可以参考：单点登录 - 单点登录集成通过谷歌浏览器80版本及以上访问SmartBI报表，有时会跳转到SmartBI登录界面
后端会话超时场景
1、SDK版本与SmartBI版本不一致
第三方系统后端集成调用SDK的类时，基本上都需要ClientConnector类来创建会话，当使用不匹配当前SmartBI版本的SDK包时就有可能会以为逻辑不一致导致会话超时。所以集成时一定要保证SDK版本与SmartBI版本一致。
2、HTTP请求调用时接口执行时间过长导致超时
不同语言的系统集成SmartBI后端的SDK接口时，往往会采用HTTP请求的方式来调用，当发起http请求完成登录获得http session之后，由于没有进行会话保持，理想情况下当前的会话只会保持5分钟（服务器配置的超时时间）。此时如果基于当前会话顺序调用耗时较长的接口时，就可以会出现会话超时的问题，或者是将会话存储起来后处理逻辑后再调用bi接口时也可能出现会话超时问题。
如下代码片段，拿到会话后进行存储，调用其他的系统逻辑耗时较长超时超时时间，后续再调用SmartBI的接口，此时会话在SmartbBI务器上已经超时，再调用就可能出现尚未登录会话超时的问题。
三、如何正确使用会话机制
1、前端集成
（1）集成隐藏的index界面，实现会话保持
在面对频繁打开SmartBI的资源的场景时，在第三方系统和SmartBI系统完成单点登录后，即可在集成系统上添加ifarme标签，并设置路径为SmartBI的index界面，只要当前页面不关闭，SmartBI的会话就能一直保持，且不影响正常的业务，伪代码如下。
处理后从网络请求中可以看到集成系统上能看到其定时发送是noop.jsp的请求，效果如下图
（2）会话存活检测
通畅情况下，集成系统使用的会话机制和SmartBI的并不一定完全相同，SmartBI使用是应用服务器会话是有状态的会话，部分系统如果使用无状态的会话机制，由于机制不一样会比较容易出现会话超时问题。
要保障会话机制不一致导致的超时场景下能正常打开集成资源，可以定时检测会话状态，当会话状态异常时重新获取会话，判断会话状态可以使用UserService的isLogged方法处理。
（3）资源打开时校验
在实际的场景中集成系统可能没有接口支持集成SmartBI的index界面，这个时候也可以在每次打开资源的时候都进行登录校验，若未登录的情况下则进行进行登录后再访问资源，这种做法适用于即开即关，且打开资源的操作不频繁的时候使用。
（4）完整实现思路总结
思路1：
该集成方案核心思路是采用“隐藏iframe会话保持 + 定时会话检测”的双重机制，隐藏iframe解决了常规浏览场景下的会话保持问题，而定时检测机制则针对性地解决了网络波动或会话机制差异造成的连接中断问题，从而保证了第三方系统集成SmartBI的整体稳定性和用户体验。这种方式常用来解决第三方系统中长时间挂载SmartBI资源的场景，可以尽量的保证长时间不操作后导致的会话断连问题。
思路2：
若第三方系统没有接口可以支持集成隐藏的index界面，也可以每次用户点击访问 SmartBI 资源的时候进行登录状态校验如果未登录，则在后台完成登录流程，然后再跳转至目标资源。也建议在此基础上添加定位会话检测的代码，来尽量保证不会出现会话超时的现象。
2、后端集成
在后端集成的场景与前端集成的场景类似，创建会话后同样进行会话保持，SmartBI提供的SDK扩展包中创建会话的 ClientConnector 类中有一个静态内部类会对创建的会话发送noop请求保持会话，所有如果是使用SDK集成的情况下是不需要处理回话保持的场景的。而对于Http请求的场景，则需要实现类似的会话保持场景，实现可以参考如下代码。只需要将使用异步现场不断发送该请求即可进行会话保持。
老规矩，来答题固定下顺带领点麦豆——>点击领取任务 | 
