Conditional creation of child nodes based on ancestor node metadata runtime values

Conditional creation of child nodes based on ancestor node metadata runtime values are described. A system receives, from an end user device, a runtime request to create an instance of a child node in a case model. The system identifies an instance of an ancestor node associated with the instance of the child node. The system identifies a runtime value of metadata associated with the instance of the ancestor node and corresponding to the instance of the child node. The system determines whether the runtime value of the metadata satisfies a condition. The system creates the instance of the child node in response to a determination that the runtime value of the metadata satisfies the condition. The system enables the end user device to access the created child node.

BACKGROUND

The exponential growth of available data, coupled with an increasing complexity of customer and regulatory data requirements, has presented challenges to information management organizations. These challenges have led to the application of data models and case management systems to organize data and effectively communicate relevant business metrics. Traditionally used in social services, healthcare, banking, insurance, and legal environments, case management systems are rapidly expanding into many other industries as organizations recognize that case management systems can be used to make data easily accessible, up-to-date, quickly tracked, and more manageable in the context of business processes.

DETAILED DESCRIPTION

Embodiments herein provide conditional creation of child nodes based on ancestor node metadata runtime values. A system receives, from an end user device, a runtime request to create an instance of a child node in a case model. The system identifies an instance of an ancestor node associated with the instance of the child node. The system identifies a runtime value of metadata associated with the instance of the ancestor node and corresponding to the instance of the child node. The system determines whether the runtime value of the metadata satisfies a condition. The system creates the instance of the child node in response to a determination that the runtime value of the metadata satisfies the condition. The system enables the end user device to access the created child node.

For example, a loan administrator's device requests a case management system to create an instance of a child node for documents for an instance of a parent node for personal income verification associated with a home loan case. The case management system accesses a “CreateOnConditionExpression: Parent.salaried==true” expression in the child node for documents in the hierarchical case model, which identifies the instance of the parent node for personal income verification and its Boolean metadata “salaried.” The case management system identifies the runtime value as “true” for the personal income verification parent node's Boolean metadata “salaried.” The case management system determines whether the “true” runtime value of the Boolean metadata “salaried” satisfies the expression “CreateOnConditionExpression: Parent.salaried==true” in the child node for documents in the hierarchical case model. The case management system creates the child node for documents as a specific child node for salaried employment documents because the runtime value of “true” for the Boolean metadata “salaried” satisfies the condition of the expression in the child node for documents in the hierarchical case model. The case management system enables the loan administrator's device to access the instance of the hierarchical case model for the home loan, which includes the child node for salaried employment documents. The case management system bases conditional creation of child nodes on ancestor node metadata runtime values, without the need for an application developer to create any custom code for any hierarchical case models.

Prior to describing the subject matter in detail, an exemplary hardware system in which the subject matter may be implemented is described. Those of ordinary skill in the art will appreciate that the elements illustrated inFIG. 1may vary depending on the system implementation.FIG. 1illustrates one embodiment of a system for providing an enterprise-level managed content service. Client applications100access a content management system120, which operates and manages a repository system140.

The use of the client applications100originates from client devices, such as client devices101,102,103, which communicate through a network104with an application server121in order to use one or more applications hosted in part or entirely on the application server121. In one embodiment, the network104is an Ethernet connection using conventional TCP/IP communication methods with both client devices and server devices. However, other types of network connection technologies are well known and may also be used to full advantage, including local area network (LAN), wide area network (WAN), storage area network (SAN), the Internet, etc. Each of the client devices101-103may be any type of processor-based digital device, such as desktop, laptop computer, tablet, smartphone, or other smart hand-held device.

The application server121hosts one or more applications running on a content management platform that provide access to the repository140for clients hosted on a content server122, which is also accessible to the client devices101-103via the network104. An HTTP server123is also coupled to the network104to provide an administrative terminal for system operators to perform system maintenance, logging, access control, etc. The client devices101-103and the servers121-123may each be substantially similar to the system900depicted inFIG. 9and described below.

The repository140is provided for use by the client applications100, through the content server122, which is accessible to the client devices101-103through the network104. The repository140may include a file store141for storing content items, a relational database142for storing attributes/metadata associated with the content items, a full-text index store143for the content items, and directory services144.

A software platform runs on each of the various components, such as the Documentum® Platform software and related Enterprise Content Management software, provided by EMC® Corporation, Hopkington, Mass. The Documentum® Platform provides capabilities for managing enterprise content and is the foundation for related content management and case management product offering.

FIG. 2is a flowchart that illustrates a method for conditional creation of child nodes based on ancestor node metadata runtime values, under an embodiment. Flowchart200illustrates method acts illustrated as flowchart blocks for certain steps involved in and/or between the client devices101,102, or103and/or the servers121,122, or123ofFIG. 1.

A runtime request to create an instance of a child node in a case model is received from an end user device, block202. For example, a loan administrator's device requests a case management system to create an instance of a child node F111for documents for an instance of a parent node F11for personal income verification associated with a home loan case. The parent node F11for personal income verification may have its own parent node F1for a “Loan 123.” An example of a hierarchical case model300which includes the nodes F1, F11, and F111, as well as the potential child node F112are depicted inFIG. 3and described below in reference toFIG. 3.

Having received the runtime request to create the instance of the child node, an instance of an ancestor node associated with the instance of the child node is identified, block204. For example, the case management system accesses a “CreateOnConditionExpression: Parent.salaried==true” expression in the child node F111for documents in the hierarchical case model, which identifies the instance of the parent node F11for personal income verification and its Boolean metadata “salaried.” Although this example describes an expression in a child node identifying an instance of the parent node for the child node, an expression in a child node may identify an instance of any type of ancestor node for the child node, such as an instance of a grandparent node for the child node.

After identifying the instance of the ancestor node, a runtime value of metadata associated with the instance of the ancestor node and corresponding to the instance of the child node is identified, block206. For example, the case management system identifies the runtime value as “true” for the personal income verification parent node's Boolean metadata “salaried,” a runtime value which would not have be known by any developer at development time for the hierarchical case model Although this example describes an expression in a child node identifying Boolean metadata, an expression in a child node may identify any type of metadata, such as integers, decimal-based numbers, cases phases, case roles, and sets of access permissions.

Having identified the runtime value of the metadata, a determination is made whether the runtime value of the metadata satisfies a condition, block208. For example, the case management system determines whether the “true” runtime value of the Boolean metadata “salaried” satisfies the expression “CreateOnConditionExpression: Parent.salaried==true” in the child node F111for documents in the hierarchical case model. If the runtime value of the metadata satisfies the condition, the flowchart200continues to block210. If the runtime value of the metadata does not satisfy the condition, the flowchart200proceeds to block212.

If the runtime value of the metadata satisfies the condition, the instance of the child node is created, block210. For example, the case management system creates the child node F111for documents as a specific child node F111for salaried employment documents because the runtime value of “true” for the Boolean metadata “salaried” satisfies the condition of the expression in the child node F111for documents in the hierarchical case model. Then the flowchart200proceeds to block216.

The case management system may conditionally create child nodes based on other types of runtime ancestor node metadata values, such as metadata values for an integer, a decimal-based number, a case phase, a case role, and/or a set of case access permissions. For example, the case management system may receive a request to create another child node for home details, access the child node's expression which identifies the parent node's metadata “phase,” identify the runtime value for the metadata “phase” as “loan initiation,” and conditionally create the child node for home details as a child node for an alternative home for the loan applicant's loan. Continuing this example, the case management system may receive a request to create another child node for home details, access the child node's expression which identifies the parent node's metadata “phase,” identify the runtime value for the metadata “phase” as “offer rejected,” and conditionally create the child node for home details as a child node for the primary home for the loan applicant's loan.

In another example, the case management system may access a child node's expression which identifies a parent node's metadata “underwriter_role,” identify the runtime value for “underwriter_role” as “senior,” and conditionally create a child node for large loan documents because senior underwriters are only assigned large loans. Continuing this example, the case management system may access a child node's expression which identifies a parent node's metadata “underwriter_role,” identify the runtime value for “underwriter_role” as “junior,” and conditionally create a child node for small loan documents because junior underwriters are only assigned small loans.

In yet another example, the case management system may receive a runtime request to create a child node for supplemental documents, access the child node's expression which identifies a parent node's metadata “loan_applicant_access_permissions,” and identify the runtime value for “loan_applicant_access_permissions” as “create, read, update, and delete.” The case management system may respond to the runtime metadata value of “create, read, update, and delete” by conditionally creating a child node for loan applicant documents because the parent node's set of access permissions for the loan applicant indicate that the supplemental documents are the loan applicant's documents. Continuing this example, the case management system may receive a runtime request to create a child node for supplemental documents, access the child node's expression which identifies a parent node's metadata “loan_applicant_access_permissions,” and identify the runtime value for “loan_applicant_access_permissions” as “no access.” The case management system may respond to this runtime metadata value of “no access” by conditionally creating a child node for loan administrator documents because the parent node's set of access permissions for the loan applicant indicate that the supplemental documents are not the loan applicant's documents. The case management system may assign any set of permissions to a case role from a group of permissions that includes a create permission, a read permission, an update/edit permission, a delete permission, and a no access permission.

If the runtime value of the metadata does not satisfy the condition, a determination is optionally made whether the runtime value of the metadata satisfies an alternative condition, block212. For example, the case management system determines whether the “false” runtime value of the Boolean metadata “salaried” satisfies the expression “CreateOnConditionExpression: Parent.salaried==false” in the child node F112for documents in the hierarchical case model. If the runtime value of the metadata satisfies the alternative condition, the flowchart200continues to block214. If the runtime value of the metadata does not satisfy the alternative condition, the flowchart200terminates.

If the runtime value of the metadata satisfies the alternative condition, an instance of an alternative child node is optionally created, block214. For example, the case management system creates the child node F112for documents as a specific child node F112for self-employed documents because the runtime value of “false” for the Boolean metadata “salaried” satisfies the condition of the expression in the child node F112for documents in the hierarchical case model.

Although these examples describe the case management system determining whether the runtime value of an ancestor node's metadata satisfy either of two Boolean conditions, the determination may be made based on satisfying any number of conditions. For example, the case management system accesses a child node's expression which identifies a parent node's metadata “loan_amount,” identifies the runtime value for “loan_amount” as corresponding to a large loan (more than $1,000,000), an intermediate loan (from $500,000 to $1,000,000), or a small loan (less than $500,000) based on corresponding thresholds in three different child node expressions. Then the case management system conditionally creates a child node for a large loan and assigns a role for a senior loan underwriter and a set of access permissions for the senior loan writer, conditionally creates a child node for an intermediate loan and assigns a role for a mid-level loan underwriter and a set of access permissions for the mid-level loan writer, or conditionally creates a child node for a small loan and assigns a role for a junior loan underwriter and a set of access permissions for the junior loan writer, based on which child node's expression is satisfied.

After conditionally creating a child node, the end user device is enabled to access the created child node, block216. For example, the case management system enables the loan administrator's device to access the instance of the hierarchical case model for the “Loan 123,” which includes the child node F111for salaried employment documents. Alternatively, the hierarchical case model for the “Loan 123” may include the child node F112for self-employed documents.

AlthoughFIG. 2depicts the blocks202-216occurring in a specific order, the blocks202-216may occur in another order. In other implementations, each of the blocks202-216may also be executed in combination with other blocks and/or some blocks may be divided into a different set of blocks. The case management system conditionally creates child nodes based on runtime ancestor node metadata values, without the need for an application developer to create any custom code for any hierarchical case models. The case management system may create multiple instances of any hierarchical case model, with each instance already containing the complex hierarchical case model metadata expressions.

Referring toFIG. 3, one example of a hierarchical case model300is illustrated. The F1node (block302) represents the container, or engagement space, of the case model as a whole. The F11node (block304) represents a first project container for a specific application or case that utilizes the case model that includes the F1node. For example, the F11node represents personal income verification, and may be conditionally created based on the runtime metadata values of the parent F1node, which represents a home loan. There may be other project containers for other applications on the same level as the F11node, utilizing the case model that includes the F1node. The F111node (block306), which represents salaried employment documents, and the F112node (block308), which represents self-employed documents, are alternative child nodes, one of which may be conditionally created based on runtime metadata values of the F11node (block302). Furthermore, either of the F111node and the F112node may be conditionally created based on the runtime metadata values of the (relative to the nodes F111and F112) grandparent F1node.

Referring toFIG. 4, one example of a hierarchical case model400is illustrated. The F1node (block402) represents the container, or engagement space, of the case model as a whole, and a corresponding role R1is assigned permissions to read (R) and update/edit (U) the F1node.

The F11node (block404) represents a first project container for a specific application or case that utilizes the case model that includes the F1node. For example, the F11node represents the case of a home loan. For hierarchical case models, the roles and permissions corresponding to the F11node could automatically inherit the roles and permissions corresponding to the F1node. In this case model, since the F11node represents the application level, all permissions are available to be granted to the user role R1at this level (block404), namely create, read, update/edit and delete (CRUD). There may be other project containers for other applications on the same level as the F11node, utilizing the case model that includes the F1node.

In addition, new permissions can be defined and assigned to selected roles and/or users. For example, as noted above, the F11node represents a first object corresponding to the case model that includes the F1node, and a first group of users, such as U1and U2, can be assigned as members belonging to the R11acase role, and having the permissions for read (R) and update (U). (block404) Likewise, a second group of users, such as U3and U4, can be assigned as members belonging to the R11bcase role, and having the permissions for read (R) only (block404).

The F111node (block406) and the F112node (block408) are defined sub-nodes, or children, of the main F11node (block402), or parent node. The F111node and the F112node are therefore considered children nodes which may include roles and permissions that correspond to the parent node F11node. That is, the R1case role could inherit all of the CRUD permissions for both of the F111node and the F112node. The first group of users R11a(including users U1and U2) also has all CRUD permissions for the F111node, and a sub-group of users R111is granted read (R) and update (U) permissions only for the F111node (block406). The second group of users R11bis granted read (R) permissions only for the F111node (block406). The second group of users R11b(including the users U3and U4) could also inherit all of the CRUD permissions for the F112node, while the first groups of users R11ais granted no access permissions for the F112node (block408). Similarly, the roles and the permissions corresponding to the F111node are listed in block310.

FIG. 5illustrates a more concrete example model500of the hierarchical case model400for the case of a home loan. A loan502node represents the container of the case model as a whole, including loan administrator, loan underwriter, and loan applicant roles defined for the case model and assigned global permissions. For example, the loan administrator role is assigned permissions to read (R) and update/edit (U) for the loan502node; the loan underwriter role is assigned permission to read (R) only for the loan502node; and the loan applicant role is assigned permission to read (R) only for the loan502node.

A financial504node is defined to store financial documents for the loan process, such as income documents in an income documents508node, and a home details506node is defined to store documents related to home details, such as in home inspection reports510node. The roles and permissions corresponding to the financial504node could include inherited roles and permissions from the loan502node. For example, the loan administrator role is granted all permissions to create (C), read (R), update/edit (U), and delete (D) the financial504node. The roles and permissions corresponding to the income documents508node could include inherited roles and permissions from the financial404node. Further, the loan applicant role is granted all permissions to create (C), read (R), update/edit (U), and delete (D) the income documents408node.

The roles and permissions corresponding to the home details406node could include inherited roles and permissions from the loan502node. For example, the loan administrator role is granted all permissions to create (C), read (R), update/edit (U), and delete (D) for the home details506node. In addition, a new role is defined at this level, namely, the home inspector role, and is assigned permission to read (R) only for the home details506node. The roles and permissions that correspond to the home inspection reports510node could include inherited roles and permissions from the home details506node. In this scenario, the home inspector role is also assigned all of the permissions to create (C), read (R), update/edit (U), and delete (D) the home inspection reports510node.

FIG. 6illustrates an example instance600of the hierarchical case model500for the case of a home loan. The example instance600could be for “Loan 123,” in which specific individuals are assigned case roles at runtime. For example, Adam is assigned the loan administrator case role, Uma is assigned the loan underwriter case role, both Alan and Angelia are assigned the loan applicants case role, and Harry is assigned the home inspector case role for the “Loan 123” example instance600of the hierarchical case model500.

FIG. 7illustrates another example instance700of the hierarchical case model500for the case of a home loan. The example instance700could be for “Loan 456,” in which the individuals who are assigned the case roles could be entirely different from the individuals who assume the case roles for the “Loan 123.” For example, Andy is assigned the loan administrator case role, Sam is assigned the loan underwriter case role, both Joe and Amy are assigned the loan applicants case role, and Harry is assigned the home inspector case role of the “Loan 456” instance of the hierarchical case model400. For these examples, other than Harry, who coincidentally assumes the home inspector case role for both instances600and700, the individuals who are assigned the case roles for the “Loan 123” would have none of the access permissions for the “Loan 456,” and the individuals who are assigned the case roles for the “Loan 456” would have none of the access permissions for the “Loan 123.”

Each case model instance may go through several phases, such as loan initiation, review, underwriting, and closed. The case management system may implement various actions based on phase changes, such as changing all access permissions to read only when a case model instance enters into the closed phase. The case management system may implement event triggers based on phase changes or based on either any case model instance or case node being created, thereby triggering a stateful/stateless process or an action such as sending an email.

A meta-model to describe the hierarchical case model access roles and permissions described above may be expressed in any modeling language. For example,FIG. 8illustrates an example designed using the Eclipse Modeling Framework. Lines 1-3 indicate that the case management system creates a container, or engagement space, for a “case model” that is modeled with a “data model” with specific instances of “case nodes.” Lines 4-15 define the data model in terms of a lifecycle, case roles, permissions, and other useful characteristics, such as anchor points for additional disclosure re phases, events and placeholders of other applications. Lines 16-30 further define the permissions.

Having describing the subject matter in detail, an exemplary hardware device in which the subject matter may be implemented shall be described. Those of ordinary skill in the art will appreciate that the elements illustrated inFIG. 9may vary depending on the system implementation. With reference toFIG. 9, an exemplary system for implementing the subject matter disclosed herein includes a hardware device900, including a processing unit902, memory904, storage906, a data entry module908, a display adapter910, a communication interface912, and a bus914that couples the elements904-912to the processing unit902.

The bus914may comprise any type of bus architecture. Examples include a memory bus, a peripheral bus, a local bus, etc. The processing unit902is an instruction execution machine, apparatus, or device and may comprise a microprocessor, a digital signal processor, a graphics processing unit, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc. The processing unit902may be configured to execute program instructions stored in the memory904and/or the storage906and/or received via the data entry module908.

The memory904may include read only memory (ROM)916and random access memory (RAM)918. The memory904may be configured to store program instructions and data during operation of the hardware device900. In various embodiments, the memory904may include any of a variety of memory technologies such as static random access memory (SRAM) or dynamic RAM (DRAM), including variants such as dual data rate synchronous DRAM (DDR SDRAM), error correcting code synchronous DRAM (ECC SDRAM), or RAMBUS DRAM (RDRAM), for example. The memory904may also include nonvolatile memory technologies such as nonvolatile flash RAM (NVRAM) or ROM. In some embodiments, it is contemplated that the memory904may include a combination of technologies such as the foregoing, as well as other technologies not specifically mentioned. When the subject matter is implemented in a computer system, a basic input/output system (BIOS)920, containing the basic routines that help to transfer information between elements within the computer system, such as during start-up, is stored in the ROM916.

The storage906may include a flash memory data storage device for reading from and writing to flash memory, a hard disk drive for reading from and writing to a hard disk, a magnetic disk drive for reading from or writing to a removable magnetic disk, and/or an optical disk drive for reading from or writing to a removable optical disk such as a CD ROM, DVD or other optical media. The drives and their associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for the hardware device900.

It is noted that the methods described herein can be embodied in executable instructions stored in a computer readable medium for use by or in connection with an instruction execution machine, apparatus, or device, such as a computer-based or processor-containing machine, apparatus, or device. It will be appreciated by those skilled in the art that for some embodiments, other types of computer readable media may be used which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, RAM, ROM, and the like may also be used in the exemplary operating environment. As used here, a “computer-readable medium” can include one or more of any suitable media for storing the executable instructions of a computer program in one or more of an electronic, magnetic, optical, and electromagnetic format, such that the instruction execution machine, system, apparatus, or device can read (or fetch) the instructions from the computer readable medium and execute the instructions for carrying out the described methods. A non-exhaustive list of conventional exemplary computer readable medium includes: a portable computer diskette; a RAM; a ROM; an erasable programmable read only memory (EPROM or flash memory); optical storage devices, including a portable compact disc (CD), a portable digital video disc (DVD), a high definition DVD (HD-DVD™), a BLU-RAY disc; and the like.

A number of program modules may be stored on the storage906, the ROM916or the RAM918, including an operating system922, one or more applications programs924, program data926, and other program modules928. A user may enter commands and information into the hardware device900through the data entry module908. The data entry module908may include mechanisms such as a keyboard, a touch screen, a pointing device, etc. Other external input devices (not shown) are connected to the hardware device900via an external data entry interface930. By way of example and not limitation, external input devices may include a microphone, joystick, game pad, satellite dish, scanner, or the like. In some embodiments, external input devices may include video or audio input devices such as a video camera, a still camera, etc. The data entry module908may be configured to receive input from one or more users of the hardware device900and to deliver such input to the processing unit902and/or the memory904via the bus914.

A display932is also connected to the bus914via the display adapter910. The display932may be configured to display output of the hardware device900to one or more users. In some embodiments, a given device such as a touch screen, for example, may function as both the data entry module908and the display932. External display devices may also be connected to the bus914via an external display interface934. Other peripheral output devices, not shown, such as speakers and printers, may be connected to the hardware device900.

The hardware device900may operate in a networked environment using logical connections to one or more remote nodes (not shown) via the communication interface912. The remote node may be another computer, a server, a router, a peer device or other common network node, and typically includes many or all of the elements described above relative to the hardware device900. The communication interface912may interface with a wireless network and/or a wired network. Examples of wireless networks include, for example, a BLUETOOTH network, a wireless personal area network, a wireless 802.11 local area network (LAN), and/or wireless telephony network (e.g., a cellular, PCS, or GSM network). Examples of wired networks include, for example, a LAN, a fiber optic network, a wired personal area network, a telephony network, and/or a wide area network (WAN). Such networking environments are commonplace in intranets, the Internet, offices, enterprise-wide computer networks and the like. In some embodiments, the communication interface912may include logic configured to support direct memory access (DMA) transfers between the memory904and other devices.

In a networked environment, program modules depicted relative to the hardware device900, or portions thereof, may be stored in a remote storage device, such as, for example, on a server. It will be appreciated that other hardware and/or software to establish a communications link between the hardware device900and other devices may be used.

It should be understood that the arrangement of the hardware device900illustrated inFIG. 9is but one possible implementation and that other arrangements are possible. It should also be understood that the various system components (and means) defined by the claims, described below, and illustrated in the various block diagrams represent logical components that are configured to perform the functionality described herein. For example, one or more of these system components (and means) can be realized, in whole or in part, by at least some of the components illustrated in the arrangement of the hardware device900.

In addition, while at least one of these components are implemented at least partially as an electronic hardware component, and therefore constitutes a machine, the other components may be implemented in software, hardware, or a combination of software and hardware. More particularly, at least one component defined by the claims is implemented at least partially as an electronic hardware component, such as an instruction execution machine (e.g., a processor-based or processor-containing machine) and/or as specialized circuits or circuitry (e.g., discrete logic gates interconnected to perform a specialized function), such as those illustrated inFIG. 9.

Other components may be implemented in software, hardware, or a combination of software and hardware. Moreover, some or all of these other components may be combined, some may be omitted altogether, and additional components can be added while still achieving the functionality described herein. Thus, the subject matter described herein can be embodied in many different variations, and all such variations are contemplated to be within the scope of what is claimed.