Sbo同Add-on插件之间的单一认证(SSO)实现

  SSO:Single Sign On,我通常将它翻译成为单点认证,不同的应用程序之间通过统一的认证技术实现对所有应用的一次性认证,就是说只要通过一次性登录确定为有效的用户,就可以获得在支持SSO认证的业务应用和业务模块中的相应的操作权限。

  这种业务要求很现实,看起来也要求的很简单,嗯,也许应证了那句话:最简单的才是最复杂的。面对这不同的软件提供商,不同的数据接口和数据库支持的应用程序要实现这一目标,不是一件容易的事情。

  好在Sbo Add-on插件是基于Sbo SDK进行开发的,从而能够很好的实现Add-on与Sbo主程序之间的统一认证。这事情说起来可能让人觉得太小case,不过,试想一下:您的Sbo系统实施顾问帮您建设完成了Sbo构架,但是Sbo框架下的复杂业务处理可能需要进行二次开发,比如物流,比如人力资源,比如中心仓库管理,比如生产调度管理,都可能需要二次开发。企业内部支持人员完成了一部分业务的开发,而更为复杂的业务可能因为支持人员的精力局限,需要联合企业外部人员或者软件提供商进行开发,这样,尽管都是运行在Sbo主程序之内,但是却包括了SAP提供的主程序、企业内部人员开发的业务模块以及企业外部单位协助开发的业务管理模块。这些模块集成在一起,统一管理者企业业务信息的管理。他们需要统一的业务审计、权限控制,就是说,Sbo SSO很有必要。

  感谢SAP,您不需要特别的考虑怎样使用特别的技术和技巧来完成Sbo与Add-on插件之间的SSO,只要按照Sbo Add-on插件编写规范,就可以容易的实现Sbo主程序、来自不同人员编写的Sbo Add-on插件之间统一的一次性认证。

  那么,在Sbo Add-on插件程序编写中,是通过怎样的程序来实现Sbo同Sbo Add-on插件程序之间的单一认证的呢?

  Sbo Add-on插件通过以下三个步骤之后,就实现了插件同Sbo主程序之间的SSO:

  1、通过UI API SDK获得当前正在运行的Sbo主程序。

 SAPbouiCOM.SboGuiApi sboGuiApi = new SAPbouiCOM.SboGuiApi(); string strConnection = ">null; strConnection = System.Convert.ToString( Environment.GetCommandLineArgs().GetValue( 1 ) );     // 连接到当前运行的Sbo主程序 try {   // 如果没有发现传来的参数,就失败  sboGuiApi.Connect( strConnection ); } catch { // 连接失败   System.Windows.Forms.MessageBox.Show( “没有发现正在运行的Sbo主程序。" );   System.Environment.Exit( 0 ); } // 获得一个初始化了的应用对象 SBO_
Application = sboGuiApi.GetApplication( 0);

  2、设置Add-on插件发生业务数据的环境在现行Sbo主程序的环境下。

 String str
Cookie, strConnectionContext;   // 先初始化公司对象 oCompany = New SAPbobsCOM.Company();   // 通过DI API获得连接环境上下文 cookie strCookie = oCompany.GetContextCookie();   // 使用获得的Cookie,通过UI API检索连接环境字符 strConnectionContext = SBO_Application.Company.GetConnectionContext(strCookie);   // 设置Sbo登录环境之前,确信公司数据库处于未连接状态 if (oCompany.Connected) oCompany.Disconnect();   // 为DI API设置连接环境信息 oCompany.SetSboLoginContext(strConnectionContext);

  3、建立Add-on插件到Sbo现行主程序的公司数据库的连接。

   // 确信公司未连接   if (oCompany.Connected) oCompany.Disconnect();     // 建立到公司数据库的连接   oCompany.Connect();

  只要按照以上的步骤来编写您的Add-on插件,就可以实现Sbo主程序同DI API、UI API SDK开发的Add-on插件程序之间的单点认证,而注册之后的Add-on插件也可以纳入到Sbo主程序统一的权限管理范围之列,从而成为Sbo业务管理的一个部分,实现了完美的统一权限管理、单一认证管理。

  本文出自 “富盛软件” 博客,请务必保留此出处http://foresun.blog.51cto.com/221037/41315

时间: 2024-09-30 22:02:19

Sbo同Add-on插件之间的单一认证(SSO)实现的相关文章

jquery插件-ztree插件中怎么单一修改某一节点的样式?

问题描述 ztree插件中怎么单一修改某一节点的样式? 如题,刚接触ztree,不知道怎么修改它的样式,不是去css文件里直接修改吧? 解决方案 view配置节点的fontCss来控制 function setFontCss(treeId, treeNode) { return treeNode.id==121 ? { color: "red"} : {}; } var setting = { view: {fontCss: setFontCss}, //...其他配置 }

tomcat javaEE 和tomcat插件之间必须配套是吗,我弄了以后不能用

问题描述 tomcat javaEE 和tomcat插件之间必须配套是吗,我弄了以后不能用 jee-luna-SR2能用哪个tomcat 和哪个插件 tomcat7.0.65. 插件tomcatPLuginV321 解决方案 一般来说插件肯定有推荐版本的(比如1.0版本以上),版本不配套,可能用不了. 解决方案二: 在哪下配套的tomcat

在C#程序中实现插件架构

程序|架构 原文作者:Shawn Patrick Walcheske 译者:电子科技大学 夏桅 [引言] 在.NET框架下的C#语言,和其他.NET语言一样提供了很多强大的特性和机制.其中一些是全新的,而有些则是从以前的语言和平台上照搬过来的.然而,这种巧妙的结合产生了一些有趣的方法可以用来解决我们的问题.这篇文章将讲述如何利用这些奇妙的特性,用插件(plug-ins)机制建立可扩展的解决方案.后面也将提供一个简要的例子,你甚至可以用这个东西来替换那些已经在很多系统中广泛使用的独立的程序.在一个

C#插件构架实战

C# 插件构架实战 Jack H Hansen [ 2004-07-27 ] Keywords C# 插件 反射(System.Reflection) 属性(System.Attribute) 一.引言 1. 问题的引入 假设你设计的程序已经部署到用户的计算机上,并且能够正常运行了.但是有一天,用户打来了电话--他们要求增加新的功能.确定了用户的需求后,你竟然发现原有的软件架构已经无法胜任新增任务的需求--你需要重新设计这个应用了!但问题是,就算你又用了一个开发周期完成了用户需要的应用,却不能保

ESFramework使用技巧(2) - 在插件中使用NHibernate

我们来讨论一下这种情景,你采用基于ESFramework的4层架构进行应用开发,你分析用户的需求,并将其分类整理为几大块,考虑每一块使用一个功能插件来完成.在这几个插件中,有个插件需要访问某个数据库,并且只有这个插件需要访问这个数据库,根据插件的"自治"性质,你不想将本插件中的数据访问"上升蔓延"到应用程序(FS),而是让它"仅仅"在本插件中,这样,无论是对FS还是插件都是有好处的--FS自己不需要访问数据库(日志记录除外),插件"自治

.NET插件系统(三) 插件间通信问题——设计可自组织和注入的组装程序

一.  问题的背景        动态系统的要求之一,是不同模块可以根据自身需求自动组装,这往往通过配置文件或用户选择进行.  这个基本问题在前面的文章中已经讲述过了.        但新的问题来了,我们定义了不同的插件A,B,C,那么,不同插件之间的通信如何进行? 如果系统本身的框架非常明晰而且不易更改,那么面向固定接口的方法是最简单方便的. 这也是大部分插件系统在"主结构"上使用的做法. 但是,如果系统框架本身非常易变,连他们之间交互的接口都会随着问题的不同而不同.这就好像,系统中

ESFramewor使用技巧(2)-- 在插件中使用NHibernate

    我们来讨论一下这种情景,你采用基于ESFramework的4层架构进行应用开发,你分析用户的需求,并将其分类整理为几大块,考虑每一块使用一个功能插件来完成.在这几个插件中,有个插件需要访问某个数据库,并且只有这个插件需要访问这个数据库,根据插件的"自治"性质,你不想将本插件中的数据访问"上升蔓延"到应用程序(FS),而是让它"仅仅"在本插件中,这样,无论是对FS还是插件都是有好处的--FS自己不需要访问数据库(日志记录除外),插件&quo

ESFramework介绍之(29)―― 插件公共设施 AddinUtil

    (本文适用于 ESFramework V0.2+)    不知你是否还记得,前面我们讲过,ESFramework规定了插件有如下特点: (1)一个插件是一个独立的物理单元.它可以独立的提供一项完整的服务(功能),而不需要依赖于其它插件. (2)插件能自我描述 ―― 插件的所有对外的发布信息都由插件自己内部提供,而不依赖于外部文件或注册表. (3)插件能自我管理 ―― 插件如果需要配置信息,则插件自己能读取和修改配置信息,而不是框架来完成这些事情.(4)插件自我独立   ―― 一个插件不得

ESFramework介绍之(26)-- 支持复杂插件(InnerDealer 和 InnerDispatcher)

    (本文内容适合于 ESFramework V0.2+)    通常,最单纯的情况是一个插件对应某一特定类型的功能请求,但是,在有的应用中也会出现这样的情况,有多种类型的功能请求相互关联.并且可能交叉,如果是这样,对应每种类型的请求都开发一个插件可能会非常困难,因为这可能会牵涉到插件之间的相互引用/访问,这违背了插件的"自治"性.最好的办法还是将它们放在一个插件中,通过ServiceItemIndex(你一定还记得消息头定义中除了ServiceKey外还有个ServiceItem