2.6.2业务详细说明
用户请求访问购买的SaaS软件： 用户请求使用用户购买的SaaS软件时，平台会将用户ID(User_ID), 软件ID(Application_ID), 购买此软件的租户ID(Renter_ID), 防止重传的Token 这4个参数传值提供软件提供商提供的网址。同时将此时生成的Token序列和时间与访问的用户id，软件id一起保存在数据库里,Token的有效时间理应当设为10秒到20秒左右。 SaaS软件访问CheckLogin.aspx 调用免登陆接口： SaaS软件在注册时候会获得一个独有的软件序列号，软件提供商在软件开始运行的代码中加入请求，访问平台判断此用户和本软件是否是合法的软件和用户，SaaS软件应该将软件序列号，时间戳（系统当前时间），请求的接口名，与传送过来的四个值用md5加密生成一个新的sipsign的值，再把sipsign，时间戳，请求的接口名和传送过来的四个值传给平台的CheckLogin.aspx页面请求调用免登陆接口。（如图1-6-2 和 图1-6-3）
图 1-6-2 sipsign验证的生成
图 1-6-3 请求接口的URL
判断请求接口的名称： 请求接口理应当分为很多类型，所以在处理页面上应当做分类处理，当然目前只实现的免登陆接口，但为了以后的扩展这种业务流程上的判断不能少（接口名称的命名规则建议为：公司名.模块名.功能名，这样可以用split做分类操作）。如果不存在此名称的接口，则返回一个错误信息。 获取请求的数据： 根据接口类型的不同，获取不同名称的数据参数。如果获取的某一个数据参数为空，则返回一个错误信息。
判断是否重传： 根据传送过来的Token序列号和用户id，从数据库读出相应的Token记录，并比较Token中的时间与平台上的当前时间是否超出了Token防重传的时间限制。如果超出了防重传的时间限制，则返回一个错误信息。如果根据Token从数据库读不出任何数据，也返回一个错误信息。 Token存取的流程如图1-6-4:
图1-6-4 Token存取流程
判断参数的合法性： 根据传送过来的参数，和平台从数据库读出相应的软件序列号重新做一次sipsign的运算，再将运算结果和SaaS软件传送过来的值做比较，如果相同则合法，如果不相同则返回一个错误信息。
处理接口调用请求，返回结果数值： 通过一系列的合法判断，最后执行接口的处理请求，不同的接口处理方式不同，需要返回结果由’&’特殊字符拼接成一个字符串返回给SaaS软件(也可以返回一个xml)，如果不需要返回结果的，可以返回一个成功信息。(这部分还需要对安全性进行考虑)
2.6.3功能描述
接口的实现主要是针对SaaS软件与SaaS平台之间的关联矛盾。因为用户数据与买卖交易数据都存放在SaaS平台之中。当SaaS软件需要获得买卖此软件的某些合法的用户数据的时候就需要和平台进行一定的交互，此时候就要通过接口来实现此种交互。 目前SaaS平台上只实现了免登陆的接口，免登陆接口实现用户从平台到第三方软件的链接不需要二次登陆，只需要在平台上购买了此软件，则可以从平台上直接登陆第三方软件使用。
接口的种类可以有很多种，如果要扩展的话还可能要有获取购买此软件用户授权的接口，查询购买此软件的用户信息的接口，以及其他等等。
2.6.4用例图
接口模块不存在用例图。
2.7 SaaS软件用户初始化 2.7.1业务流程图
用户在平台登陆选择购买的软件进入SaaS软件调用免登陆接口[用户非法] 提示错误信息，返回平台[用户合法] 判断用户所属租户是否存在[本地数据不存在此租户] 初始化租户信息及相关信息[本地数据存在此租户] 判断用户是否存在[本地数据不存在此用户] 初始化用户信息[本地数据存在此用户] 载入登陆用户的权限，信息使用属于此用户的软件
图 1-7-1 SaaS软件初始化流程
2.7.2业务详细说明
用户在平台登陆： 基于SaaS平台的SaaS软件的用户都是在平台上实现注册登陆的，这样平台上管理多个SaaS软件的时候就可以一次登陆免去多个二次登陆的麻烦。用户在平台通过单点登陆(SSO)链接到SaaS软件上。
选择购买的软件进入： 用户可以拥有多个软件，不同的软件有不同的软件入口地址。
SaaS软件调用免登陆接口： 所有的软件一开始都应当判断进入用户的合法性。 判断用户所属租户是否存在?初始化租户信息： 先查看本地数据库中是否存在与此租户是否存在，如果不存在则需要初始化租户及相关的数据，所谓的初始化租户及相关的数据不止是将租户的信息加入到本地数据库，而且要初始化SaaS软件的默认配置。譬如说SaaS软件本身具有默认的几个角色，但由于SaaS软件的特性是由多个不同的租户使用，不同的租户定义的角色有所不同，但又具有相同的系统默认的角色，在这种情况下就需要在初始化租户的时候初始化SaaS软件的默认配置，将系统本身默认的角色与此租户关联起来。还有一点要注意的是，SaaS软件本地数据库里的租户id就是用户在平台上的用户id,通过这样才能判断平台上的用户是否已经在软件本地里初始化过。
判断用户是否存在?初始化用户信息: 如果本地数据库没有此用户信息，且此用户又是合法的，则将此用户的信息存放在数据库里。如果SaaS软件系统功能上是分角色权限的，则需要把给此用户赋予一个最低的权限，再由系统管理员（即是租户）提升此用户的权限。 载入登陆用户的权限，信息： 当一切判断结束后，如果用户合法且系统初始化信息完毕则用户获得一个具有他在此系统的权限和信息的Session。
2.7.3功能描述
SaaS软件初始化的过程也即是为了解决平台与SaaS软件之间的关联矛盾问题。但不同的是此部分必须要由软件提供者完成，也就是软件提供者需要在用户登陆的时候就需要判断初始化数据(尽管从流程上看很繁琐，但必不可少)。这个初始化的过程可以解决不同租户在软件中配置不同且又都保留系统默认配置的问题。 在初始化的设计我们采用的是一对一的设计方式：
租户1判断初始化租户 判断初始化用户 租户1下的用户1在数据库添加用户数据 租户1下的用户2
图 1-7-2 初始化方式
这种初始化方式即是每个用户就需要经历初始化判断的过程，且只有判断后才能把用户数据添加到本地数据库里。即是一个租户买了软件后添加了用户，租户可以不先登陆，用户可以先登陆（因为所有的用户都会触发初始化过程），然而只有登陆过的用户才能出现在SaaS软件的本地数据库中。这种初始化过程是采用分别初始化，一一对应的方式。（至于基于组织结构方式进行初始化方式，我们在改进的功能点与方案中再进行描述讨论）
2.7.4用例图
此模块无用例图。