GROUPING PROCESS STRUCTURES IN A SOLUTION MANAGER UNIFIED DIRECTORY

Techniques for managing business process functionality by grouping process structures in a solution manager unified directory (SMUD) include defining a group for a SMUD, the defined group including a group identification (ID) and a plurality of members of the group, each member including a business process structure; defining a plurality of generic functions of the group; receive a request for an adjustment to the plurality of generic functions of a particular member of the plurality of members of the group; and based on the received request, adjusting the plurality of generic functions of members of the group other than the particular member.

DETAILED DESCRIPTION

FIG. 1illustrates an example distributed computing environment100for grouping process structures in a SMUD. For example, in some aspects, environment100may facilitate an option to define SMUD groups that allows for generic group functionality for a variety of use cases. For example, group specific functionality may be provided through an enhancement concept based on inheritance that allows an overwrite of, or an enhancement to, the generic group functionality. In addition, the group concept may be associated with authorization features that allow a user to manage particular functionality (e.g., display, edit, delete) applied to the group members (e.g., the sub-set of processes). In some aspects, computing environment100may facilitate techniques for grouping process structures in a SMUD by facilitating a generic concept that allows generic group functionality for a variety of functions. If group specific functionality is needed, an enhancement concept based on inheritance allows an enhancement to the generic functionality. In addition, the group concept may be associated with authorization features that manage which users can perform which functionality (e.g. display, edit, delete).

Turning to the example implementation ofFIG. 1, the illustrated environment100includes one or more clients102, at least some of which require access to secure data owned by the resource owner104and protected by the computer system106. The client computing devices102and resource owner104can communicate with one or more of the computer systems106over a network108. The computer system106can include one or more servers110and one or more data stores112. In some implementations, the system100may represent a client/server system supporting multiple computer systems106including one or more clients (e.g., client computing devices102and resource owners devices104) that are connectively coupled for communication with one another over the network108.

The client computing devices102and resource owner devices104can represent various forms of processing devices including, but not limited to, a desktop computer, a laptop computer, a handheld computer, a personal digital assistant (PDA), a cellular telephone, a network appliance, a camera, a smart phone, an enhanced general packet radio service (EGPRS) mobile phone, a media player, a navigation device, an email device, a game console, or a combination of any two or more of these data processing devices or other data processing devices. The client computing devices102and resource owner devices104can access application software on one or more of the computer systems106.

The computer system106can represent various forms of server systems including, but not limited to a web server, an application server, a proxy server, a network server, or a server farm. For example, one or more of the servers110can be an application server that executes software accessed by the client computing devices102and resource owner devices104. In some implementations, the computer system106disposes of a configuration interface that can extend Integrated Development Environments (IDE's) to support the integration of new protocols into web or cloud applications. A user can invoke applications available on one or more of the servers110in a web browser running on a client (e.g., client computing device102and resource owner devices104). Each application can individually access data from one or more repository resources (e.g., datastores112). The computer system106can include a storage device to store information. In one implementation, the storage device is a volatile memory unit. In another implementation, the storage device is a non-volatile memory unit. The storage device is capable of providing mass storage for the system106. In one implementation, the storage device is a computer-readable medium. In various different implementations, the storage device can be a floppy disk device, a hard disk device, an optical disk device, a tape device, or a flash memory device. The input/output device provides input/output operations for the system106. In one implementation, the input/output device includes a keyboard and/or pointing device. In another implementation, the input/output device includes a display unit for displaying graphical user interfaces.

In some implementations, the resource owner devices104may communicate wirelessly through a communication interface (not shown), which may include digital signal processing circuitry where necessary. The communication interface may provide for communications under various modes or web protocols, such as Global System for Mobile communication (GSM) voice calls, Short Message Service (SMS), Enhanced Messaging Service (EMS), or Multimedia Messaging Service (MMS) messaging, Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Personal Digital Cellular (PDC), Wideband Code Division Multiple Access (WCDMA), CDMA2000, or General Packet Radio System (GPRS), among others. For example, the communication may occur through a radio-frequency transceiver (not shown). In addition, short-range communication may occur, such Bluetooth, WiFi, or other such transceiver communications.

The network108can be a large computer network, such as a local area network (LAN), wide area network (WAN), the Internet, a cellular network, or a combination thereof connecting any number of mobile clients, fixed clients, and/or servers. In some implementations, each client (e.g., client computing device102) can communicate with one or more of the computer systems106via a virtual private network (VPN), Secure Shell (SSH) tunnel, or other secure network connection. The network108can include the Internet, a wireless service network and may include the Public Switched Telephone Network (PSTN). In other implementations, the network108may include a corporate network (e.g., an intranet) and one or more wireless access points.

The client computing devices102and resource owner devices104can establish their own sessions with the computer system106. Each session can involve two-way information exchange between the computer system106and the client computing devices102and resource owner devices104. For example, a Hypertext Transfer Protocol (HTTP) session can allow the association of information with individual users. A session can be a stateful session, in which at least one of the communicating parts (e.g., the computer systems106or the client computing device102or resource owner devices104) stores information about the session history in order to be able to communicate. Alternatively, stateless communication during a stateless session includes independent requests with associated responses.

FIG. 2Aillustrates an example system architecture200for grouping process structures in a SMUD. As illustrated, the architecture200includes a SmudIAPI module202that includes a SmudIAPI204and additional API modules that communicably couple the SmudIAPI204to a database206(e.g., a relational database, an in-memory database, or other type of database). The illustrated modules include, for example, a SmudILockManager module208, a SmudIPartitionedCmd module210, and a SmudIDbAccess module212. In some aspects, access to SMUD data (e.g., stored in the database206) may be provided via the provided APIs (e.g., SmudIAPI204, SmudDBAccess212and otherwise) so that it is not possible to access the database layer directly.

The illustrated architecture200also includes an SmudIGroups module214communicably coupled to the SmudIAPISmudIGrpAPI216through a SmudIGrpAPI216. In some aspects, the SmudIGroups module214may provide for generic functionality for groups (e.g., SMUD groups) in the architecture200. For example, SMUD instances (SMUDI) and SMUD groups may communicate via interfaces as shown inFIG. 2Ato filter data from a SMUDI, for example, through the interface ISmudIGrpFilter. Further, SmudIGroups214may lock occurrences of a SMUDI, such as through the interface IEnqueue. SmudIApi204may also manage change documents, for example, through the interface IChangeDocuments. In some aspects, this may allow occurrences to be stored in groups, occurrences to be locked via the group, and/or change information to be stored on group level.

In the illustrated example, APIs in SmudIGroups214may be used to store and retrieve group data (especially occurrences) and perform queries. In addition, the following interfaces may be provided for external users. For example, the interface ISmudIGRPAdmin may create groups, add users to a certain group or remove them, change the permissions of the group, and/or add occurrences and objects to a group or remove them. As another example, the interface ISmudIGRPFilter may be used to perform filter operations on lists of objects or occurrences (e.g., remove all occurrences for a list that have no copy permission). As another example, the interface ISmudIGRPQuery may be used for general queries (e.g., select all member of certain group, select all groups of a certain occurrence, and other queries).

Access to SMUD data, for example in the database220, may be provided via a SmudIAPI216and a SmudDBAccess module218. In some aspects, access to such SMUD data (e.g., data stored in a header as described below) may only be provided through such APIs, so that it is not possible to access the database layer directly.

FIG. 2Billustrates an example process hierarchy230for grouping process structures in a SMUDI232(e.g., a SMUD instance). In the illustrated hierarchy230, the sample process hierarchy and some objects234of the object pool are shown, along with attributes of such objects. In some aspects, all attributes, such as description, country, and industry of a business process, are derived from the object234of the object pool and can be visualized in the occurrence hierarchy230. In some aspects, the object pool is transparent to an end user and is only used for performance and data handling reasons. Further, in some examples, access to objects234of the pools may be through the occurrence structure, so that for some, most, or all operations (e.g., change, delete, relocate, and others), an occurrence context is available. In this example, the root node of the SMUDI232can be seen as a representative of the complete occurrence tree since this is the unique anchor point for the SMUDI232.

In SMUD, the concept of a process occurrence structure with object links may be used to manage process structures. In this concept, all structure information (e.g., that a process consists of process steps) may be stored in the SMUDI232. Each node in the SMUDI232has an ID. The hierarchical relation, in the illustrated hierarchy230, is stored as a parent-child relation between the occurrence nodes. In addition, each occurrence node may carry a link to the object234of an object pool (e.g., of multiple objects).

In some aspects, data (e.g., attributes) are stored together with the objects234in the object pool so that an occurrence node does not have any additional data. Thus, in the illustrated example hierarchy230, data of an occurrence can be fetched from the object234.

FIG. 2Cillustrates an example group header definition250in an architecture for grouping process structures in a SMUD. As illustrated, the definition250includes a group header252that includes a RootID254, ID256, and multiple (in this example) attributes258. In some aspects, the header252defines the SMUD group that includes GroupMembers260(e.g., defined by GroupID); GroupOccurences262(e.g., defined by various attributes such as the GroupID256, RootID254, occurrence ID, or OccID, whether it is active, and when and whom added the occurrence); GroupObjects264(e.g., defined by various attributes such as the GroupID256, object ID, and when and whom added the object); and GroupTypes266(e.g., defined by various attributes such as the GroupID256, object type ID, and when and whom added the object type).

The group header256defines the whole group. Since a group might be applied to occurrences or global objects, the GroupOccurences262and the GroupObjects264is available to store the corresponding group occurrence IDs or object IDs. User information may also be stored in the GroupMembers260. In some aspects, the GroupMembers260can be used to steer authorization features. In addition, it is possible to apply a group to object types of a SMUD model.

In some aspects, certain operations in SMUD can be performed if the correct authorization for the corresponding user is available. In addition, such authorized operations may be reduced to certain parts of the data (e.g., reduced to certain occurrences). As one example, a “scoping” flag can be used to define whether certain occurrences are “in scope” or “out of scope.” This information may then be used by other operations that can then decide whether they operate on all occurrences or only on occurrences that are “in scope” (e.g., a copy function). In some aspects, the default is that all occurrences are “in scope.” Since there may be authorizations, logging, and other features associated with scoping, an ordinary “scope flag” may not be enough to fulfill all requirements. Instead, a scope group is introduced that is based on a SMUD group concept. The scope group can contain all occurrences of a SMUDI that are “out-of-scope.” Since there may be many other groups needed, a SMUD_GROUP table (shown below) may manage different SMUD groups

SMUD_GROUPRemarkIDSCOPEIdentifies the groupNameOut of ScopeDescribes the groupGroupRoot_occ1234Each group is associated with exactlyone SMUDI. The SMUDI rootoccurrence ID is used for this.CreatedByuserCreator of a GroupCreatedAtJun. 25, 2013CreaterPermissionsnoneThe authorizations that the creator ofthe group has for the occurrences andobjects within the group (e.g., none =“the creator of the group can executeno operation for the occurrences andobjects in the group”)GroupPermissionsnoneThe authorizations that all members ofthe group have for the occurrences andobjects in the group ( e.g. none = “seeabove”)OtherRelocate,The authorizations that all other usersmodifyhave (e.g., users that are not the creatorand not a member of the group) for theoccurrences and objects in the group (e.g. relocate, modify = “All other usershave the permissions to relocate and tomodify the occurrences and objects ofthe group”)

FIGS. 3A-3Billustrate example sub-structures of a SMUD instance in an architecture for grouping process structures in a SMUD. Turning toFIG. 3A, for example, a SMUDI occurrence structure320is shown, which includes a SMUDI322with a scenario324that includes multiple processes326. Each process326includes multiple steps328, as illustrated. Continuing with the above, “out of scope” example, manipulation operations can be provided generically so that they are available for all SMUD groups. In the above “out of scope” example, various operations may be performed. For example, an occurrence such as occurrence “6” (e.g., in Proc2) may be put “out of scope” by Operation: AddOccurrences (‘SCOPE’, ‘6’). With this operation, occurrence ‘6’ is added to SMUD group “SCOPE.”

Turning toFIG. 3B, for example, an example of a copy scenario operation is illustrated. Here, a user may copy a scenario (e.g., Scen1) from the occurrence structure320from one SMUDI to another SMUDI, shown as occurrence structure340inFIG. 3B. The SMUDI occurrence structure340, as shown, includes a scenario342that includes multiple processes344. Each process344includes multiple steps346, as illustrated. In this example, operation, “in scope” occurrences may be taken into account, and since the occurrence ID of Scen1 is ‘2,’ the following operation can be performed: Copy(2,{SCOPE}. The following filter is now used: filterOccPermissionCopy (User=MN,{3,4,5,6,7,8,9,10,11}). This results, as illustrated, in {3,4,5,8,9,10,11} and, therefore, Scen1 will be copied taking the ‘Scope’ group into account. This leads to the result that process Proc2 (and its children) is omitted, since Proc2 was previously set “out of scope” as explained with reference toFIG. 3A.

FIGS. 4A-4Billustrate example group interface hierarchies for grouping process structures in a SMUD. Turning toFIG. 4A, for example, the interface hierarchy400illustrates group APIs in more detail. In this example, the super classes, such as IGroupAdmin402and SmudIGrpsFab404may provide for all of the functionality of a SMUDI group in a generic way. Case specific features, if needed by the SMUDI group, may be provided by a sub-class, such as, for example, the sub-classes needed by a special group. A sub-class may provide these feature as indicated by sub-classes ScopeGroups408and ChangeGroup410.

Turning toFIG. 4B, the interface hierarchy440illustrates additional group APIs in more detail. In this example, the super classes IGroupAOQuery442and Allowed Operation446may provide for all of the functionality of a SMUDI group in a generic way. Illustrated sub-classes include GroupQueryBase444and GroupEnqueue448

In some aspects, authorization and permission features may be provided via the “group member:” In one example method for providing authorization and permission features, a check is first conducted as to whether a current user exists (e.g., test if the user name is initial). If, in one example, the user is the creator of the group, this check is confirmed from the group header (as shown in the table above). Thus, corresponding authorization as defined in the header is provided. If the user has not created the group, then the check is confirmed against the defined group membership attributes. Depending on the result of this check, the corresponding authorization may be provided (or not, if the user is not among the group membership attributes).

Several examples are disclosed herein, in addition to the scoping example provided above. One example is a “Change Groups” example. In this example, changes to an occurrence may only be possible via a “change request.” In some aspects, changes shall be applied to “inactive” versions of the occurrences and, for example, may only be possible by authorized users. A change request can be supported via a “change group” that is defined in a similar way as the “scope group,” as shown in the following table.

CHANGE_GROUPRemarkIDChangeChange group identifierNameChange GroupChange GroupRoot_occ1234SMUD Occurrence Root NodeCreatedByuserUser who has created the groupCreatedAtSep. 10, 2012CreaterPermissionsallThe creator and all members of thechange group can perform anyoperation on the occurrences andobjects in the groupGroupPermissionsallOthernone

For example, with reference toFIG. 3A, a sample occurrence hierarchy with root1234is illustrated. A change request for process Proc1 (occurrence ID 3) is created. Since a change request for a process may also encompass the corresponding process steps of the process, also Step1.1 and Step 1.2 are involved. This may be realized in the following way based on the group concept. First, a user creates a change request for Proc1. Next, a change with ID 23 for SMUDI 1234 is created for the change group: ChangeAdmin.createChange(1234, . . . ):CHANGE_ID=23. Next, the affected occurrences are calculated (Proc1, Step1.1, Step 1.2): SmudIQuery.readOccurrenceStructure(3):{4,5}. Next a change group is created and member “MN” is added to the member group with read and change authorization: SmudiGrpsAdmin.createGroup(ID=23,RootId=1234, . . . ), SmudiGrpsAdmin.addMember({MN}),SmudiGrpsAdmin.setGroupAO(read=X,change=X . . . ), and SmudiGrpsAdmin.setOtherAO(none). Next, occurrences are added to group 23: SmudiGrpsAdmin.addOccurrences({3,4,5}). Next, inactive occurrences are created for the occurrences in the new group: SmudICmd.SetToInactive({3,4,5}). Finally, an authorization check for occurrence 4 (Step 1.1) is performed if an attribute is to be changed by user “MN” (group member) or by user “MV” (not a group member): SmudiCmd.setAttribute({4} . . . ),SmudiGrpsAOFilter.filterOccAOChange(MN,{4})→{4}→change possible, and SmudiGrpsAOFilter.filterOccAOChange(MV,{4})→{ }→change not possible.

This example shows that the group concept fits well to the requirements. In many cases, the provided generic functionality for groups can be used so that only a minimum of specific functionality needs to be implemented in a sub-class for “change groups.”

Another example is a “Blueprint Lock.” There may be two options for the “Blueprint Lock”: an Edit Structures in which the structure (e.g., all occurrences of a SMUDI) may not be edited anymore; or an Edit Structures, Change Documents and Administration Data in which additional change of blueprint relevant documentation and the administration data is not allowed.

In this use case, a “blueprint lock group” may be defined to fulfill the above requirements.

In the SMUDI ofFIG. 3A, a blueprint lock is to be defined by the following example process. First, a user may activate a Blueprint Structure Lock for SMUDI 1234: Root.ProjSolAdmGrp.LockOptGroup.BlueprintLockStruc.setAttribute(ISACTIVE=abap_true). Second, the affected occurrences/objects are determined: SmudIQuery.readOccurrenceStructure(1):{2,3,4,5 . . . }. Next, the group is locked for the SMUDI: SmudiGrpsAdmin.lockGroup(groupID). Next, the blueprint lock group is created: SmudiGrpsAdmin.createGroup(GroupType=BLUEPRINTLOCKSTRUC RootId=1234, . . . ),SmudiGrpsAdmin.setOtherAO(read, copy). Next, affected occurrences are added to group: SmudiGrpsAdmin.addOccurrences({1,2,3,4,5}). Next, affected objects are added to group (e.g., global objects that are referenced by the occurrences): SmudiGrpsAdmin.addObjects({O1, O2, O3}). Next, the group is unlocked: SmudiGrpsAdmin.unlockGroup(groupID). Next, the change is checked: SmudiCmd.setAttribute({4}),SmudiGrpsAOFilter.filterOccAOChange(MN,{4})→{ }→change not possible.

In another example, the SMUDI group concept can be applied to object types defined via the SMUD models. For example, the SMUD Instances may be based on a SMUD Model. The model defines the object types, their attributes, and relations. In some cases, it may be more effective to define groups using the object types and not the instances of the objects (e.g., occurrence IDs). For example, continuing the above Blueprint Lock example, this can be defined so that the lock should affect only the process structure (e.g., no user should change the processes or scenarios but it should be possible to add more content (documents)). To that end, “Structure objects types” can be added to the group: SmudIModel.getAllStructureTypes( ):{SCN,PROC,PROCSTEP, . . . }, and SmudiGrpsAdmin.addTypes({SCN,PROC,PROCSTEP, . . . }). Now the permissions of this group apply to all occurrences and objects within the SMUDI with the given types and each instance of the type need not be added individually.

The processes and logic flows described in this specification can be performed by one or more programmable computers executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., a central processing unit (CPU), a FPGA (field programmable gate array), or an ASIC (application-specific integrated circuit).

Particular implementations of the subject matter have been described. Other implementations, alterations, and permutations of the described implementations are within the scope of the following claims as will be apparent to those skilled in the art. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. Accordingly, the above description of example implementations does not define or constrain this disclosure. Other changes, substitutions, and alterations are also possible without departing from the spirit and scope of this disclosure.