US20120173572A1 - Concurrent Long Spanning Edit Sessions using Change Lists with Explicit Assumptions - Google Patents
Concurrent Long Spanning Edit Sessions using Change Lists with Explicit Assumptions Download PDFInfo
- Publication number
- US20120173572A1 US20120173572A1 US13/417,223 US201213417223A US2012173572A1 US 20120173572 A1 US20120173572 A1 US 20120173572A1 US 201213417223 A US201213417223 A US 201213417223A US 2012173572 A1 US2012173572 A1 US 2012173572A1
- Authority
- US
- United States
- Prior art keywords
- change
- assumptions
- request
- external
- changes
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 230000008859 change Effects 0.000 title claims abstract description 69
- 238000012508 change request Methods 0.000 claims abstract description 53
- 230000004044 response Effects 0.000 claims abstract description 20
- 238000000034 method Methods 0.000 claims description 40
- 238000012545 processing Methods 0.000 claims description 33
- 230000004048 modification Effects 0.000 claims description 6
- 238000012986 modification Methods 0.000 claims description 6
- 238000013459 approach Methods 0.000 abstract description 2
- 230000008569 process Effects 0.000 description 19
- 238000010586 diagram Methods 0.000 description 13
- 238000004590 computer program Methods 0.000 description 11
- 238000007726 management method Methods 0.000 description 11
- 230000006870 function Effects 0.000 description 8
- 230000003287 optical effect Effects 0.000 description 7
- 238000013070 change management Methods 0.000 description 6
- 239000000463 material Substances 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 239000013307 optical fiber Substances 0.000 description 2
- 230000000644 propagated effect Effects 0.000 description 2
- 230000003442 weekly effect Effects 0.000 description 2
- LYNCXVGFZKKGDB-UHFFFAOYSA-M [2-hydroxy-3-(4-methoxyphenoxy)propyl]-[2-[[2-hydroxy-3-(4-methoxyphenoxy)propyl]amino]ethyl]-dimethylazanium;chloride;hydrochloride Chemical compound Cl.[Cl-].C1=CC(OC)=CC=C1OCC(O)CNCC[N+](C)(C)CC(O)COC1=CC=C(OC)C=C1 LYNCXVGFZKKGDB-UHFFFAOYSA-M 0.000 description 1
- 230000003190 augmentative effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000012858 packaging process Methods 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000026676 system process Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2308—Concurrency control
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/40—Information retrieval; Database structures therefor; File system structures therefor of multimedia data, e.g. slideshows comprising image and additional audio data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/235—Update request formulation
Definitions
- Information handling systems often include object models that can be edited by multiple users. Conflicts can arise when conflicting submissions are received that pertain to a common object. Locking objects is infeasible and overly burdensome when object editing sessions lasts a relatively long period of time. Conversely, simply allowing concurrent edits of the same object can introduce many conflicts that can be difficult, or even impossible, to identify and resolve.
- An approach is provided that receives a change request from a requestor.
- the change request includes metadata regarding the change, one or more changes, and one or more change assumptions corresponding to at least one of the changes.
- the change request is stored in a data store of pending requests.
- One or more systems are identified that correspond to each of the change assumptions.
- the identified systems are automatically queried with queries that correspond to the change assumptions.
- Query responses in response to the querying are received from the identified systems.
- the validity of each of the change assumptions is determined based on the received query responses. If the change assumptions are valid, then the changes included in the change request are processed. On the other hand, if at least one of the change assumptions is invalid, then the change request is rejected.
- FIG. 1 is a block diagram of a data processing system in which the methods described herein can be implemented
- FIG. 2 provides an extension of the information handling system environment shown in FIG. 1 to illustrate that the methods described herein can be performed on a wide variety of information handling systems which operate in a networked environment;
- FIG. 3 is a high level diagram showing interaction of the processes and entities used to provide concurrent long spanning edit sessions using changelists with explicit assumptions;
- FIG. 4 is a flowchart showing steps taken by a requestor of a change request
- FIG. 5 is a flowchart showing steps taken by a change request management system
- FIG. 6 is a flowchart showing steps taken to analyze request assumptions
- FIG. 7 is a flowchart showing steps taken to check internal assumptions
- FIG. 8 is a flowchart showing steps taken to check external assumptions.
- FIG. 9 is a flowchart showing steps taken when a request is rejected.
- aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
- the computer readable medium may be a computer readable signal medium or a computer readable storage medium.
- a computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.
- a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
- a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof.
- a computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
- Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
- Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages.
- the program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server.
- the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
- LAN local area network
- WAN wide area network
- Internet Service Provider for example, AT&T, MCI, Sprint, EarthLink, MSN, GTE, etc.
- These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
- These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
- the computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
- FIG. 1 A computing environment in FIG. 1 that is suitable to implement the software and/or hardware techniques associated with the invention.
- FIG. 2 A networked environment is illustrated in FIG. 2 as an extension of the basic computing environment, to emphasize that modern computing techniques can be performed across multiple discrete devices.
- FIG. 1 illustrates information handling system 100 , which is a simplified example of a computer system capable of performing the computing operations described herein.
- Information handling system 100 includes one or more processors 110 coupled to processor interface bus 112 .
- Processor interface bus 112 connects processors 110 to Northbridge 115 , which is also known as the Memory Controller Hub (MCH).
- Northbridge 115 connects to system memory 120 and provides a means for processor(s) 110 to access the system memory.
- Graphics controller 125 also connects to Northbridge 115 .
- PCI Express bus 118 connects Northbridge 115 to graphics controller 125 .
- Graphics controller 125 connects to display device 130 , such as a computer monitor.
- Northbridge 115 and Southbridge 135 connect to each other using bus 119 .
- the bus is a Direct Media Interface (DMI) bus that transfers data at high speeds in each direction between Northbridge 115 and Southbridge 135 .
- a Peripheral Component Interconnect (PCI) bus connects the Northbridge and the Southbridge.
- Southbridge 135 also known as the I/O Controller Hub (ICH) is a chip that generally implements capabilities that operate at slower speeds than the capabilities provided by the Northbridge.
- Southbridge 135 typically provides various busses used to connect various components. These busses include, for example, PCI and PCI Express busses, an ISA bus, a System Management Bus (SMBus or SMB), and/or a Low Pin Count (LPC) bus.
- PCI and PCI Express busses an ISA bus
- SMB System Management Bus
- LPC Low Pin Count
- the LPC bus often connects low-bandwidth devices, such as boot ROM 196 and “legacy” I/O devices (using a “super I/O” chip).
- the “legacy” I/O devices ( 198 ) can include, for example, serial and parallel ports, keyboard, mouse, and/or a floppy disk controller.
- the LPC bus also connects Southbridge 135 to Trusted Platform Module (TPM) 195 .
- TPM Trusted Platform Module
- Other components often included in Southbridge 135 include a Direct Memory Access (DMA) controller, a Programmable Interrupt Controller (PIC), and a storage device controller, which connects Southbridge 135 to nonvolatile storage device 185 , such as a hard disk drive, using bus 184 .
- DMA Direct Memory Access
- PIC Programmable Interrupt Controller
- storage device controller which connects Southbridge 135 to nonvolatile storage device 185 , such as a hard disk drive, using bus 184 .
- ExpressCard 155 is a slot that connects hot-pluggable devices to the information handling system.
- ExpressCard 155 supports both PCI Express and USB connectivity as it connects to Southbridge 135 using both the Universal Serial Bus (USB) the PCI Express bus.
- Southbridge 135 includes USB Controller 140 that provides USB connectivity to devices that connect to the USB. These devices include webcam (camera) 150 , infrared (IR) receiver 148 , keyboard and trackpad 144 , and Bluetooth device 146 , which provides for wireless personal area networks (PANs).
- webcam camera
- IR infrared
- keyboard and trackpad 144 keyboard and trackpad 144
- Bluetooth device 146 which provides for wireless personal area networks (PANs).
- USB Controller 140 also provides USB connectivity to other miscellaneous USB connected devices 142 , such as a mouse, removable nonvolatile storage device 145 , modems, network cards, ISDN connectors, fax, printers, USB hubs, and many other types of USB connected devices. While removable nonvolatile storage device 145 is shown as a USB-connected device, removable nonvolatile storage device 145 could be connected using a different interface, such as a Firewire interface, etcetera.
- Wireless Local Area Network (LAN) device 175 connects to Southbridge 135 via the PCI or PCI Express bus 172 .
- LAN device 175 typically implements one of the IEEE 802.11 standards of over-the-air modulation techniques that all use the same protocol to wirelessly communicate between information handling system 100 and another computer system or device.
- Optical storage device 190 connects to Southbridge 135 using Serial ATA (SATA) bus 188 .
- Serial ATA adapters and devices communicate over a high-speed serial link.
- the Serial ATA bus also connects Southbridge 135 to other forms of storage devices, such as hard disk drives.
- Audio circuitry 160 such as a sound card, connects to Southbridge 135 via bus 158 .
- Audio circuitry 160 also provides functionality such as audio line-in and optical digital audio in port 162 , optical digital output and headphone jack 164 , internal speakers 166 , and internal microphone 168 .
- Ethernet controller 170 connects to Southbridge 135 using a bus, such as the PCI or PCI Express bus. Ethernet controller 170 connects information handling system 100 to a computer network, such as a Local Area Network (LAN), the Internet, and other public and private computer networks.
- LAN Local Area Network
- the Internet and other public and private computer networks.
- an information handling system may take many forms.
- an information handling system may take the form of a desktop, server, portable, laptop, notebook, mobile internet device, or other form factor computer or data processing system.
- an information handling system may take other form factors such as a personal digital assistant (PDA), a gaming device, ATM machine, a portable telephone device, a communication device or other devices that include a processor and memory.
- PDA personal digital assistant
- gaming device such as a gaming device, ATM machine, a portable telephone device, a communication device or other devices that include a processor and memory.
- FIG. 2 provides an extension of the information handling system environment shown in FIG. 1 to illustrate that the methods described herein can be performed on a wide variety of information handling systems that operate in a networked environment.
- Types of information handling systems range from small handheld devices, such as handheld computer/mobile telephone 210 to large mainframe systems, such as mainframe computer 270 .
- handheld computer 210 include personal digital assistants (PDAs), personal entertainment devices, such as MP3 players, portable televisions, and compact disc players.
- PDAs personal digital assistants
- Other examples of information handling systems include pen, or tablet, computer 220 , laptop, or notebook, computer 230 , workstation 240 , personal computer system 250 , and server 260 .
- Other types of information handling systems that are not individually shown in FIG. 2 are represented by information handling system 280 .
- the various information handling systems can be networked together using computer network 200 .
- Types of computer network that can be used to interconnect the various information handling systems include Local Area Networks (LANs), Wireless Local Area Networks (WLANs), the Internet, the Public Switched Telephone Network (PSTN), other wireless networks, and any other network topology that can be used to interconnect the information handling systems.
- Many of the information handling systems include nonvolatile data stores, such as hard drives and/or nonvolatile memory.
- Some of the information handling systems shown in FIG. 2 depicts separate nonvolatile data stores (server 260 utilizes nonvolatile data store 265 , mainframe computer 270 utilizes nonvolatile data store 275 , and information handling system 280 utilizes nonvolatile data store 285 ).
- the nonvolatile data store can be a component that is external to the various information handling systems or can be internal to one of the information handling systems.
- removable nonvolatile storage device 145 can be shared among two or more information handling systems using various techniques, such as connecting the removable nonvolatile storage device 145 to a USB port or other connector of the information handling systems.
- FIG. 3 is a high level diagram showing interaction of the processes and entities used to provide concurrent long spanning edit sessions using change lists with explicit assumptions.
- Requestor 310 submits requests to change management system 350 for processing.
- the requests are transmitted to change management system 350 from an information handling system utilized by the requestor via computer network 200 .
- the computer network facilitates communication between the requestors, that change management system, and systems 360 .
- Systems 360 are a set of factors that change assumptions included with the request are checked against for validity. As shown, these systems include external factors (external systems 370 ) and internal factors (internal systems 380 ).
- the change request includes change list 320 which is metadata about the change request, change assumptions 330 , and the actual changes 340 .
- Change management system 350 reads the change assumptions and uses the change assumptions to check the external and internal factors.
- Internal factors correspond to internal systems 380 and can automatically be checked using software that queries the internal systems based on the change assumptions.
- External factors correspond to external systems 370 , such as approval by a decision maker, etc.
- some of the external systems have the authority to modify change assumptions. For example, in a purchasing scenario, an internal change assumption may be that the requested item can be purchased if the price is below an assumed threshold.
- An external system such as a manager, may have the authority to change the internal change assumption (e.g., raise or lower the price threshold).
- both the external and internal systems can provide reasons for both approving, and rejecting, a change assumption.
- each of the internal change assumptions is checked each time one of the external systems is checked. For example, if three levels of management approval (external systems) are required, each of the internal change assumptions are checked after each of the approvals is given. In this manner, the internal systems can take into account changes that have occurred between submissions as well as take into account any modifications made to the change assumptions by any of the external systems.
- Change management system 350 receives approvals, denials, modified assumptions, and reasons from systems 360 . Based on the received information, change management system 350 generates responses, such as approval to perform the changes and rejections to the change request. If each of the change assumptions included in the change request is valid, then the changes are processed (e.g., a requested file is updated, a requested item is purchased, etc.). On the other hand, if any one of the change assumptions is invalid, then the change is rejected. In one embodiment, rejected change requests are retained in a data store of pending requests.
- rejected change requests are re-submitted on a periodic basis (e.g., daily, weekly, monthly, etc.) until the request expires or until the invalid assumption(s) become(s) valid (for example, a manager rejection is changed to an approval) and the included changes are processed.
- a counter is maintained of the number of times a change request has been processed.
- the change request is removed from the data store of pending changes (deleted) when the counter reaches a predetermined limit (e.g., after three submissions, etc.).
- FIG. 4 is a flowchart showing steps taken by a requestor of a change request. Processing commences at 400 whereupon, at step 410 , the requestor specifies a list of changes being requested to be applied atomically as a set. The list of changes is stored in memory area 420 . At step 430 , the requestor specifies a list of change assumptions and these change assumptions are stored in memory area 440 .
- the change assumptions include both internal change assumptions and external change assumptions. Also, in one embodiment, each of the change assumptions must be met (be valid) before any of the changes stored in memory area 420 are processed.
- the list of change assumptions may be generated or augmented automatically (for example, the system may see that a particular variable value is being changed, and may add an assumption that the current value of that variable is the value at the time the change request was created).
- the requestor specifies metadata for the change list which is stored in memory area 320 .
- Metadata can include the requestor's information (e.g., name, identifier, contact information, etc.), a change narrative that describes the change request that is being submitted, an active time period during which the change request can be processed, and a number of retries value that provides a predetermined limit on the number of times the change request should be retried before removing the change request from the change request management system.
- the change request is packaged into change request data store 480 (e.g., a computer file).
- the packaging process packages the specified list of changes, the list of assumptions, and the specified metadata into change request data store 480 .
- the change request (change request data store 480 ) is transmitted to the change request management system via computer network 200 .
- Predefined process 495 details the processing performed by the change request management system when the change request is received (see FIG. 5 and corresponding text for processing details).
- FIG. 5 is a flowchart showing steps taken by a change request management system. Processing performed by the change request management system commences at 500 whereupon, at step 510 , the change request management system receives change request 480 from a requestor. As shown, change request 480 includes the metadata, assumptions, and changes that were specified by the requestor. At step 520 , the received request is compared with request submission rules 530 in order to determine if the change request is valid. For example, an organization could establish that only employees with a certain level can make various types of requests. If the requestor is not one of these employees, then the request would be denied. A determination is made as to whether the request is valid based on the comparison with the request submission rules (decision 540 ).
- decision 540 branches to the “no” branch whereupon, at step 560 , an error is returned to the requestor informing the requestor that the request was denied and will not be processed.
- decision 540 branches to the “yes” branch whereupon, at step 550 , the received request is stored in data store of pending requests 480 .
- the change request management system processes the requests stored in data store 480 .
- the first change request stored in data store 480 that is ready for processing is selected.
- a request is “ready for processing” based upon its metadata. For example, a pending request may have been previously rejected and is scheduled for weekly re-submission, in which case the pending request will not be selected at step 570 until a week has passed.
- the assumptions included in the selected request are analyzed and the change request is processed (see FIG. 6 and corresponding text for processing details). A determination is made as to whether there are more requests that are ready to be processed (decision 580 ).
- decision 580 branches to the “yes” branch which loops back to select the next request that is ready to be processed from data store 480 and processes it using predefined process 575 . This looping continues until there are no more requests in data store 480 that are ready to be processed, at which point decision 580 branches to the “no” branch whereupon, at step 590 , processing waits for the next new request to arrive or for a given time interval (e.g., hourly, daily, etc.). If the time interval is reached, then step 590 branches to the “time interval” branch which loops back to process the requests pending in data store 480 . If a new request is received, then step 590 branches to the “new request” branch which loops back to receive the next request and process it as described above.
- time interval e.g., hourly, daily, etc.
- FIG. 6 is a flowchart showing steps taken to analyze request assumptions. This routine is called at predefined process 575 shown in FIG. 5 .
- FIG. 6 processing commences at 600 whereupon, at step 605 , change list metadata 320 is checked in order to identify if the request has expired based on the active time period. A determination is made as to whether the request is still active (decision 610 ). If the request is no longer active, decision 610 branches to the “no” branch whereupon, at step 615 , the request is deleted from the data store of pending requests, and at step 620 , the requestor is notified that the request has expired and has been deleted from the data store of pending requests.
- decision 610 branches to the “yes” branch whereupon a determination is made as to whether there are any internal assumptions included with the request (decision 625 ). If there are one or more internal assumptions, then decision 625 branches to the “yes” branch whereupon, at predefined process 630 , the internal assumptions included in assumptions 440 are processed (see FIG. 7 and corresponding text for processing details). On the other hand, if there are no internal assumptions included in the request, then decision 625 branches to the “no” branch bypassing predefined process 630 .
- the processing of the change request is different depending upon the type of change being performed (e.g., document control, procurement, etc.). However, when the change request is processed, the executed change is recorded in data store 655 and the request is deleted from the list of active requests at step 658 . On the other hand, if there are more external assumptions, then decision 640 branches to the “yes” branch whereupon predefined process 660 is executed to select the first external assumption from assumptions 440 and check it for validity (see FIG. 8 and corresponding text for external assumption processing details).
- decision 635 will branch to the “yes” branch and, if there are more external assumptions to check, decision 640 will branch to the “yes” branch to select and check the next external assumption for validity and then loop back around to again to recheck whether the request is still active and recheck the internal assumptions. This selection and checking of external assumptions and looping to recheck whether the request is active and recheck the internal assumptions continues until all of the external assumptions have been selected and checked. When there are no more external assumptions to check and all external assumptions and internal assumptions are valid, then decision 640 branches to the “no” branch whereupon, at step 650 , the change list included in the change request is processed.
- FIG. 7 is a flowchart showing steps taken to check internal assumptions. This routine is called by predefined process 630 shown in FIG. 6 . Processing of FIG. 7 commences at 700 whereupon, at step 710 , the first internal assumption is selected from assumptions 440 . At step 720 , the selected internal assumption is checked by querying it against various internal systems 380 . At step 730 , one or more responses are received from the internal systems. A determination is made, based on the received responses, as to whether the selected internal assumption is valid (decision 740 ). If the selected internal assumption is not valid, then decision 740 branches to the “no” branch whereupon, at step 750 , the invalid assumption is recorded in invalid assumptions memory area 760 .
- decision 770 A determination is made as to whether the system is set to gather a list of all invalid internal assumptions or whether to stop after one invalid internal assumption is identified (decision 770 ). If processing stops after the first invalid internal assumption is encountered, then decision 770 branches to the “no” branch leading to decision 780 described below, otherwise processing of the list of internal assumptions continues with decision 770 branching to the “yes” branch.
- decision 740 if the selected internal assumption is valid, then decision 740 branches to the “yes” branch bypassing step 750 and decision 770 .
- a determination is made as to whether there are more internal assumptions to check (decision 775 ). If there are more internal assumptions to check, then decision 775 branches to the “yes” branch which loops back to step 710 to select the next internal assumption from assumptions 440 . This looping continues until all of the internal assumptions have been processed, at which point decision 775 branches to the “no” branch leading to decision 780 .
- FIG. 8 is a flowchart showing steps taken to check external assumptions. This routine is called by predefined process 660 shown in FIG. 6 .
- FIG. 8 processing commences at 800 whereupon, at step 810 , the first external assumption is selected from assumptions 440 .
- the selected external assumption is checked against one or more external systems 370 (e.g., external sources such as by sending a note to a manager for approval, etc.).
- a response is received from the external source(s).
- FIG. 9 is a flowchart showing steps taken when a request is rejected for any reason other than because the request is invalid.
- This routine is called by predefined process 680 shown in FIG. 6 .
- FIG. 9 processing commences at 900 whereupon, at step 910 message 970 (e.g., an email note, etc.) is prepared to the requestor with the message including the reasons that one or more of the internal and/or external assumptions were invalid as recorded in invalid assumptions memory area 760 .
- a counter that tracks the number of times that this request has been rejected is incremented.
- the incremented counter is compared to a predefined limit, such as a limit provided by the requestor in request metadata 320 .
- request rejection message 970 is sent to requestor 310 .
- the requestor now has reasons for the rejection as well as knowledge of whether the request has been removed from the data store of pending requests. The requestor can analyze these reasons and determine if changes should be made to the request (or if a new request should be created using steps shown in FIG. 4 ) and resubmitted to the change request management system shown in FIG. 3 .
- each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s).
- the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.
- One of the implementations of the invention is a client application, namely, a set of instructions (program code) or other functional descriptive material in a code module that may, for example, be resident in the random access memory of the computer.
- the set of instructions may be stored in another computer memory, for example, in a hard disk drive, or in a removable memory such as an optical disk (for eventual use in a CD ROM) or floppy disk (for eventual use in a floppy disk drive).
- the present invention may be implemented as a computer program product for use in a computer.
- Functional descriptive material is information that imparts functionality to a machine.
- Functional descriptive material includes, but is not limited to, computer programs, instructions, rules, facts, definitions of computable functions, objects, and data structures.
Abstract
An approach is provided that receives a change request from a requestor. The change request includes metadata regarding the change, one or more changes, and one or more change assumptions corresponding to at least one of the changes. The change request is stored in a data store of pending requests. One or more systems are identified that correspond to each of the change assumptions. The identified systems are automatically queried with queries that correspond to the change assumptions. Query responses in response to the querying are received from the identified systems. The validity of each of the change assumptions is determined based on the received query responses. If the change assumptions are valid, then the changes included in the change request are processed. On the other hand, if at least one of the change assumptions is invalid, then the change request is rejected.
Description
- This application is a continuation of U.S. application Ser. No. 12/770,824, filed Apr. 30, 2010, titled “Concurrent Long Spanning Edit Sessions Using Change Lists with Explicit Assumptions,” and having the same inventors as the above-referenced application.
- Information handling systems often include object models that can be edited by multiple users. Conflicts can arise when conflicting submissions are received that pertain to a common object. Locking objects is infeasible and overly burdensome when object editing sessions lasts a relatively long period of time. Conversely, simply allowing concurrent edits of the same object can introduce many conflicts that can be difficult, or even impossible, to identify and resolve.
- An approach is provided that receives a change request from a requestor.
- The change request includes metadata regarding the change, one or more changes, and one or more change assumptions corresponding to at least one of the changes. The change request is stored in a data store of pending requests. One or more systems are identified that correspond to each of the change assumptions. The identified systems are automatically queried with queries that correspond to the change assumptions. Query responses in response to the querying are received from the identified systems. The validity of each of the change assumptions is determined based on the received query responses. If the change assumptions are valid, then the changes included in the change request are processed. On the other hand, if at least one of the change assumptions is invalid, then the change request is rejected.
- The foregoing is a summary and thus contains, by necessity, simplifications, generalizations, and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the present invention, as defined solely by the claims, will become apparent in the non-limiting detailed description set forth below.
- The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings, wherein:
-
FIG. 1 is a block diagram of a data processing system in which the methods described herein can be implemented; -
FIG. 2 provides an extension of the information handling system environment shown inFIG. 1 to illustrate that the methods described herein can be performed on a wide variety of information handling systems which operate in a networked environment; -
FIG. 3 is a high level diagram showing interaction of the processes and entities used to provide concurrent long spanning edit sessions using changelists with explicit assumptions; -
FIG. 4 is a flowchart showing steps taken by a requestor of a change request; -
FIG. 5 is a flowchart showing steps taken by a change request management system; -
FIG. 6 is a flowchart showing steps taken to analyze request assumptions; -
FIG. 7 is a flowchart showing steps taken to check internal assumptions; -
FIG. 8 is a flowchart showing steps taken to check external assumptions; and -
FIG. 9 is a flowchart showing steps taken when a request is rejected. - As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
- Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
- A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
- Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
- Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
- Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions.
- These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
- These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
- The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
- Certain specific details are set forth in the following description and figures to provide a thorough understanding of various embodiments of the invention. Certain well-known details often associated with computing and software technology are not set forth in the following disclosure, however, to avoid unnecessarily obscuring the various embodiments of the invention. Further, those of ordinary skill in the relevant art will understand that they can practice other embodiments of the invention without one or more of the details described below. Finally, while various methods are described with reference to steps and sequences in the following disclosure, the description as such is for providing a clear implementation of embodiments of the invention, and the steps and sequences of steps should not be taken as required to practice this invention. Instead, the following is intended to provide a detailed description of an example of the invention and should not be taken to be limiting of the invention itself. Rather, any number of variations may fall within the scope of the invention, which is defined by the claims that follow the description.
- The following detailed description will generally follow the summary of the invention, as set forth above, further explaining and expanding the definitions of the various aspects and embodiments of the invention as necessary. To this end, this detailed description first sets forth a computing environment in
FIG. 1 that is suitable to implement the software and/or hardware techniques associated with the invention. A networked environment is illustrated inFIG. 2 as an extension of the basic computing environment, to emphasize that modern computing techniques can be performed across multiple discrete devices. -
FIG. 1 illustratesinformation handling system 100, which is a simplified example of a computer system capable of performing the computing operations described herein.Information handling system 100 includes one ormore processors 110 coupled toprocessor interface bus 112.Processor interface bus 112 connectsprocessors 110 to Northbridge 115, which is also known as the Memory Controller Hub (MCH). Northbridge 115 connects tosystem memory 120 and provides a means for processor(s) 110 to access the system memory.Graphics controller 125 also connects toNorthbridge 115. In one embodiment,PCI Express bus 118 connectsNorthbridge 115 tographics controller 125.Graphics controller 125 connects to displaydevice 130, such as a computer monitor. -
Northbridge 115 andSouthbridge 135 connect to each other usingbus 119. - In one embodiment, the bus is a Direct Media Interface (DMI) bus that transfers data at high speeds in each direction between
Northbridge 115 andSouthbridge 135. In another embodiment, a Peripheral Component Interconnect (PCI) bus connects the Northbridge and the Southbridge.Southbridge 135, also known as the I/O Controller Hub (ICH) is a chip that generally implements capabilities that operate at slower speeds than the capabilities provided by the Northbridge.Southbridge 135 typically provides various busses used to connect various components. These busses include, for example, PCI and PCI Express busses, an ISA bus, a System Management Bus (SMBus or SMB), and/or a Low Pin Count (LPC) bus. The LPC bus often connects low-bandwidth devices, such asboot ROM 196 and “legacy” I/O devices (using a “super I/O” chip). The “legacy” I/O devices (198) can include, for example, serial and parallel ports, keyboard, mouse, and/or a floppy disk controller. The LPC bus also connectsSouthbridge 135 to Trusted Platform Module (TPM) 195. Other components often included inSouthbridge 135 include a Direct Memory Access (DMA) controller, a Programmable Interrupt Controller (PIC), and a storage device controller, which connectsSouthbridge 135 tononvolatile storage device 185, such as a hard disk drive, usingbus 184. -
ExpressCard 155 is a slot that connects hot-pluggable devices to the information handling system.ExpressCard 155 supports both PCI Express and USB connectivity as it connects toSouthbridge 135 using both the Universal Serial Bus (USB) the PCI Express bus.Southbridge 135 includes USB Controller 140 that provides USB connectivity to devices that connect to the USB. These devices include webcam (camera) 150, infrared (IR)receiver 148, keyboard andtrackpad 144, andBluetooth device 146, which provides for wireless personal area networks (PANs). USB Controller 140 also provides USB connectivity to other miscellaneous USB connecteddevices 142, such as a mouse, removablenonvolatile storage device 145, modems, network cards, ISDN connectors, fax, printers, USB hubs, and many other types of USB connected devices. While removablenonvolatile storage device 145 is shown as a USB-connected device, removablenonvolatile storage device 145 could be connected using a different interface, such as a Firewire interface, etcetera. - Wireless Local Area Network (LAN)
device 175 connects to Southbridge 135 via the PCI orPCI Express bus 172.LAN device 175 typically implements one of the IEEE 802.11 standards of over-the-air modulation techniques that all use the same protocol to wirelessly communicate betweeninformation handling system 100 and another computer system or device.Optical storage device 190 connects toSouthbridge 135 using Serial ATA (SATA)bus 188. Serial ATA adapters and devices communicate over a high-speed serial link. The Serial ATA bus also connectsSouthbridge 135 to other forms of storage devices, such as hard disk drives.Audio circuitry 160, such as a sound card, connects toSouthbridge 135 viabus 158.Audio circuitry 160 also provides functionality such as audio line-in and optical digital audio inport 162, optical digital output andheadphone jack 164,internal speakers 166, andinternal microphone 168.Ethernet controller 170 connects toSouthbridge 135 using a bus, such as the PCI or PCI Express bus.Ethernet controller 170 connectsinformation handling system 100 to a computer network, such as a Local Area Network (LAN), the Internet, and other public and private computer networks. - While
FIG. 1 shows one information handling system, an information handling system may take many forms. For example, an information handling system may take the form of a desktop, server, portable, laptop, notebook, mobile internet device, or other form factor computer or data processing system. In addition, an information handling system may take other form factors such as a personal digital assistant (PDA), a gaming device, ATM machine, a portable telephone device, a communication device or other devices that include a processor and memory. -
FIG. 2 provides an extension of the information handling system environment shown inFIG. 1 to illustrate that the methods described herein can be performed on a wide variety of information handling systems that operate in a networked environment. Types of information handling systems range from small handheld devices, such as handheld computer/mobile telephone 210 to large mainframe systems, such asmainframe computer 270. Examples ofhandheld computer 210 include personal digital assistants (PDAs), personal entertainment devices, such as MP3 players, portable televisions, and compact disc players. Other examples of information handling systems include pen, or tablet,computer 220, laptop, or notebook,computer 230,workstation 240,personal computer system 250, andserver 260. Other types of information handling systems that are not individually shown inFIG. 2 are represented byinformation handling system 280. As shown, the various information handling systems can be networked together usingcomputer network 200. Types of computer network that can be used to interconnect the various information handling systems include Local Area Networks (LANs), Wireless Local Area Networks (WLANs), the Internet, the Public Switched Telephone Network (PSTN), other wireless networks, and any other network topology that can be used to interconnect the information handling systems. Many of the information handling systems include nonvolatile data stores, such as hard drives and/or nonvolatile memory. Some of the information handling systems shown inFIG. 2 depicts separate nonvolatile data stores (server 260 utilizesnonvolatile data store 265,mainframe computer 270 utilizesnonvolatile data store 275, andinformation handling system 280 utilizes nonvolatile data store 285). The nonvolatile data store can be a component that is external to the various information handling systems or can be internal to one of the information handling systems. In addition, removablenonvolatile storage device 145 can be shared among two or more information handling systems using various techniques, such as connecting the removablenonvolatile storage device 145 to a USB port or other connector of the information handling systems. -
FIG. 3 is a high level diagram showing interaction of the processes and entities used to provide concurrent long spanning edit sessions using change lists with explicit assumptions.Requestor 310 submits requests to changemanagement system 350 for processing. In one embodiment, the requests are transmitted tochange management system 350 from an information handling system utilized by the requestor viacomputer network 200. In this embodiment, the computer network facilitates communication between the requestors, that change management system, andsystems 360.Systems 360 are a set of factors that change assumptions included with the request are checked against for validity. As shown, these systems include external factors (external systems 370) and internal factors (internal systems 380). The change request includeschange list 320 which is metadata about the change request, changeassumptions 330, and theactual changes 340. -
Change management system 350 reads the change assumptions and uses the change assumptions to check the external and internal factors. Internal factors correspond tointernal systems 380 and can automatically be checked using software that queries the internal systems based on the change assumptions. External factors correspond toexternal systems 370, such as approval by a decision maker, etc. In addition, in one embodiment, some of the external systems have the authority to modify change assumptions. For example, in a purchasing scenario, an internal change assumption may be that the requested item can be purchased if the price is below an assumed threshold. An external system, such as a manager, may have the authority to change the internal change assumption (e.g., raise or lower the price threshold). In addition, both the external and internal systems can provide reasons for both approving, and rejecting, a change assumption. In one embodiment, each of the internal change assumptions is checked each time one of the external systems is checked. For example, if three levels of management approval (external systems) are required, each of the internal change assumptions are checked after each of the approvals is given. In this manner, the internal systems can take into account changes that have occurred between submissions as well as take into account any modifications made to the change assumptions by any of the external systems. -
Change management system 350 receives approvals, denials, modified assumptions, and reasons fromsystems 360. Based on the received information,change management system 350 generates responses, such as approval to perform the changes and rejections to the change request. If each of the change assumptions included in the change request is valid, then the changes are processed (e.g., a requested file is updated, a requested item is purchased, etc.). On the other hand, if any one of the change assumptions is invalid, then the change is rejected. In one embodiment, rejected change requests are retained in a data store of pending requests. In this embodiment, rejected change requests are re-submitted on a periodic basis (e.g., daily, weekly, monthly, etc.) until the request expires or until the invalid assumption(s) become(s) valid (for example, a manager rejection is changed to an approval) and the included changes are processed. In one embodiment, a counter is maintained of the number of times a change request has been processed. In this embodiment, the change request is removed from the data store of pending changes (deleted) when the counter reaches a predetermined limit (e.g., after three submissions, etc.). -
FIG. 4 is a flowchart showing steps taken by a requestor of a change request. Processing commences at 400 whereupon, atstep 410, the requestor specifies a list of changes being requested to be applied atomically as a set. The list of changes is stored inmemory area 420. At step 430, the requestor specifies a list of change assumptions and these change assumptions are stored inmemory area 440. In one embodiment, the change assumptions include both internal change assumptions and external change assumptions. Also, in one embodiment, each of the change assumptions must be met (be valid) before any of the changes stored inmemory area 420 are processed. Finally, in another embodiment, the list of change assumptions may be generated or augmented automatically (for example, the system may see that a particular variable value is being changed, and may add an assumption that the current value of that variable is the value at the time the change request was created). - At
step 450, the requestor specifies metadata for the change list which is stored inmemory area 320. Metadata can include the requestor's information (e.g., name, identifier, contact information, etc.), a change narrative that describes the change request that is being submitted, an active time period during which the change request can be processed, and a number of retries value that provides a predetermined limit on the number of times the change request should be retried before removing the change request from the change request management system. - At
step 470, the change request is packaged into change request data store 480 (e.g., a computer file). The packaging process packages the specified list of changes, the list of assumptions, and the specified metadata into changerequest data store 480. Atstep 490, the change request (change request data store 480) is transmitted to the change request management system viacomputer network 200.Predefined process 495 details the processing performed by the change request management system when the change request is received (seeFIG. 5 and corresponding text for processing details). -
FIG. 5 is a flowchart showing steps taken by a change request management system. Processing performed by the change request management system commences at 500 whereupon, atstep 510, the change request management system receiveschange request 480 from a requestor. As shown,change request 480 includes the metadata, assumptions, and changes that were specified by the requestor. Atstep 520, the received request is compared withrequest submission rules 530 in order to determine if the change request is valid. For example, an organization could establish that only employees with a certain level can make various types of requests. If the requestor is not one of these employees, then the request would be denied. A determination is made as to whether the request is valid based on the comparison with the request submission rules (decision 540). If the request is not valid, thendecision 540 branches to the “no” branch whereupon, atstep 560, an error is returned to the requestor informing the requestor that the request was denied and will not be processed. On the other hand, if the request is valid, thendecision 540 branches to the “yes” branch whereupon, atstep 550, the received request is stored in data store of pendingrequests 480. - Periodically, the change request management system processes the requests stored in
data store 480. Atstep 570, the first change request stored indata store 480 that is ready for processing is selected. A request is “ready for processing” based upon its metadata. For example, a pending request may have been previously rejected and is scheduled for weekly re-submission, in which case the pending request will not be selected atstep 570 until a week has passed. At predefined process 575, the assumptions included in the selected request are analyzed and the change request is processed (seeFIG. 6 and corresponding text for processing details). A determination is made as to whether there are more requests that are ready to be processed (decision 580). If there are more requests ready to be processed, thendecision 580 branches to the “yes” branch which loops back to select the next request that is ready to be processed fromdata store 480 and processes it using predefined process 575. This looping continues until there are no more requests indata store 480 that are ready to be processed, at whichpoint decision 580 branches to the “no” branch whereupon, at step 590, processing waits for the next new request to arrive or for a given time interval (e.g., hourly, daily, etc.). If the time interval is reached, then step 590 branches to the “time interval” branch which loops back to process the requests pending indata store 480. If a new request is received, then step 590 branches to the “new request” branch which loops back to receive the next request and process it as described above. -
FIG. 6 is a flowchart showing steps taken to analyze request assumptions. This routine is called at predefined process 575 shown inFIG. 5 .FIG. 6 processing commences at 600 whereupon, atstep 605,change list metadata 320 is checked in order to identify if the request has expired based on the active time period. A determination is made as to whether the request is still active (decision 610). If the request is no longer active,decision 610 branches to the “no” branch whereupon, atstep 615, the request is deleted from the data store of pending requests, and atstep 620, the requestor is notified that the request has expired and has been deleted from the data store of pending requests. - On the other hand, if the request is still active, then
decision 610 branches to the “yes” branch whereupon a determination is made as to whether there are any internal assumptions included with the request (decision 625). If there are one or more internal assumptions, thendecision 625 branches to the “yes” branch whereupon, at predefined process 630, the internal assumptions included inassumptions 440 are processed (seeFIG. 7 and corresponding text for processing details). On the other hand, if there are no internal assumptions included in the request, thendecision 625 branches to the “no” branch bypassing predefined process 630. - A determination is made as to whether the internal assumptions (if any were checked) are valid (decision 635). If one or more of the internal assumptions are invalid, then
decision 635 branches to the “no” branch whereupon, atpredefined process 680, the request is rejected (seeFIG. 9 and corresponding text for rejection processing details). On the other hand, if the internal assumptions are valid, thendecision 635 branches to the “yes” branch whereupon a determination is made as to whether there are any external assumptions that need to be checked (decision 640). If there are no external assumptions to be checked, thendecision 640 branches to the “no” branch whereupon, atstep 650, the assumptions are valid and the change list included in the change request is processed. The processing of the change request is different depending upon the type of change being performed (e.g., document control, procurement, etc.). However, when the change request is processed, the executed change is recorded indata store 655 and the request is deleted from the list of active requests atstep 658. On the other hand, if there are more external assumptions, thendecision 640 branches to the “yes” branch whereuponpredefined process 660 is executed to select the first external assumption fromassumptions 440 and check it for validity (seeFIG. 8 and corresponding text for external assumption processing details). - A determination is made as to whether the selected external assumption was invalid (decision 670). If the selected external assumption is invalid, then
decision 670 branches to the “yes” branch whereupon, atpredefined process 680, the request is rejected (seeFIG. 9 and corresponding text for rejection processing details). On the other hand, if the selected external assumption is not invalid, thendecision 670 branches to the “no” branch which loops back to step 605 to recheck whether the request is still active and recheck the internal assumptions. In one embodiment, the internal assumptions are rechecked after each external assumption is selected and determined to be valid. If the internal assumptions are still valid, thendecision 635 will branch to the “yes” branch and, if there are more external assumptions to check,decision 640 will branch to the “yes” branch to select and check the next external assumption for validity and then loop back around to again to recheck whether the request is still active and recheck the internal assumptions. This selection and checking of external assumptions and looping to recheck whether the request is active and recheck the internal assumptions continues until all of the external assumptions have been selected and checked. When there are no more external assumptions to check and all external assumptions and internal assumptions are valid, thendecision 640 branches to the “no” branch whereupon, atstep 650, the change list included in the change request is processed. -
FIG. 7 is a flowchart showing steps taken to check internal assumptions. This routine is called by predefined process 630 shown inFIG. 6 . Processing ofFIG. 7 commences at 700 whereupon, atstep 710, the first internal assumption is selected fromassumptions 440. At step 720, the selected internal assumption is checked by querying it against variousinternal systems 380. Atstep 730, one or more responses are received from the internal systems. A determination is made, based on the received responses, as to whether the selected internal assumption is valid (decision 740). If the selected internal assumption is not valid, thendecision 740 branches to the “no” branch whereupon, atstep 750, the invalid assumption is recorded in invalidassumptions memory area 760. A determination is made as to whether the system is set to gather a list of all invalid internal assumptions or whether to stop after one invalid internal assumption is identified (decision 770). If processing stops after the first invalid internal assumption is encountered, thendecision 770 branches to the “no” branch leading todecision 780 described below, otherwise processing of the list of internal assumptions continues withdecision 770 branching to the “yes” branch. - Returning to
decision 740, if the selected internal assumption is valid, thendecision 740 branches to the “yes”branch bypassing step 750 anddecision 770. A determination is made as to whether there are more internal assumptions to check (decision 775). If there are more internal assumptions to check, thendecision 775 branches to the “yes” branch which loops back to step 710 to select the next internal assumption fromassumptions 440. This looping continues until all of the internal assumptions have been processed, at whichpoint decision 775 branches to the “no” branch leading todecision 780. - A determination is made as to whether one or more invalid internal assumptions were identified during the processing of the internal assumptions list (decision 780). If no invalid internal assumptions were identified, then
decision 780 branches to the “no” branch whereupon processing returns at 790 with a flag indicating that the internal assumptions have been checked and are valid. On the other hand, if one or more of the internal assumptions are invalid, thendecision 780 branches to the “yes” branch whereupon processing returns at 795 with a flag indicating that one or more internal assumptions are invalid. -
FIG. 8 is a flowchart showing steps taken to check external assumptions. This routine is called bypredefined process 660 shown inFIG. 6 .FIG. 8 processing commences at 800 whereupon, atstep 810, the first external assumption is selected fromassumptions 440. At step 820 the selected external assumption is checked against one or more external systems 370 (e.g., external sources such as by sending a note to a manager for approval, etc.). Atstep 830, a response is received from the external source(s). - A determination is made as to whether the external systems have requested a modification of one or more of the assumptions included in
assumptions 440. If the external system has requested a modification of one or more of the assumptions, thendecision 840 branches to the “yes” branch whereupon a determination is made as to whether the external system has the authority to modify the requested assumption(s) (decision 850). If the external system has the needed authority, thendecision 850 branches to the “yes” branch whereupon the assumption(s) selected by the external system is modified atstep 860. Note that in one embodiment, the external system can modify both external and internal assumptions included inassumptions 440. On the other hand, if the external system does not have the authority needed to modify the selected assumption(s) thendecision 850 branches to the “no”branch bypassing step 860. - A determination is made as to whether the selected external assumption is valid (decision 870). If the selected external assumption is valid, then
decision 870 branches to the “yes” branch whereupon processing returns at 875 with a flag indicating that the external assumption is valid. On the other hand, if the selected external assumption is invalid, thendecision 870 branches to the “no” branch whereupon, atstep 880, the invalid external assumption is recorded in invalidassumptions memory area 760 along with any reasons provided by the external system for rejecting the external assumption. Processing then returns to the calling routine at 895 with a flag indicating that the external assumption is invalid. -
FIG. 9 is a flowchart showing steps taken when a request is rejected for any reason other than because the request is invalid. This routine is called bypredefined process 680 shown inFIG. 6 .FIG. 9 processing commences at 900 whereupon, at step 910 message 970 (e.g., an email note, etc.) is prepared to the requestor with the message including the reasons that one or more of the internal and/or external assumptions were invalid as recorded in invalidassumptions memory area 760. Atstep 920, a counter that tracks the number of times that this request has been rejected is incremented. Atstep 930, the incremented counter is compared to a predefined limit, such as a limit provided by the requestor inrequest metadata 320. A determination is made as to whether the counter exceeds the number of retries set by the predefined limit (decision 940). If the counter exceeds the number of retries set by the predefined, thendecision 940 branches to the “yes” branch whereupon, atstep 950, the request is removed from data store of pendingrequests 480. Atstep 960, a notice is added torejection message 970 informing the requestor that the request has been removed from the data store of pending requests due to the predefined retry limit being reached. Returning todecision 940, if the counter does not exceed the retries set by the predefined limit, thendecision 940 branches to the “no”branch bypassing steps - At
step 980,request rejection message 970 is sent torequestor 310. The requestor now has reasons for the rejection as well as knowledge of whether the request has been removed from the data store of pending requests. The requestor can analyze these reasons and determine if changes should be made to the request (or if a new request should be created using steps shown inFIG. 4 ) and resubmitted to the change request management system shown inFIG. 3 . - The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
- One of the implementations of the invention is a client application, namely, a set of instructions (program code) or other functional descriptive material in a code module that may, for example, be resident in the random access memory of the computer. Until required by the computer, the set of instructions may be stored in another computer memory, for example, in a hard disk drive, or in a removable memory such as an optical disk (for eventual use in a CD ROM) or floppy disk (for eventual use in a floppy disk drive). Thus, the present invention may be implemented as a computer program product for use in a computer. In addition, although the various methods described are conveniently implemented in a general purpose computer selectively activated or reconfigured by software, one of ordinary skill in the art would also recognize that such methods may be carried out in hardware, in firmware, or in more specialized apparatus constructed to perform the required method steps. Functional descriptive material is information that imparts functionality to a machine. Functional descriptive material includes, but is not limited to, computer programs, instructions, rules, facts, definitions of computable functions, objects, and data structures.
- While particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that, based upon the teachings herein, that changes and modifications may be made without departing from this invention and its broader aspects. Therefore, the appended claims are to encompass within their scope all such changes and modifications as are within the true spirit and scope of this invention. Furthermore, it is to be understood that the invention is solely defined by the appended claims. It will be understood by those with skill in the art that if a specific number of an introduced claim element is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation no such limitation is present. For non-limiting example, as an aid to understanding, the following appended claims contain usage of the introductory phrases “at least one” and “one or more” to introduce claim elements. However, the use of such phrases should not be construed to imply that the introduction of a claim element by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an”; the same holds true for the use in the claims of definite articles.
Claims (7)
1. A computer-implemented method comprising:
receiving a change request from a requestor, wherein the change request includes metadata regarding the change, one or more changes, and one or more change assumptions corresponding to at least one of the changes;
storing, in a nonvolatile storage medium, the request in a data store of pending requests;
identifying one or more systems that correspond to each of the change assumptions;
automatically querying one or more of the identified systems with one or more queries that correspond to the change assumptions;
receiving one or more query responses in response to the querying;
determining a validity, based on the received query responses, of each of the change assumptions;
processing the one or more changes included in the change request in response to determining that each of the change assumptions is valid; and
rejecting the change request in response to determining that at least one of the change assumptions is invalid.
2. The method of claim 1 wherein the change assumptions include one or more internal change assumptions and one or more external change assumptions, the method further comprising:
determining the validity, based on the received query responses, of each checking an external validity of each of the external change assumptions, wherein each of the external change assumptions is checked against an external source, wherein the processing of the one or more changes is performed in response to determining that each of the internal change assumptions and each of the external change assumptions is valid.
3. The method of claim 2 further comprising:
receiving, from one of the external sources, one or more assumption changes; and
modifying the one or more change assumptions based on the assumption changes received from the external source.
4. The method of claim 3 further comprising:
prior to modifying the one or more change assumptions, verifying that the external source from which the assumption change was received is authorized to modify the change assumptions corresponding to the received assumption changes, wherein the modification of the change assumptions is performed in response to the external source being verified.
5. The method of claim 2 further comprising:
re-determining the validity of each of the internal change assumptions after checking the external validity of each of the external change assumptions.
6. The method of claim 1 wherein the rejecting further comprises:
preparing a message that includes one or more reasons corresponding to sending the prepared message to the requestor.
7. The method of claim 6 further comprising:
incrementing a counter that tracks a number of times that the request has been rejected;
comparing the incremented counter with a predefined limit;
removing the request from the data store of pending requests in response to the comparison revealing that the request has been rejected the predefined limit of times; and
retaining the request in the data store of pending requests in response to the comparison revealing that the request has not been rejected the predefined limit of times, wherein the request is reprocessed after a predefined amount of time has passed.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/417,223 US20120173572A1 (en) | 2010-04-30 | 2012-03-10 | Concurrent Long Spanning Edit Sessions using Change Lists with Explicit Assumptions |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/770,824 US9390090B2 (en) | 2010-04-30 | 2010-04-30 | Concurrent long spanning edit sessions using change lists with explicit assumptions |
US13/417,223 US20120173572A1 (en) | 2010-04-30 | 2012-03-10 | Concurrent Long Spanning Edit Sessions using Change Lists with Explicit Assumptions |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/770,824 Continuation US9390090B2 (en) | 2010-04-30 | 2010-04-30 | Concurrent long spanning edit sessions using change lists with explicit assumptions |
Publications (1)
Publication Number | Publication Date |
---|---|
US20120173572A1 true US20120173572A1 (en) | 2012-07-05 |
Family
ID=44123152
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/770,824 Expired - Fee Related US9390090B2 (en) | 2010-04-30 | 2010-04-30 | Concurrent long spanning edit sessions using change lists with explicit assumptions |
US13/417,223 Abandoned US20120173572A1 (en) | 2010-04-30 | 2012-03-10 | Concurrent Long Spanning Edit Sessions using Change Lists with Explicit Assumptions |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/770,824 Expired - Fee Related US9390090B2 (en) | 2010-04-30 | 2010-04-30 | Concurrent long spanning edit sessions using change lists with explicit assumptions |
Country Status (2)
Country | Link |
---|---|
US (2) | US9390090B2 (en) |
WO (1) | WO2011134982A1 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10127019B2 (en) | 2017-03-08 | 2018-11-13 | Hartford Fire Insurance Company | System to coordinate source code module changes |
US10713261B2 (en) | 2013-03-13 | 2020-07-14 | Google Llc | Generating insightful connections between graph entities |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9798977B2 (en) * | 2014-06-09 | 2017-10-24 | Cognitive Scale, Inc. | Method for providing cognitive insights using cognitive agents |
US10445645B2 (en) | 2014-06-09 | 2019-10-15 | Cognitive Scale, Inc. | Cognitive agents for use within a cognitive environment |
CN107678775B (en) * | 2017-10-10 | 2021-02-09 | 中国航发控制系统研究所 | Environment initialization method of high-security software |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5778370A (en) | 1995-08-25 | 1998-07-07 | Emerson; Mark L. | Data village system |
US5826014A (en) * | 1996-02-06 | 1998-10-20 | Network Engineering Software | Firewall system for protecting network elements connected to a public network |
US6003082A (en) * | 1998-04-22 | 1999-12-14 | International Business Machines Corporation | Selective internet request caching and execution system |
US6275863B1 (en) | 1999-01-25 | 2001-08-14 | International Business Machines Corp. | System and method for programming and executing long running transactions |
US20020010715A1 (en) * | 2001-07-26 | 2002-01-24 | Garry Chinn | System and method for browsing using a limited display device |
US20040250259A1 (en) | 2003-06-04 | 2004-12-09 | Johannes Lauterbach | System and method for incremental object generation |
US7484011B1 (en) * | 2003-10-08 | 2009-01-27 | Cisco Technology, Inc. | Apparatus and method for rate limiting and filtering of HTTP(S) server connections in embedded systems |
US20060155716A1 (en) | 2004-12-23 | 2006-07-13 | Microsoft Corporation | Schema change governance for identity store |
US7827206B2 (en) * | 2005-11-03 | 2010-11-02 | International Business Machines Corporation | System and method for managing changes to business rules |
US8161078B2 (en) | 2006-09-20 | 2012-04-17 | Microsoft Corporation | Electronic data interchange (EDI) data dictionary management and versioning system |
JP5178341B2 (en) * | 2008-06-23 | 2013-04-10 | パナソニック株式会社 | Secure boot with optional components |
-
2010
- 2010-04-30 US US12/770,824 patent/US9390090B2/en not_active Expired - Fee Related
-
2011
- 2011-04-27 WO PCT/EP2011/056628 patent/WO2011134982A1/en active Application Filing
-
2012
- 2012-03-10 US US13/417,223 patent/US20120173572A1/en not_active Abandoned
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10713261B2 (en) | 2013-03-13 | 2020-07-14 | Google Llc | Generating insightful connections between graph entities |
US10127019B2 (en) | 2017-03-08 | 2018-11-13 | Hartford Fire Insurance Company | System to coordinate source code module changes |
US10635410B2 (en) * | 2017-03-08 | 2020-04-28 | Hartford Fire Insurance Company | System to coordinate source code module changes |
Also Published As
Publication number | Publication date |
---|---|
WO2011134982A1 (en) | 2011-11-03 |
US9390090B2 (en) | 2016-07-12 |
US20110270805A1 (en) | 2011-11-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8260715B2 (en) | Software license usage amongst workgroups using software usage data | |
US8955153B2 (en) | Privacy control in a social network | |
US20140149322A1 (en) | Protecting Contents in a Content Management System by Automatically Determining the Content Security Level | |
US20130185807A1 (en) | End User License Agreement Detection and Monitoring | |
US9390090B2 (en) | Concurrent long spanning edit sessions using change lists with explicit assumptions | |
US9411974B2 (en) | Managing document revisions | |
US20110270602A1 (en) | Opening A Message Catalog File For a Language That Is Not Installed | |
CN110244963B (en) | Data updating method and device and terminal equipment | |
US8468305B2 (en) | Data processing method for removable storage medium and data processing device | |
US9785724B2 (en) | Secondary queue for index process | |
US20120011083A1 (en) | Product-Centric Automatic Software Identification in z/OS Systems | |
US20150156132A1 (en) | Determining Available User Interface Functionality Based on Backend Server Load | |
US8527446B2 (en) | Information integrity rules framework | |
US9201937B2 (en) | Rapid provisioning of information for business analytics | |
CN109472540B (en) | Service processing method and device | |
US9003364B2 (en) | Overriding system attributes and function returns in a software subsystem | |
US10673863B2 (en) | Managing inter-object operations in a domain role-based access control (RBAC) system | |
US11023479B2 (en) | Managing asynchronous analytics operation based on communication exchange | |
US9323934B2 (en) | Managing and tracking commands associated with a change on a computer system | |
US20120265691A1 (en) | Visualizing and Managing Complex Scheduling Constraints | |
US20140074870A1 (en) | Combining Problem and Solution Artifacts | |
US11113378B2 (en) | Content-based authentication | |
US8429127B2 (en) | Circumventing queue downtime in a queue damage scenario | |
US9378225B2 (en) | Core service build / deployment for hierarchical database | |
US8271406B2 (en) | Computing mixed-integer program solutions using multiple starting vectors |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |