本人编写的《Sbo维护与开发助手软件》--《Sbo 2005B数据结构与业务对象分析软件》--推出后,得到了大家的喜欢和支持,一些朋友也希望本人就软件的使用技巧提供一些文档。最近几天比较忙,就先就大家可能忽略的一些地方,给大家提个简单的说明吧。 1、数据表结构全中文分析:这个功能很容易理解,属于本软件中最简单的功能部分。在这个功能模块中,值得注意的包括以下几个方面: 搜索技巧。搜索包括按照表名搜索和按照数据表描述搜索:按照表名搜索时,只能输入大写字母,定位到从当前行开始之后的第一个左匹配的数据表,如果到了列表中的最后一个就从头再次搜索;按照数据表描述搜索定位时,支持大小写,并且对大小写敏感,定位算法为全包含模糊查询方式--就是说只要表描述中包含了需要搜索内容的,就定位到指定记录。 有效可选。应该说,这个描述不准确,也正是因为描述不准确,才有必要对其加以说明。先不讨论该怎样翻译,举个例子大家就明白了。在操作SBO时,特别做数据录入的时候,有些字段是通过可选下拉框的方式,要求从下拉框中的数据中选取一个才有效,不允许输入没有再下拉框中出现的数值。对,这样的字段就叫有效值可选字段(我取得名词呀,您懂了就行了)。作为软件开发人员,应该考虑到开发模块同SBO的兼容性和一致性,应该考虑对有效值可选字段提供有效值选择功能。DI API中通过SBObob.GetFieldValidValues(strTableName, strFieldName)来调用,DI Server API使用者GetFieldValidValues 指令来读取有效值选择字段的可供选择值,当然了,调用之前应该选判断这个字段是否具有有效值选择的属性,怎么判断?这个表不是给了答案了吗?的确不能照搬,应该实现程序控制化。 关联字段。说了有效值可选字段,需要明确的是:如果某字段的输入数字来自某个表中的内容,那不是有效性可选,那叫关联,比如INV1中的字段docEntry是个关联字段,关联到OINV的主键。 总结一下:有效性可选字段是在设计软件的时候,由开发人员设计好的,用于标示记录某种状态等属性的,比如发票状态、发票行状态等;关联字段表示两个表之间的数据关系,通常存在主表和子表,主表的主键或者唯一性索引可能作为子表的关联外键。 2、业务对象及其调用全剖析。这个模块应该说也比较容易理解,但是其中有些部分可能会被忽略。 对象标识。您可能根本就没有在意对象标示列下的那些数字,但是它却非常有意义,特别在分析Sbo业务数据的时候。你是否在意过凭证标题和凭证行中的这么几个字段:objType、TargetType、baseType,以及大家打提到的那个用于控制的存储过程SBO_SP_TransactionNotification中的@object_type就是它,维护与开发助手软件列举了所有SBO开放的对象标示,实施上有些对象标示SBO没有开放,在上述的存储过程中可以日志下来进行分析。 对象标示非常重要,熟悉对象标示将大大提高对数据的分析能力。 在数据库中,特别在业务凭证中,objType表示业务对象的类型,targetType表示的是引用此业务凭证的业务类型,baseType表示的是被引用业务的业务类型。 查询主键与参数类型。在DI API和DI Server API中,都提供业务对象的主键查询功能,通过提供业务对象的主键值(注意,主键值往往是唯一性的)检索到一条唯一的业务数据,在DI API中使用的oObject.GetByKey,在DI Server API中通过GetByKey 指令来完成对数据的检索。不管采用哪种方式,都需要传递查询对象的主键对应的参数,业务对象的主键值并不是同一的,比如特价清单处理的主键就需要对应cardcode和itemcode字段,因而调用的时候就需要传递两个字符串参数。表中的查询主键对应的是cardcode,itemcode,对应的数据类型为00。 在DI API开发中查询主键的顺序不容改变,使用DI Server开发的时候,主键是需要填写到QueryParam节点中,不容有错误。 数据类型:0字符型;1数值型;2日期型;3文本型。 查询主键也是维护人员应该了解的,这对分析业务数据有帮助。 不用字段指明本业务对象是否不在中国使用,中国用户可以不考虑不在中国使用的那些业务对象。 点击此处访问原文
__________________QQ:8015656MSN:nostop2do@hotmail.comEMAIL:foresunltd@126.comBLOG:http://foresun.blog.hexun.com
由 nothing2do 于 07-08-25 18:07 最后编辑
注册日期: 2005 May来自: 技术贴数:13精华贴数:1论坛积分:116论坛排名:23672论坛徽章:0
原文刊登在我的博客上,欢迎访问 3、业务对象数据结构全剖析。应该说这个功能主要为开发人员提供的,但是维护人员也可以从中获得帮助。在这这个功能模块中解析了每个业务对象的主键检索条件、数据结构和业务逻辑。在此着重讨论一下QueryParms通数据操纵之间的关系。A、查询参数(QueryParams),指明数据对象的主键字段列表和主键字段的数据类型。既然是主键,那么在数据操纵的时候就必须满足:非空、唯一性。非空意味着这个业务对象在新增数据的时候,这些字段时必须的,并且必须在关联数据表中也是必填的;唯一性意味着在唯一性精确更新修改业务对象的时候,可以通过这样主键字段列表进行唯一性信息确定,从而保障数据操纵的准确性。不管使用DI API或者DI Server API进行开发,SAP不建议通过SQL语句直接对数据库进行维护,而是应该DI API中的业务对象的Add、Update和Remove方法完成对业务对象进行数据操作;在DI Server API中也是通过AddObject、UpdateObject、RemoveObject指令来完成 --当然对于单据对象,可能还存在Close、Cancel操作--对应DI Server API中的CloseObject、CancelObject,也是应该遵循同样的处理规则。相对来说,新增业务对象在DI API中实现较为简单,实例化一个业务对象,然后按照业务对象所提供的字段属性进行赋值,之后通过调用业务对象的Add方法完成新增操作,不过,新增之前,应该对新增数据进行有效性校验,通过GetByKey查询主键是否存在也是有效性检验的其中一项内容,当然也可以直接检查保存后的返回值确定新增是否成功。对于DI Server API也是一样,不过,DI Server指令因为使用XML文档,所以在字段属性的设置上更加灵活。在DI API开发中,要对一个业务对象进行修改、删除、关闭或者取消,一般的,应该先使用业务对象的GetByKey检索出指定的业务信息--从上面介绍中可以看到,这需要使用QueryParams中的对应字段作为检索参数--检索得到的业务数据通过UI界面(可以使Sbo UI SDK开发的UI界面或者自己开发的UI窗口)显示到人机界面上,操作人员对数据进行相应处理后,通过保存或者确定之类的按钮来完成对业务对象的修改、删除、关闭或者取消。在DI Server API中有所不同,首先需要指定业务操纵对象,对应本功能模块上的AdmInfo,比如如果要对特价对象进行处理,需要指明<AdmInfo> <Object>oSpecialPrices</Object> </AdmInfo>。DI Server API开发中,QueryParms对应主键列表就非常重要了,不同业务对象的主键字段列表也对应着数据操纵条件,如oItem的主键是ItemCode,其操纵条件为<QueryParams><ItemCode>myItemCode001</ItemCode></QueryParms>;oSpecialPrices的主键包括两项cardCode和itemCode,对应的操纵条件为<QueryParams><ItemCode>myItemCode001</ItemCode><cardCode>myItemCode001</cardCode></QueryParms>。同DI API不同,因为DI Server的数据操纵指令通过XML格式进行传递,只要保障主键列表的对应关系就可以了,而不需要象DI API中需要严格的参数顺序。当然,对于二次开发人员的自定义函数中是否确定应该做这种要求,那是另外一回事。QueryParams中指定的字段列表作为业务对象的主键字段列表,在业务对象主数据信息表、以及关联字表中都应该具有,它也是我们在系统维护中进行表间数据关联的最恰当字段关联列表。B、业务对象结构。在QueryParams之后,软件列举了业务对象对应的数据信息表以及关联业务子表。通常在QueryParams之后的第一个数据表示业务对象的主数据表,其它数据表同主数据表之间存在着某种业务关联,主信息表同业务子表之间通过QueryParams对应的字段列表进行关联。本功能模块中列举的主信息表和关联信息表中的字段仅仅只能在DI API或者DI Server API开发中使用,在实际的数据库中很多字段并不是此处显示的内容,但是在SDK开发中应该使用这些内容。