WO1996017296A1 - Methods and apparatus for implementing a message driven processor in a client-server environment - Google Patents
Methods and apparatus for implementing a message driven processor in a client-server environment Download PDFInfo
- Publication number
- WO1996017296A1 WO1996017296A1 PCT/US1995/015432 US9515432W WO9617296A1 WO 1996017296 A1 WO1996017296 A1 WO 1996017296A1 US 9515432 W US9515432 W US 9515432W WO 9617296 A1 WO9617296 A1 WO 9617296A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- client
- message
- request
- server
- information
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims description 172
- 230000008569 process Effects 0.000 claims description 152
- 238000012545 processing Methods 0.000 claims description 51
- 238000004891 communication Methods 0.000 claims description 25
- 238000003860 storage Methods 0.000 claims description 17
- 230000003068 static effect Effects 0.000 claims description 16
- 230000004044 response Effects 0.000 claims description 12
- 238000012360 testing method Methods 0.000 claims description 12
- 230000009471 action Effects 0.000 claims description 5
- 238000013507 mapping Methods 0.000 claims description 5
- 238000010998 test method Methods 0.000 claims description 5
- 238000004806 packaging method and process Methods 0.000 claims description 4
- 238000012544 monitoring process Methods 0.000 claims description 2
- 241000269627 Amphiuma means Species 0.000 claims 2
- 230000006870 function Effects 0.000 description 27
- 239000003795 chemical substances by application Substances 0.000 description 22
- 238000011161 development Methods 0.000 description 22
- 238000007726 management method Methods 0.000 description 19
- 230000008901 benefit Effects 0.000 description 15
- 238000013461 design Methods 0.000 description 7
- 101001074449 Crotalus durissus terrificus Phospholipase A2 inhibitor CNF Proteins 0.000 description 4
- 238000000354 decomposition reaction Methods 0.000 description 4
- 230000000977 initiatory effect Effects 0.000 description 4
- 230000010354 integration Effects 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 4
- 238000004088 simulation Methods 0.000 description 4
- 230000001360 synchronised effect Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 238000010348 incorporation Methods 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 238000012423 maintenance Methods 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 150000001875 compounds Chemical class 0.000 description 2
- 238000013523 data management Methods 0.000 description 2
- 238000011156 evaluation Methods 0.000 description 2
- 238000005111 flow chemistry technique Methods 0.000 description 2
- 230000002452 interceptive effect Effects 0.000 description 2
- 230000001737 promoting effect Effects 0.000 description 2
- 238000011084 recovery Methods 0.000 description 2
- 238000012549 training Methods 0.000 description 2
- 238000013519 translation Methods 0.000 description 2
- 230000014616 translation Effects 0.000 description 2
- 238000012384 transportation and delivery Methods 0.000 description 2
- 101100172132 Mus musculus Eif3a gene Proteins 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 238000013479 data entry Methods 0.000 description 1
- 238000013502 data validation Methods 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000012432 intermediate storage Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 239000003973 paint Substances 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/46—Indexing scheme relating to G06F9/46
- G06F2209/462—Lookup
Definitions
- This invention relates to the field of information retrieval and more particularly to the integration of heterogenous computer systems into an enterprise wide message driven client-server system which simplifies network connections and facilitates business process re- engineering.
- the invention had its genesis in the banking failures of the 1980s which resulted in the merger of many financial institutions. As two institutions merged, there were substantial technical integration problems resulting from different equipment and different ADP philosophies. Retraining of users was required on the disparate systems of the merging organizations and there was a clash of corporate culture and doctrine which created a need for significant re-engineering of the business processes of the old organization(s) , to the new. Beyond the problems associated with merging organizations, there are also problems with modifying existing applications and adding new applications. The development process is too slow. The cross-discipline communication problems which exist between system developers and application end users are significant. It is therefore desirable to allow end users to add or modify processes with minimal or no involvement of ADP or systems personnel, and to do such work quickly.
- Figure 1 illustrates the problems of integrating two disparate automated data processing systems from two different banks.
- Bank 1 has an IBM host 101 running the MVS/XA operating system and running a DB-II database application.
- Bank 1 also has a second host 102 running the MVS/ESA operating system and a variety of older (legacy) banking applications.
- Bank 2 has a first host 111 running for example a Tandem TM operating system for general purpose processing and a second non-IBM host 112 running a non-IBM operating system and an SQL database management system.
- Host 1 of Bank 1 has a network 103 running the SNA protocols at the higher levels and token ring at the lower levels.
- Each branch office has a multiplexer 107 which connects tellers 108 and ATM machines 109 to the network.
- Gateway 105 connects a second network 104 via gateway 106.
- Network 104 is a token ring network at the lower level protocol and SNA at the higher levels, with terminals 108 and 109 hanging off the network.
- Bank 2 has a network 113 using poll-select communications.
- Host 111 also services an X.25 network 114.
- Host number 2 of Bank 2 services a CSMA/CD network 116 utilizing TCP/IP protocols.
- Customer service representatives (CSR) 115 may receive requests from the clients of either former bank and therefore must access systems from both banks. For example, if a customer calls in and requests account balance information, the customer service representative will need access to the host of the former bank on which that information resides. If a customer from the other former bank calls, the customer service representative would require access to the .ADP resources of the other bank.
- the request requires several transactions to satisfy such a compound or complex request.
- the customer service representative would access a credit history (220) of the prospective borrower.
- the CSR would access the account balance (230) and the credit card status (240) of the prospective borrower.
- the customer service representative might inquire as to the availability of bank funds (250) to fund the loan using yet another transaction.
- the information required to satisfy the different kinds of information needed to satisfy a complex request might well be located on different hosts. Therefore, in the prior art, the customer service representative would be required to logon to the individual hosts, obtain the information and then manually arrange and assemble it in a manner that would permit a decision to be made on the loan request.
- Figure 3 illustrates a problem when large numbers of clients and hosts are involved. Assume that there were 10 hosts acting as servers for 1000 client work stations and that each client work station needed to access information rapidly from any of the hosts. Such an arrangement would require 10,000 sessions to be maintained over the network. Typically, this would strain the ability of the communication interfaces on the host to manage that number of sessions. Each host would be required to manage 1,000 sessions and each client would be required to manage 10 sessions as shown in Figure 3. Therefore, it is desirable to reduce the number of sessions required to be maintained in order to service operations from a large number of clients.
- One advantage of the invention is to provide a client-server network which requires fewer network sessions .
- Another advantage of the invention is to permit the integration of disparate computer systems with a minimum of integration effort. Another advantage of the invention is to allow business end users to develop business applications with minimal or no intervention of programmers.
- Another advantage of the invention is to facilitate business process re-engineering. Another advantage of the invention is to allow the formal capture and documentation of business processes and practices.
- Another advantage of the invention is to permit the reuse of functional software modules. Another advantage of the invention is to allow for quick development of new or modified applications at the business level.
- Another advantage of the invention is to unify the user interface across all back end and front end platforms to thereby eliminate the need for user training on different back end hosts.
- Another advantage of the invention is to permit the screen capture of back end application screens to permit quick development for the capture of information required by the back end application programs and for the packaging of information to be sent to a back-end server.
- Another advantage of the invention is the use of a common user interface when accessing any part of a heterogeneous system of computers.
- Another advantage of the invention is the ability given the user to avoid any need for knowledge of communications protocols or session initiation protocols.
- Another advantage of the invention is the connectivity of users to designated systems through a single message interface.
- Another advantage of the invention is the incorporation of a workflow manager to assist in development and execution of process oriented user requests presented in the form of compound requests to user generated transactional workflows.
- Another advantage of the invention is to overcome the problems found in the prior art described above.
- a message driven client-server system which has a message driven processor (MDP) which translates a request message from a client process into a transactional workflow of one or more transactions required to satisfy the request.
- the transactions may result in a transaction request message or set of messages which provide the necessary information required by a server process to service the request .
- MDP message driven processor
- Protocol independence between the back-end host and the message driven processor is achieved by server agents.
- the server process responds by providing reply information to the message driven processor where it is assembled, with optional other reply information into one or more reply messages which is sent to the client.
- Message based connectivity between one or more client processes and said message driven processor is made protocol transparent to the user by providing client agents which handle differences in network protocol.
- Each type of request message which may be sent by a client is associated with a request profile which specifies the transactions necessary to satisfy the request. Similarly, each type of request message is associated with a reply profile which specifies how to deliver reply information.
- a client profile is also maintained for each client.
- the message driven processor maintains a session control block for each session with a client.
- the session control block provides storage needed for memory and data management for the entire work flow.
- the session control block is composed of several item areas, maintained in temporary storage, that pertain to specific messaging objectives within the system.
- a session static area is defined for each session with a client and is established during logon to a message driven processor
- a message control block is established for each request message received from the client. More than one message control block may be active concurrently.
- a message control block comprises a workflow static area and one or more workflow dynamic areas.
- Data dictionary maintenance provides data definition capabilities over the user definable item areas of the session control block. All user definable item areas are variable length.
- Messages from a client can be directed to a store and forward queue which receives a request from a client, schedules processing of the request for a later time, and forwards the queued request from the client to the message driven processor for execution when the scheduled time arrives.
- the invention also relates to a method of reducing the number of communications sessions required in a client server system in which a plurality of client processes running on one or more client processors retrieves information from one or more host processors by sending a request message from a client process to a message driven processor without establishing an ongoing communication session. Transaction requests from the message driven processor which require server action to satisfy the request of the request message are sent to one or more host processors; and information received back from said one or more host processors is assembled into one or more reply messages to be sent to the requesting client process. Thus, communication sessions are not required between each client processor and each host .
- the invention is also directed to a method of communicating information between one or more client processes running on respective client processors and one or more server processes running on one or more host processors by way of message driven processor which translates request messages from a client process into one or more transactions one or more of which may be sent to a server process which involves sending a request message from the client process to the message driven processor, the request message containing a Message Header identifying source and destination of the message, a Message Specific Header identifying a particular type of business level request and a Message Context Area portion containing data related to the request and receiving from the message driven processor one or more reply messages containing information requested.
- the inventions In apparatus for communicating information between one or more client processes running on respective client processors and one or more server processes running on one or more host processors by way of message driven processor which translates a request message from a client process into one or more transactions at least one or more of which may be sent to a server process, the inventions relates to a method of testing executable workflow objects by simulating inputs required for the workflow object and applying them to the input of the object, simulating an object receiving an output from the workflow object and testing execution flow of the workflow object by monitoring specified variables during program execution and by selectively stepping through work flow object execution one access point at a time and by setting predetermined entry points at certain points during workflow object execution to permit detailed analysis of the state of the workflow at specified points during workflow object execution.
- the invention also relates to apparatus for communicating information between one- or more client processes and one or more server processes by way of a message driven processor which translates a request message from a client process into plural transactions at least two of which are sent to a server process, by dispatching transactions which do not depend on the results of each other from the message driven processor, substantially concurrently, to the one or more host or server processors and then assembling replies received from the host or server processors into one or more reply messages to be sent to a client process which sent said request message.
- a message driven processor which translates a request message from a client process into plural transactions at least two of which are sent to a server process, by dispatching transactions which do not depend on the results of each other from the message driven processor, substantially concurrently, to the one or more host or server processors and then assembling replies received from the host or server processors into one or more reply messages to be sent to a client process which sent said request message.
- the invention also relates to a method for communicating information between one or more client processes running on respective client processors and one or more server processes running on one or more host processors by sending a request message from a client process to an intermediate process, establishing a session control block at the intermediate process, accessing a request profile characteristic of the particular message sent to the intermediate process to identify transactions required to satisfy the request of said message, establishing one or more control blocks as part of the message control block for transactions, selecting transactions for dispatch to one or more server processes, dispatching, concurrently, those transactions which do not depend upon completion of earlier dispatched transactions by retrieving a request view of data contained in the session control block and packaging that data into a workflow request, establishing or accessing a previously established communications session to a host running the server process required to satisfy the transaction and sending the workflow request to the host, receiving a response from a replying host or server, mapping data received from that host or server into a reply view of data, storing the reply view of data in the session control block; and assembling one or more reply messages from data stored in
- the invention also relates to a method of constructing screens for packaging information to be sent to a server process for retrieving information or to a client process for obtaining information from the client to be sent to a server process by storing a map of screen information received from a server process, associating specific areas on the screen with variable information to be sent to or received from the server; and saving said bit map with representations of variable information for transmission to said server process.
- the invention also relates to a hierarchical message driven client-server system which has a plurality of sets of client processes running on respective client processors, one or more server processes running on at least two host processors, a first level message driven processor for translating a request message from a client process into one or more first level transaction messages required to satisfy the request, one or more second level message driven processors for translating a request message from a client or a transaction message from a first level message driven processor into one or more second level transactions required to satisfy the request, client agents for providing message based connectivity between a client process and said first level message driven processor, server agents for providing connectivity between the first and second level message driven processors and the server processes; and apparatus for assembling reply information from a second or higher level server process into one or more reply messages and sending the reply message to the client process which sent the request message.
- a request message from a client processor is translated into transactions and transactions are selectively sent to one or more host processors in a hierarchy of host processors and information retrieved is returned to the client in satisfaction of
- the invention also relates to apparatus for communicating information between one or more client processes running on respective client processors and one or more server processes running on one or more host processors by way of message driven processor which translates a request message from a client process into one or more transactions, comprising one or more workflow objects, at least one or more of which transactions are sent to a server process, a method of generating executable workflow objects by interrogating a user as to information needed to define a workflow object, incorporating that information into a skeleton of source code, so that the combined information and skeleton constitutes a complete source code list, compiling the source code list into executable code, and storing the executable code as a workflow object which can be selectively incorporated in workflows to satisfy a request from a client .
- Figure 1 is a diagram utilized to illustrate the problems associated with merger of two different organizations.
- Figure 2 is an example of how a particular business request results in multiple transactions necessary to satisfy that request.
- Figure 3 is a diagram of session management in a multi-host, multi-client, client-server system.
- Figure 4 is an overview of the message driven architecture of the invention.
- Figure 5 is an illustration of the basic message format at the application level.
- Figure 6 is a diagram of the functional components of the message driven processing system of the invention.
- Figure 7 is an illustration of the connectivity between client networks and back-end servers using the work flow manager of the invention.
- Figure 8 is an illustration of how a request is translated into a transactional work flow for delivery to back end servers.
- Figure 9 is an illustration of how the session control block is utilized in the decomposition of incoming messages and the composition of reply messages.
- Figure 10 is a flow chart illustrating one example in which a customer service representative initiates a request message receives information back from a back end server.
- Figure 11 illustrates an example of how the back end server replies to a request from the work flow manager and how it is processed into one or more reply messages to be sent to the customer service representative.
- Figure 12 is a flow chart of the work flow object builder.
- Figure 13 shows compilation of a work flow object into executable code.
- Figure 14 is a flow chart of a skeleton of one type of workflow object (a message handler)
- Figure 15 shows diagnostic processing with simulation.
- Figure 16 shows diagnostic processing using debugging.
- Figure 17 is an illustration of how MDP processors can be utilized in an hierarchal arrangement.
- Figure 4 shows the invention at a high level.
- a number of end user clients 400 are connected to a client connectivity layer 410.
- a number of servers 440 are connected to a server connectivity layer 430.
- a work flow management layer 420 mediates between the client connectivity layer and the server connectivity layer performing the work flow management functions. This architecture permits the user, with no knowledge of data location, to approach the entire network as if it were a single entity.
- the invention provides any to any (or many to many) connectivity using application to application communications and a work flow processing environment between front end requests for service, by clients, and back end applications running on hosts or servers.
- a client connectivity layer 410 insulates the business process from device specific protocols.
- a server connectivity layer 430 works in conjunction with the work flow management layer to permit connectivity to back end applications which have been inherited from the merging organizations (legacy applications) as well as newly engineered back end systems for which common application programming interfaces are available.
- the client connectivity layer allows multiple, disparate clients to request the same services, regardless of front end protocols and device types. Clients interact with client agent interface programs, which filter out device-specific protocols and allow business requests, in the form of messages, to be passed on to the workflow management layer.
- the client connectivity layer behaves as a connectionless environment to fully accommodate synchronous and asynchronous client/server requirements.
- the client connectivity layer accomplishes the following functional objectives.
- the client connectivity layer is composed of three basic modules: client agent, input request manager and output reply manager
- a client agent is a device driven program responsible for communications and protocol in relation to the sending and receiving of requests and replies, and communication error recovery. This program also allows for custom user exit points for use in such things as journaling. Client agents receive request messages from the client and direct them to the input request manager, and receive reply messages from the output reply manager and send them to the client.
- the input request manager is the primary entry point of request messages into the MDP. Apart from performing session establishment, security checking and client validation and registration functions, the input request manager can also be a custom-coded entry point into the workflow manager. This means that the input request manager can translate disparate front end message protocols into MDP message formats, allowing clients with existing application message formats to be accepted by the workflow Manger. In this manner, the integrity of the application program interface is preserved.
- the input request manager performs the following functions. Receives or retrieves request messages, depending on task initiation.
- Accesses the request profile to determine special attributes associated with the request, and validates the request's request profile against the request profile file.
- the output reply manager supports the reply side of message processing.
- the output reply manager is initiated by the workflow manager when the unit of work is complete.
- the output reply manager then formats the reply message from the session control block.
- the output reply manager uses the reply profile parameters, loaded previously in memory, to determine the proper reply process, and sends the completed message back to the client, via client agent module, if applicable.
- the output reply manager is also designed openly, allowing customization to be implemented where necessary.
- the output reply manager performs the following functions : Uses the reply profile parameters, loaded into memory previously by the input request manager, to determine how the reply should be sent to the client.
- the workflow Management layer is made up of two environments that control the enablement, generation, and processing of messages in the form of workflows.
- workflows whichcontain executable workflow objects that together fulfill the requirements of a request, are created in the development environment, and then executed in the run time environment.
- the major system component of the development environment is the workflow object builder.
- the major system component of the run time environment is the workflow Manager.
- the workflow Manager is initiated by a request message which it receives as input. Since the workflow Manager is not responsible for the initial receipt of the Request (nor its resulting replies) , it is not encumbered by network dependencies that would limit the reusability of a workflow. The processing which begins with a request and ends with one or more replies is done within the workflow.
- a workflow can represent a very simple or a very complex function. Typically, the more complex the function, the more units of work there will be in the workflow. To complete a complex workflow, the workflow will decompose the message received and invoke a synchronous unit of work and, perhaps, one or more asynchronous units of work, to independently retrieve information from different sources as necessary and process it.
- Asynchronous units of work may execute waited or nowaited. Based on design of the unit of work, the workflow recomposes the resultant information in the session control block memory management area into a reply, which is then sent back to the client. Between the workflow Manager and the workflow, the complexity of the business function is removed from the client. This concept of complex transaction enablement lets the client make simple single requests for services, and receive simple single replies or a series of replies, in return.
- a workflow may provide connectivity between the workflow
- a workflow may be organized into one or more units of work; each unit of work performs a part of the overall business request .
- a workflow contains one synchronous unit of work and optionally one or more units of work that may be dispatched to execute substantially concurrently.
- the smallest unit of work that is capable of executing by itself is a workflow object.
- a workflow typically consists of multiple workflow objects.
- Session Control Profiles link initiation of the execution of the workflow to reception of a Session Request Message.
- the MDP receives a request message which contains a request profile ID, which in turn points to the first workflow object or profile in the workflow. Using data in the request message, workflow execution then begins.
- the MDP may receive a standard or extended signon request message or a signoff request message, which may indicate the first workflow object or object profile. Using data in the standard or extended signon request message or signoff request message, workflow execution then begins.
- MDP also supports the fast path business request message, a method to conserve memory by supporting the logical session for only those clients whose workflows are currently in progress and a method of supporting MDP to MDP communication.
- the workflow may execute using data from one or more sources:
- MDP may receive a subsequent message that points to a new workflow.
- MDP supports execution of multiple concurrent workflows, initiated by multiple messages from the same client .
- the workflow Management development environment provides menu-driven workflow building tools that allow the developer to:
- workflow objects of different types to interact either synchronously or asynchronously with the workflow Manager and back end systems. Simulate the execution of, and debug, workflows.
- Access utilities that support the development process for generating, compiling and copying workflow object definitions.
- the work flow management layer is made up of two principal environments that control the enablement, generation and processing of messages in the form of work flows. They are created in the work flow development environment 421 and then executed in the work flow manager run time environment 422. Work flows contain executable objects that together fulfill the requirements of a request .
- the Major components of workflow development include the workflow object Builder which is a tool that is used to define and generate complex units of work in the form of a workflow.
- the component allows the developer to define the attributes of each workflow object associated with the workflow.
- Data Dictionary Maintenance is also included in workflow development.
- a Data Dictionary Builder provides data definition capabilities over the user accessible item areas of the session control block. All item areas relating to user-defined message areas are variable length. This allows the developer to define the maximum space requirement for each business function, making for an efficient use of space.
- the work flow manager is initiated by a request message which it receives as input.
- the work flow manager Since the work flow manager is not responsible for the initial receipt of the request (nor its ultimate reply to the requester) , it is not encumbered by network dependencies which would limit the reusability of a work flow.
- the execution of an output reply by the work flow manager marks a completion of a work flow.
- the processing which begins with a request and ends with a reply is also called a unit of work.
- a work flow can -represent a very simple or a very complex function. Typically the more complex the function, the more pieces there will be to the associated work flow.
- the work flow will decompose the message received and invoke several tasks to independently retrieve information from whatever different sources are necessary.
- the work flow manager manages all of the information placed into the session control block, to be described hereinafter, into one or more comprehensive replies which may then be sent back to the client.
- the complexity of the function is removed from the client. This enables the client to make simple single requests for services and receive simple single replies in return.
- a work flow may request connectivity between the work flow manager and multiple disparate back end systems. This contributes to the single system image viewed by the front end client.
- the common message header labels all message traffic to and from the Client. It uniquely identifies the requesting Client and associates the unit of work requested with that Client.
- the common message header is carried in all required Request and Reply Message exchanges associated with the request or the logical session.
- the Message-Specific Context Header varies in content with each specific message type and defines static fields that must be populated by the requesting Client and becomes the context for each message type.
- the data in these fields correspond with functions performed by the various layers in the workflow Management environment .
- the Message Context Area includes variable length data used to supply user-defined and formatted data to a particular Business or System Request.
- the developer decides the length, content and the request and reply format during the workflow Development phase.
- the workflow Manager will associate the Request with a workflow.
- the workflow is developed to accept data from the request format and, eventually, map data to the reply format of this segment after processing has been completed.
- the format of the data in this segment can vary with each Request and may even vary within a Request.
- This segment is defined by the developer based on the needs of the Request.
- These three basic components provide a basis for both Request and Reply Messages.
- the Common Message Header and the Message-Specific Context Header are required of all messages and are fixed length segments.
- the Message Data Context Area is of variable length, defined by the developer, based on the needs of the system request or business function.
- Figure 6 illustrates the message driven processor 450 in greater detail.
- a set of client agents, 610 act as protocol engines to insulate the work flow management layer 620 from the different protocol layers which wrap the illustrated in Figure 5.
- server agents 630 perform a similar function.
- a message handler 633 formats data to be sent to back end servers and passes it to either FEPI object 634, NVAS object 635 or dispatcher-responder pair 636A and 636B where the interaction with the back end server is handled.
- FEPI object 634 e.g., FEPI object 634
- NVAS object 635 e.g., NVAS object 635
- dispatcher-responder pair 636A and 636B e.g., NVAS object 635
- Figure 7 illustrates the processing of a message from a client up to the work flow manager level shown in Figure 6.
- the message driven processor has a number of network ports, 710, each of which services a corresponding network.
- Each network is characterized by a communications protocol which specified how stations on the network interact.
- Protocols LU6.2, LUO and LU2 are protocols generally utilized in an IBM environment.
- CICS stands for Customer Information Control System which is an IBM product permitting access to application programs associated with it, formatting information in a manner analogous to a formal protocol .
- MQI stands for Message Queuing Interface and represents protocols associated with the MQTM Series software product by IBM. MQTM Series simplifies communications by utilizing a simplified command set.
- each of the client agents, 720 manages communications below the application layer passing only the application level message to queue 725 for delivery, in turn, to the input request manager 730.
- a client wishing to sign on to the message driven processor may do so in one of two modes. If a great deal of transaction volume is expected from that client over the course of a day, the client may wish to sign on and remain permanently signed on to the system. On the other hand, if only occasional access is required, a session may be established only for the duration of each request.
- Session profile/sign-on control 735 manages sign-on in accordance with the session profile which is selected based on the content of the sign-on message received from the client. Which method of sign-on is preferable depends on the amount of overhead required in establishing and tearing down session control blocks, described hereinafter.
- a Client sends a sign-on request message in preparation for the day's processing.
- the sign-on request message may be transported from the LAN server to the host via a LU 6.2 transport.
- the LU 6.2 Client Agent program is initiated and any data conversions or protocol specific logic is performed at this time.
- the Client Agent starts the Input Request Manager.
- the MDP determines the file base and processing mode.
- the Client Profile file is read and the Session Control Request Message is validated.
- the Session file is read to determine if a session had already been established for that Client.
- the Request Profile file is then read to determine the detail parameters of the Sign-on Request, and optionally may point to a workflow or workflow object to be executed at sign-on.
- the Reply Profile is read to determine the reply characteristics. Since this is the first sign-on of the day, a Session record is written.
- Sign-on processing controls overall processing of the Client's session, controlling access to workflows and data stored on the host, based in part on the Client's assignment to an MDP Office.
- the workflow to which the sign-on- request message may point as an option may support more complex processes such as logging on to the back end servers.
- a fast path business request message may be sent at any time - without regard to whether an MDP session is established for this Client. It my be used to immediately begin processing a workflow, without previous sign-on.
- the Request Message and the Fast-Path Business Request Message may contain data for the workflow to process. Both the Request Message and the Fast Path Business Request Message point to a Request Profile ID. The Request Profile ID points in turn to the workflow.
- a request profile is a decomposition of the incoming business request into units of work or workflow required in order to satisfy the request.
- a request in the form of a message to approve a loan illustrated as step 2 would be decomposed into four different requests for information as defined by the request profile, one to retrieve a credit history, one to retrieve an account balance, one to retrieve credit card status and one to confirm bank fund availability to fund the loan.
- the individual requests which make up the profile of the request from the client are then processed by the work flow manager environment where they are individually packaged for sending to the back-end servers.
- the information is assembled into one or more reply messages and sent to the output reply manager 770 where it is queued for transmission to the client using the specified client agent.
- the outgoing application level message is sent to the client in the protocol appropriate for the network by the client agents and sent to the client.
- Work flows are essentially composed of a series of work flow objects, whether they are individual objects or a plurality of objects grouped together in object profiles, and routing parameters for processing instructions defined at the request profile level to direct the order of execution of the work flow objects.
- a work flow object is a generated program designed to accomplish a specific task or function, allowing its reusability by multiple work flows.
- Work flow objects are generated dynamically by the work flow object builder and may themselves contain internal routing parameters, which are defined within the work flow object.
- work flow objects are designed to be executed from within a work flow, they can be created work flow independent. The reusable nature of work flow objects allows them to be associated with multiple work flows, each of which may use the object in a different scenario.
- a work flow object processing sequence may be incorporated alone into a work flow or it may be part of an object profile which contains a processing series of work flow objects.
- object profiles can also be reused by multiple work flows.
- Figure 8 illustrates a typical request message, its decomposition into a transactional work flow, the execution of the work flow and the composition of one or more reply messages to the client requestor and queuing steps required to complete the business flow.
- a request is received at the input request manager 800 which accesses the request profile in storage 805.
- the request requires three units of work to complete. These are labeled A, B and C in the drawing.
- Separate storage areas are set aside for the request and reply data. In each area, a separate storage area belongs to each of the units of work required to complete the request .
- the work flow manager 810 determines that units of work objects A and B can be executed concurrently and that unit of work C must await the completion of units of work A and B.
- Work flow manager 810 dispatches unit of work A at step 820 and unit of work B at step 830.
- Step A work flow object A involves viewing the data (821) associated with the client request message to extract the data needed to formulate the transaction associated with work flow object A.
- the two branches 822 and 823 of processing utilizing that data can proceed culminating in steps A5 and A6 in unit of work A which access one or more host computers to retrieve data.
- a similar process occurs with work flow object B as illustrated in the work flow 830 including Bl through B3 shown in the drawing.
- the reply data is returned to storage area BR2 (807) and stored in respective blocks A and B.
- Step C the final step in the work flow, takes the data from A and B, does data correction, checking and error handling, and passes reply data to area C of reply area BR2.
- Reply profile data 850 is utilized to determine how the data in the reply area is to be sent to the client using a client agent, if necessary. Once a reply message is sent, the storage areas dedicated to the request are freed up for use by other processes.
- the data dictionary/message definition support 631 shown in ' Figure 6 is used to design, generate and maintain data dictionary entries (chapters) which map storage areas to data elements and structures
- Data item areas, user files, temporary storage and request and reply messages are normally defined and dynamically maintained in data dictionary chapters and are used to direct data placement during work flow processing.
- the request and reply storage areas 806 and 807 of Figure 8 represents a common memory area for the operation of a work flow called a session control block.
- the session control block provides storage needed for memory and data management for the entire work flow which comprise a plurality of message control blocks.
- the session control block is composed of several item areas, maintained in temporary storage, that pertain to specific messaging objectives within the system.
- a session static area 901 is defined for each session with a client and is established during MDP logon.
- a message control block 930 is established for each concurrent request message received from the client. More than one message control block may be used concurrently.
- a message control block comprises a workflow static area and one or more workflow dynamic area 920.
- Data dictionary maintenance provides data definition capabilities over the user definable item areas of the session control block. All user definable item areas are variable length.
- the session control block allows the MDP session to maintain a connectionless, non-blocking conversation with a front end client and to maintain the data for all work flow objects.
- Each message control block is primarily made up of two temporary storage areas one containing static item areas and one dynamic item areas.
- the workflow static area of the message control block contains a workflow static item area 911 and a workflow dynamic area 920.
- the workflow static area (workflow area) has a system-reserved area containing static information that relates to one workflow. This item area cannot be modified, -but may be browsed.
- the request area contains the request message and reply area which may contain one or more reply messages sequentially to be sent back to the client.
- Figure 9 illustrates in more detail the operation of the session control block.
- a message control block is created as discussed above.
- the request data received with the request message is written in block 913.
- the work flow manager .930 may assemble data into the reply message data format in the reply section 914 of the message control block. That message data is then passed to the output request manager 940 where it is sent to the client requestor.
- the global area is used to store event user data throughout the length of a workflow typically used to collect data for use in multiple workflow objects and during asynchronous workflow processing.
- the workflow dynamic area 920 contains 3 work areas, pre-defined in a set of data dictionary entries, and a dynamic system area containing data relating to a workflow object and its processing.
- communication sessions are transitory, operating in the connectionless mode. That is, the client and the client agents interact only long enough to receive the message and acknowledge the message.
- the communication session does not typically remain active during the processing required to obtain the request data.
- one or more reply messages will be sent to the client requestor in the connectionless mode.
- the message control block which defines the data request session, remains active throughout the lifetime of the processing until all reply messages are sent to the client. Thus, even though a communication session is not continuous throughout the processing, an MDP session is normally maintained until a logoff request is received from the client requestor.
- a client requestor may logon to the MDP for only the duration required to process a single message via fast path processing, or, where high transaction volumes are expected, for a larger duration such as all day.
- logging on involves establishing a session control block for the client requestor.
- message control blocks will be freed up when the reply to the message from the client is sent.
- Figure 10 is a flow chart of an example of the work flow process. From the time a request message is received (1001) to the time a transaction request is dispatched to the server 1050. The reply process is depicted in a flow chart in Figure 11.
- a customer service representative initiates (1001) a request message.
- the message is received at the MDP and a message control block is established (1005) as described above.
- the request profile for the type of the message received is accessed (1010) and the message control areas are updated. If an unexecuted unit of work from the profile can proceed concurrently with other units of work, the workflow manager dispatches the unit of work and processing of the work flow object begins. If it cannot, it checks.to see if there is an ongoing unit of work and if there is it will delay (1060) until a unit of work completes. If there is no ongoing unit of work, the next unit of work will be dispatched (1030) .
- the request view of the input message data is retrieved, a session to the back end host established (1045) and a transaction request sent to the host.
- the reply comes back from the host 1101 the response mapped into a reply view of the data at 1110 and the reply is stored (1120) in the workflow dynamic area of the message control block.
- the results are assembled from the workflow dynamic areas to a Reply Message Data area 914 in the workflow static area of the message control block (1125) . If all necessary responses have not been received and no-wait is not active, nothing happens (1150) but if all responses have been received (1150) , the output reply manager is invoked and one or more reply messages are sent (1160) to the customer service representative. In a no-wait mode, multiple reply messages are generated from work flow dynamic blocks as responses are received.
- request messages There are several types of request messages. One is the session control message. Another is the business request. A third is a system request. In the run time environment, when clients actually execute work flows to perform business functions, an MDP session must first be established for the client in the MDP before the process of sending requests and receiving replies can take place. To establish and end a session, a session control message must be sent from the client to the MDP.
- a session control message will not necessarily have a work flow associated with it. All it may be is a simple message sent to the MDP requesting a session be started and a session control block be established. When ending a session, all the message may require is the deletion of the session control block and little else.
- the option of associating specific tasks with a session control message opens the door for the client to possibly perform automatic logons to back end systems, as well as any other standard start up tasks. Completion of these tasks can be indicated to the client in the form of one or more reply messages.
- the work flow object builder is a flexible code- generator that creates work flow objects suited to perform specific elementary tasks. These objects, when strung together in routing sequence or profile, collectively form a work flow.
- a work flow designed to fulfill tasks associated with a request, or unit of work, is triggered by a request profile and executed by the work flow manager.
- some work flow objects may access back end systems via NV/ASTM (Net View/Access Services) , FEPITM (front end programming interface to CICS) , MQI (MQTM Series interface) and others mechanism or protocols) .
- Some units of work may run substantially concurrently (sometimes called asynchronously) as permitted by an object profile.
- Some work flow objects may be designed specifically for data manipulation or for checking data obtained by other work flow objects.
- the final work flow object in a work flow or unit of work will typically construct one or more reply messages to be sent back to the front end client.
- a work flow object that accesses information contained in one or more of the items in temporary storage from the session control block and uses it to make routing decision or to format output message views that may be required to obtain information from other systems is called a message handler.
- Message handlers are not typically designed for reusability by multiple work flows since much of their purpose is specific to a certain request. The decomposition of a request message and recomposition of one or more reply messages will most likely be found in this type of work flow object.
- a dispatcher is a work flow object defined for use as part of a pair of objects. Used with the responder, dispatchers initiate transactions using an MQ seriesTM, a CICS peer-to-peer, an LU6.2 or other mechanisms or protocols. Dispatchers are typically used when it is necessary to execute a task that is external to MDP. A dispatcher is primarily responsible for setting parameters associated with the external task, such as PUT queue name, responder name, etc. The dispatcher/responder pair is inherently a sequential (sometimes called synchronous) process. Once something is dispatched the work flow unit of work waits for a response. However, dispatcher/responder pairs may be part of a concurrent (asynchronous) object profile.
- Responders get involved after the external target task is completed and the MDP resolution processes have been invoked.
- a responder receives information from the target task in the session control block item area defined at dispatcher development time.
- NV/AS, FEPI and other work flow objects which can accommodate a variety of different platforms perform 3270 emulation to retrieve data and map from back end applications into the session control block.
- the building process is set forth in Figure 12.
- the start of the development process involves a definition of message layouts (1200) .
- specific field definitions for incoming and outgoing messages are defined and stored in a data dictionary 1405.
- Certain views of message data are generated in the form of copy books or structures (1210) and are available for use during the definition, design and development of the object.
- Certain implementation specific workflow object parameters are optionally defined at 1220.
- data elements used as input and output within the module are defined, optional edits applied and named object data elements information stored at 1235.
- Object routing optionally defined at 1240 specifies, inter alia, the order in which workflow objects are executed, and the routing information is stored at 1245.
- the developer defines certain decision making logic at 1250 which is stored at 1255.
- Certain user exits are identified at 1260 through which calls to user developed sub-routines (1275) and standard library (copybook) functions can be incorporated selectively. User exits are named and their identifiers stored at 1265. Once a developer has been guided through this process, sufficient information has been stored to submit the object specified in the process of Figure 12 for code generation.
- Figure 13 illustrates the code generation process.
- the work flow object generation process 1300 incorporates all of the development information stored from a user during the development process and integrates it with work flow object skeletons 1320.
- Each type of work flow object has a predefined source code skeleton consistent with its particular function which is used as the infrastructure for creation of object source code 1330.
- the object skeletons 1320 are fleshed out in object generation block 1300 by incorporating the information captured at 1310 and stored into the final source code. Once all of the user defined information has been integrated into the skeleton, a complete source code block exists at 1330 and can be optionally submitted for compilation (1340) . Once compiled into executable code, the object may be utilized as part of a work flow needed to satisfy a request (1350) .
- Figure 14 is a high level flow chart of a skeleton of a message handler 1320 from Figure 13.
- the skeleton begins (1400) with reading the session control block 1405.
- Selective access to the debugger is provided between blocks 1405 and 1410 to permit the state of the input information from the SCB to be captured for evaluation.
- Initial decision making logic 1410 processes logic defined during the development process.
- Input block 1420 performs data validation and checking, edits and table translations that otherwise prepare the data for the main processing functions 1425.
- the main decision making logic is predefined for each type of work flow object and its source coding included in block 1425.
- Main user exit 1430 permits the incorporation of source code modules previously developed and stored in library for the inclusion of user developed routines into the overall source code stream.
- Output block 1435 is analogous to input block 1420 and prepares data for output from the work flow object.
- the next decision making logic 1440 is predefined for the object and user exit 1445 permits the user one additional opportunity to customize the module by incorporation of library or custom subroutines .
- Routing for the output data is optionally defined at 1450 and ultimately, the session control block is updated with the final versions of data processed by the work flow object (1455) .
- Selective access to debugger is provided after block 1455 to permit the changes to the SCB caused by object execution to be captured for evaluation.
- the source code ends at 1460.
- Internal routing from one work flow object to another can be defined during the work flow building process to be either static or dynamic. Dynamic routing can be based on data content and/or context within the session control block. All the work flow object characteristics and parameters are stored in the work flow object definition and decision making files. These files are referenced during the batch work flow object generation process in which the parameters are converted into CICS command level source code, then compiled and linked into an
- Debugger/simulator modules shown in of Figure 6 are available typically in the development environment to provide testing support for work flow objects.
- the Debugger/simulator modules allow simulation and diagnostics of workflows to allow the developer to examine the session control block through all of the major processing steps in all of the workflow' s objects. It also allows performance analysis and automated testing. If the workflow acquires data from back end hosts and applications, this data is incorporated in the workflow' s processing as well. These two special development features help developers test workflows before subjecting them to the condition of network level testing with custom front end applications.
- the simulator formats and submits certain session control messages in order to simulate a client who is requesting services.
- the simulator allows for the input of user data in all request messages.
- the data can be typed in free form or can be formatted via a data dictionary.
- the simulator also allows the active message buffer to be written to the input request file.
- This file is used as the simulator's depository for request messages. With the potential for large or numerous messages, this file can be used to store data and eliminate the need for time consuming data re-entry.
- the simulator can replay any message stored on the input request file by loading the record into the active message buffer.
- the data can then be modified prior to being sent in a request message. All input request messages can be updated on the file or deleted from the file.
- the data can also be used as a template to create additional request message data formats.
- the simulator can display available information about the source of the error.
- the simulator can also display the header of the reply message that MDP generates in response to the simulator client's message as well as providing view capabilities of the session control block.
- the simulator has been integrated with the workflow debugger to allow for simulation and diagnostics from a single terminal. This allows the simulator to turn debugging on and off on the processing of each message.
- the workflow debugger has the ability to capture data from the request item area of the session control block and store the data in the input request file.
- the simulator also provides the ability to terminate processing by performing the appropriate signoff request messages or by archiving the current session on the host.
- the simulator may be used as an aid in network level testing with custom front end applications.
- the simulator can send a message that is identical to a target message sent from a front end application on a client or a client work station.
- the journal display can be used to confirm that the two messages are identical . If the simulator has already tested the workflow that is associated with the target message, and if journal display confirms that the simulation message and the target message are identical, then it is likely that the problem lies with the custom front end application.
- the system provides run time diagnostics through the use of the workflow debugger, providing the ability to interactively debug the workflows that support the processing of Request Messages. This is accomplished by executing the workflow in a terminal-associated fashion, thereby allowing screen display and interactive user intervention at the host level.
- Debug processing control i.e., abort Request Message, terminate debugging, etc.
- the workflow debugger allows all items of the session control block to be symbolically viewed. An initial screen will be displayed showing all items and the symbolic chapter that will be used to map the item.
- the process of starting the workflow debugger is generated at two exit points in every workflow object. The first exit point is before the main logic is performed, immediately after the session control block has been read into the program. The second exit point is at program completion, after any session control block updates have been processed.
- session control block data can be displayed and manipulated at the field level.
- a session control block item area can be selected and displayed via the Symbolic Mapping Utility.
- a list processor of symbolic fields used to map the selected item area displays, allowing the user to list and search for fields by name or offset. Left/right scrolling capabilities are available to view the field data.
- Field data values may be displayed in Character or Hex Mode.
- Field data values can be updated by entering an Update Mode.
- the user can toggle between Update Mode and Browse Mode. When in Update Mode, field data values are modifiable. Field updates are applied to the session control block.
- Fields can also be optimally initialized. Alphanumeric fields are initialized to spaces and numeric fields are initialized to zero.
- the workflow debugger provides that capability. This data can then be saved and reused when testing with the Simulator (i.e., without having to reenter data repeatedly) .
- the user may terminate debugging at will, continue while viewing the SCB at every exit point, suspend and reactivate debugging and re-execute a workflow object.
- the work flow debugger provides on line addressability to items within the session control block and permits data field examination and modification. If necessary, the work flow debugger may be turned on in the run time environment for setting traps and handling exceptional data conditions for real time or later analysis. In operation, debugging is started from terminal 1610.
- workflow objects are initiated. If a workflow object is enabled with debug support, it will initiate debugger module 1600 at the awaiting terminal at defined entry points (see figure 14) within the workflow objects.
- the debugger module allows interactive data display and manipulation.
- the debugger stub 1630 is started by the debugger module.
- the debugger stub activates the workflow 1620, to resume execution, until the next debug entry point is encountered or workflow processing is complete.
- work flow objects such as FEPI work flow objects and NVAS work flow objects, it is often the case that the backend host expects a set of screens of data to be presented to it in a particular order.
- the host transmits a set of data and commands which identify the locations of variables on the screen.
- the terminal uses these data and commands to paint the screen and to extract data for sending to the host when data entry is complete.
- the system of the invention captures the screen information sent from the host and uses captured screens to emulate a screen based interaction of a terminal and the host by stuffing captured screens information with the proper data and presenting those screens to the host in the order the host expects.
- Server agents are analogous to client agents. These provide the protocol interface drivers, state management and error recovery to create and maintain logical sessions to the back end systems.
- Figure 17 illustrates how hierarchal arrangements of
- MDP systems can be utilized. As shown in Figure 17 the output to the back end servers from one layer of MDP processors is utilized as the client input to the next level of MDP processors. Thus, the work flow objects executed at the lowest level may constitute a client message for the MDP server at the next higher level. Thus, entire hierarchies of MDP processors can be utilized. This is particularly convenient when one MDP processor is utilized as an office server and a number of offices are serviced by a region and the next level in the hierarchy constitutes a regional processor which provides information to the local offices served by it. This allows local offices to develop their individualized business practices while still being able to access the regional offices ADP resources.
- each local office can access one or all of the regional offices and one or more national offices.
- Regional or national office can access one or all of the others as desired or required.
- this disclosure there is shown and described only the preferred embodiment of the invention, but, as aforementioned, it is to be understood that the invention is capable of use in various other combinations and environments. It is capable of changes or modifications within the scope of the inventive concept as expressed herein.
Abstract
A message driven processor (450) operates as middleware between clients (400) and back-end hosts or servers (440) in a large client-server system to reduce the number of concurrent sessions required to be supported by the network and to allow a common client user interface to divergent back-end systems. High level requests from a client (400) in support of a business function are translated into workflows which may involve multiple requests to back-end servers by the message driven processor (450). Information resulting from workflows and information retrieved from back-end servers may be integrated into a single reply message to the requesting client (400).
Description
METHODS AND APPARATUS FOR IMPLEMENTING A MESSAGE DRIVEN PROCESSOR IN A CLIENT-SERVER ENVIRONMENT
Technical Field
This invention relates to the field of information retrieval and more particularly to the integration of heterogenous computer systems into an enterprise wide message driven client-server system which simplifies network connections and facilitates business process re- engineering.
Background of the Invention
The invention had its genesis in the banking failures of the 1980s which resulted in the merger of many financial institutions. As two institutions merged, there were substantial technical integration problems resulting from different equipment and different ADP philosophies. Retraining of users was required on the disparate systems of the merging organizations and there was a clash of corporate culture and doctrine which created a need for significant re-engineering of the business processes of the old organization(s) , to the new. Beyond the problems associated with merging organizations, there are also problems with modifying existing applications and adding new applications. The development process is too slow. The cross-discipline communication problems which exist between system developers and application end users are significant. It is therefore desirable to allow end users to add or
modify processes with minimal or no involvement of ADP or systems personnel, and to do such work quickly.
Another problem which exists is that organizations seldom formally document the details of their business processes. This occurs in part because those processes change frequently and the people who know the processes are too busy performing the work to document the processes. Accordingly, it is desirable to have a mechanism for formally capturing and documenting business practices.
Reuse of software modules is also a difficult problem. Typically, these modules are created by programmers and other programmers either do not know of the work done by others or, if they have access to a library of such work, they are unable to recognize relevant modules using available indexing systems . Therefore, it is desirable to provide a mechanism for the reuse of modules in an easy and convenient manner.
Figure 1 illustrates the problems of integrating two disparate automated data processing systems from two different banks. Bank 1 has an IBM host 101 running the MVS/XA operating system and running a DB-II database application. Bank 1 also has a second host 102 running the MVS/ESA operating system and a variety of older (legacy) banking applications. Bank 2 has a first host 111 running for example a Tandem™ operating system for general purpose processing and a second non-IBM host 112 running a non-IBM operating system and an SQL database management system. Host 1 of Bank 1 has a network 103 running the SNA protocols at the higher levels and token ring at the lower levels. Each branch office has a multiplexer 107 which connects tellers 108 and ATM machines 109 to the network. Gateway 105 connects a second network 104 via gateway 106. Network 104 is a token ring network at the lower level protocol and SNA at the higher levels, with
terminals 108 and 109 hanging off the network. Bank 2 has a network 113 using poll-select communications. Host 111 also services an X.25 network 114. Host number 2 of Bank 2 services a CSMA/CD network 116 utilizing TCP/IP protocols.
When integrating the automated data processing systems of the two banks together, one of the problems involves providing access to customer service representative 115 to all of the ADP resources at both banks. As illustrated in Figure 1, this requires a network appearance on each of three networks 104, 113 and
116. Access by customer service representative to the fourth network, 103, occurs over gateway pairs 105, 106.
Customer service representatives (CSR) 115 may receive requests from the clients of either former bank and therefore must access systems from both banks. For example, if a customer calls in and requests account balance information, the customer service representative will need access to the host of the former bank on which that information resides. If a customer from the other former bank calls, the customer service representative would require access to the .ADP resources of the other bank.
If a customer calls in with a request for a loan from the new merged bank, the request requires several transactions to satisfy such a compound or complex request. As shown in Figure 2, first, the customer service representative would access a credit history (220) of the prospective borrower. Then, the CSR would access the account balance (230) and the credit card status (240) of the prospective borrower. Finally, the customer service representative might inquire as to the availability of bank funds (250) to fund the loan using yet another transaction. The information required to satisfy the different kinds of information needed to satisfy a complex request
might well be located on different hosts. Therefore, in the prior art, the customer service representative would be required to logon to the individual hosts, obtain the information and then manually arrange and assemble it in a manner that would permit a decision to be made on the loan request.
Figure 3 illustrates a problem when large numbers of clients and hosts are involved. Assume that there were 10 hosts acting as servers for 1000 client work stations and that each client work station needed to access information rapidly from any of the hosts. Such an arrangement would require 10,000 sessions to be maintained over the network. Typically, this would strain the ability of the communication interfaces on the host to manage that number of sessions. Each host would be required to manage 1,000 sessions and each client would be required to manage 10 sessions as shown in Figure 3. Therefore, it is desirable to reduce the number of sessions required to be maintained in order to service operations from a large number of clients.
In capturing information from a client for submission to a server, it is often desirable to replicate screens which the server produces. In the prior art, this is done by manually mapping out fields and screen literals on a blank format screen. This is cumbersome and often inaccurate. Accordingly, it would be desirable to have an ability to capture application screens from information provided from a back end host and utilize those screens either when capturing information from a front end client or when interacting with a back-end server.
When merging non-compatible ADP systems into a single environment, it is required to train operating personnel not only on the ADP equipment but on the business functions and procedures as well. It would desirable to minimize the training required by
eliminating the need to train personnel on different types of ADP equipment .
Further, when modifying or instituting new business procedures, it would be desirable to be able to minimize or eliminate the involvement of programming personnel and have the change implemented by the business people only. From a users point of view, approaching the network as if it were a single entity even though it is composed in fact of heterogenous ADP systems would be very desirable. Isolating the end user from multiple protocols, multiple logons and session initiations, and hand shaking/security exchanges would also be desirable.
Objects and Disclosure of the Invention
One advantage of the invention is to provide a client-server network which requires fewer network sessions .
Another advantage of the invention is to permit the integration of disparate computer systems with a minimum of integration effort. Another advantage of the invention is to allow business end users to develop business applications with minimal or no intervention of programmers.
Another advantage of the invention is to facilitate business process re-engineering. Another advantage of the invention is to allow the formal capture and documentation of business processes and practices.
Another advantage of the invention is to permit the reuse of functional software modules. Another advantage of the invention is to allow for quick development of new or modified applications at the business level.
Another advantage of the invention is to unify the user interface across all back end and front end
platforms to thereby eliminate the need for user training on different back end hosts.
Another advantage of the invention is to permit the screen capture of back end application screens to permit quick development for the capture of information required by the back end application programs and for the packaging of information to be sent to a back-end server.
Another advantage of the invention is the use of a common user interface when accessing any part of a heterogeneous system of computers.
Another advantage of the invention is the ability given the user to avoid any need for knowledge of communications protocols or session initiation protocols.
Another advantage of the invention is the connectivity of users to designated systems through a single message interface.
Another advantage of the invention is the incorporation of a workflow manager to assist in development and execution of process oriented user requests presented in the form of compound requests to user generated transactional workflows.
Another advantage of the invention is to overcome the problems found in the prior art described above.
These and other objects of the invention are achieved in accordance with the invention by providing a message driven client-server system which has a message driven processor (MDP) which translates a request message from a client process into a transactional workflow of one or more transactions required to satisfy the request. The transactions may result in a transaction request message or set of messages which provide the necessary information required by a server process to service the request .
Protocol independence between the back-end host and the message driven processor is achieved by server agents. The server process responds by providing reply
information to the message driven processor where it is assembled, with optional other reply information into one or more reply messages which is sent to the client. Message based connectivity between one or more client processes and said message driven processor is made protocol transparent to the user by providing client agents which handle differences in network protocol.
Each type of request message which may be sent by a client is associated with a request profile which specifies the transactions necessary to satisfy the request. Similarly, each type of request message is associated with a reply profile which specifies how to deliver reply information. A client profile is also maintained for each client. The message driven processor maintains a session control block for each session with a client. The session control block provides storage needed for memory and data management for the entire work flow. The session control block is composed of several item areas, maintained in temporary storage, that pertain to specific messaging objectives within the system. A session static area is defined for each session with a client and is established during logon to a message driven processor
(MDP) . A message control block is established for each request message received from the client. More than one message control block may be active concurrently. A message control block comprises a workflow static area and one or more workflow dynamic areas. Data dictionary maintenance provides data definition capabilities over the user definable item areas of the session control block. All user definable item areas are variable length.
Messages from a client can be directed to a store and forward queue which receives a request from a client, schedules processing of the request for a later time, and forwards the queued request from the client to the
message driven processor for execution when the scheduled time arrives.
The invention also relates to a method of reducing the number of communications sessions required in a client server system in which a plurality of client processes running on one or more client processors retrieves information from one or more host processors by sending a request message from a client process to a message driven processor without establishing an ongoing communication session. Transaction requests from the message driven processor which require server action to satisfy the request of the request message are sent to one or more host processors; and information received back from said one or more host processors is assembled into one or more reply messages to be sent to the requesting client process. Thus, communication sessions are not required between each client processor and each host .
The invention is also directed to a method of communicating information between one or more client processes running on respective client processors and one or more server processes running on one or more host processors by way of message driven processor which translates request messages from a client process into one or more transactions one or more of which may be sent to a server process which involves sending a request message from the client process to the message driven processor, the request message containing a Message Header identifying source and destination of the message, a Message Specific Header identifying a particular type of business level request and a Message Context Area portion containing data related to the request and receiving from the message driven processor one or more reply messages containing information requested. In apparatus for communicating information between one or more client processes running on respective client
processors and one or more server processes running on one or more host processors by way of message driven processor which translates a request message from a client process into one or more transactions at least one or more of which may be sent to a server process, the inventions relates to a method of testing executable workflow objects by simulating inputs required for the workflow object and applying them to the input of the object, simulating an object receiving an output from the workflow object and testing execution flow of the workflow object by monitoring specified variables during program execution and by selectively stepping through work flow object execution one access point at a time and by setting predetermined entry points at certain points during workflow object execution to permit detailed analysis of the state of the workflow at specified points during workflow object execution.
The invention also relates to apparatus for communicating information between one- or more client processes and one or more server processes by way of a message driven processor which translates a request message from a client process into plural transactions at least two of which are sent to a server process, by dispatching transactions which do not depend on the results of each other from the message driven processor, substantially concurrently, to the one or more host or server processors and then assembling replies received from the host or server processors into one or more reply messages to be sent to a client process which sent said request message.
The invention also relates to a method for communicating information between one or more client processes running on respective client processors and one or more server processes running on one or more host processors by sending a request message from a client process to an intermediate process, establishing a
session control block at the intermediate process, accessing a request profile characteristic of the particular message sent to the intermediate process to identify transactions required to satisfy the request of said message, establishing one or more control blocks as part of the message control block for transactions, selecting transactions for dispatch to one or more server processes, dispatching, concurrently, those transactions which do not depend upon completion of earlier dispatched transactions by retrieving a request view of data contained in the session control block and packaging that data into a workflow request, establishing or accessing a previously established communications session to a host running the server process required to satisfy the transaction and sending the workflow request to the host, receiving a response from a replying host or server, mapping data received from that host or server into a reply view of data, storing the reply view of data in the session control block; and assembling one or more reply messages from data stored in the session control block and sending the reply message (s) to the requesting client process.
The invention also relates to a method of constructing screens for packaging information to be sent to a server process for retrieving information or to a client process for obtaining information from the client to be sent to a server process by storing a map of screen information received from a server process, associating specific areas on the screen with variable information to be sent to or received from the server; and saving said bit map with representations of variable information for transmission to said server process.
The invention also relates to a hierarchical message driven client-server system which has a plurality of sets of client processes running on respective client processors, one or more server processes running on at
least two host processors, a first level message driven processor for translating a request message from a client process into one or more first level transaction messages required to satisfy the request, one or more second level message driven processors for translating a request message from a client or a transaction message from a first level message driven processor into one or more second level transactions required to satisfy the request, client agents for providing message based connectivity between a client process and said first level message driven processor, server agents for providing connectivity between the first and second level message driven processors and the server processes; and apparatus for assembling reply information from a second or higher level server process into one or more reply messages and sending the reply message to the client process which sent the request message. As a result, a request message from a client processor is translated into transactions and transactions are selectively sent to one or more host processors in a hierarchy of host processors and information retrieved is returned to the client in satisfaction of the request message.
The invention also relates to apparatus for communicating information between one or more client processes running on respective client processors and one or more server processes running on one or more host processors by way of message driven processor which translates a request message from a client process into one or more transactions, comprising one or more workflow objects, at least one or more of which transactions are sent to a server process, a method of generating executable workflow objects by interrogating a user as to information needed to define a workflow object, incorporating that information into a skeleton of source code, so that the combined information and skeleton constitutes a complete source code list, compiling the
source code list into executable code, and storing the executable code as a workflow object which can be selectively incorporated in workflows to satisfy a request from a client . Still other objects and advantages of the present invention will become readily apparent to those skilled in this art from the following detailed description wherein only the preferred embodiment of the invention is shown and described, simply by way of illustration of the best mode contemplated of carrying out the invention. As will be realized, the invention is capable of other and different embodiments, and its several details are capable of modifications in various obvious respects, all without departing from the invention. Accordingly, the drawings and description are to be regarded as illustrative in nature and not as restrictive.
Brief Description of Drawings
Figure 1 is a diagram utilized to illustrate the problems associated with merger of two different organizations.
Figure 2 is an example of how a particular business request results in multiple transactions necessary to satisfy that request.
Figure 3 is a diagram of session management in a multi-host, multi-client, client-server system.
Figure 4 is an overview of the message driven architecture of the invention.
Figure 5 is an illustration of the basic message format at the application level. Figure 6 is a diagram of the functional components of the message driven processing system of the invention.
Figure 7 is an illustration of the connectivity between client networks and back-end servers using the work flow manager of the invention.
Figure 8 is an illustration of how a request is translated into a transactional work flow for delivery to back end servers.
Figure 9 is an illustration of how the session control block is utilized in the decomposition of incoming messages and the composition of reply messages.
Figure 10 is a flow chart illustrating one example in which a customer service representative initiates a request message receives information back from a back end server.
Figure 11 illustrates an example of how the back end server replies to a request from the work flow manager and how it is processed into one or more reply messages to be sent to the customer service representative. Figure 12 is a flow chart of the work flow object builder.
Figure 13 shows compilation of a work flow object into executable code.
Figure 14 is a flow chart of a skeleton of one type of workflow object (a message handler)
Figure 15 shows diagnostic processing with simulation.
Figure 16 shows diagnostic processing using debugging. Figure 17 is an illustration of how MDP processors can be utilized in an hierarchal arrangement.
Best Mode for Carrying out the Invention
Figure 4 shows the invention at a high level. A number of end user clients 400 are connected to a client connectivity layer 410. Similarly, a number of servers 440 are connected to a server connectivity layer 430. A work flow management layer 420 mediates between the client connectivity layer and the server connectivity layer performing the work flow management functions.
This architecture permits the user, with no knowledge of data location, to approach the entire network as if it were a single entity.
The invention provides any to any (or many to many) connectivity using application to application communications and a work flow processing environment between front end requests for service, by clients, and back end applications running on hosts or servers.
A client connectivity layer 410 insulates the business process from device specific protocols. A work flow management layer 420 including development section 421 and run time section 422, decomposes a complex request into several individual transactions and recomposes the results of those transactions into one or more replies. A server connectivity layer 430 works in conjunction with the work flow management layer to permit connectivity to back end applications which have been inherited from the merging organizations (legacy applications) as well as newly engineered back end systems for which common application programming interfaces are available. The client connectivity layer allows multiple, disparate clients to request the same services, regardless of front end protocols and device types. Clients interact with client agent interface programs, which filter out device-specific protocols and allow business requests, in the form of messages, to be passed on to the workflow management layer.
The client connectivity layer behaves as a connectionless environment to fully accommodate synchronous and asynchronous client/server requirements. The client connectivity layer accomplishes the following functional objectives.
Supports device-specific protocols to a variety of industry-standard device types to perform the application-to-application communications necessary to send a request and receive a reply.
Provides create, continue and reattach capabilities for a logical session.
Establishes a session control block, an internal application program interface memory management area used by the workflow manager during execution of the request's workflow, and for overall memory management processing.
Terminates and archives a logical session and, upon signoff, deletes the session control block.
The client connectivity layer is composed of three basic modules: client agent, input request manager and output reply manager
A client agent is a device driven program responsible for communications and protocol in relation to the sending and receiving of requests and replies, and communication error recovery. This program also allows for custom user exit points for use in such things as journaling. Client agents receive request messages from the client and direct them to the input request manager, and receive reply messages from the output reply manager and send them to the client.
The input request manager is the primary entry point of request messages into the MDP. Apart from performing session establishment, security checking and client validation and registration functions, the input request manager can also be a custom-coded entry point into the workflow manager. This means that the input request manager can translate disparate front end message protocols into MDP message formats, allowing clients with existing application message formats to be accepted by the workflow Manger. In this manner, the integrity of the application program interface is preserved.
The input request manager performs the following functions.
Receives or retrieves request messages, depending on task initiation.
Validates security and registers clients.
Processes session reattach functions. Creates the session control block and completes associated memory management tasks.
Manages allocation of multiple message control block areas when required for concurrent processing of requests. Processes and journals session errors.
Accesses the reply profile to stage the output reply parameters when a reply is to be sent from the workflow Manager.
Journals request messages. Processes application program interface extension user exit points, allowing application level protocol translation and message reformatting.
Accesses the request profile to determine special attributes associated with the request, and validates the request's request profile against the request profile file.
The output reply manager supports the reply side of message processing. The output reply manager is initiated by the workflow manager when the unit of work is complete. The output reply manager then formats the reply message from the session control block. Next, the output reply manager uses the reply profile parameters, loaded previously in memory, to determine the proper reply process, and sends the completed message back to the client, via client agent module, if applicable. The output reply manager is also designed openly, allowing customization to be implemented where necessary.
The output reply manager performs the following functions : Uses the reply profile parameters, loaded into memory previously by the input request
manager, to determine how the reply should be sent to the client.
May initiate client agent module.
Maintains/updates session file record upon completion of the request.
Maintains the session control block for subsequent request message processing, or deletes the session control block upon signoff. Manages deallocation of message control block areas upon completion of concurrent requests.
The workflow Management layer is made up of two environments that control the enablement, generation, and processing of messages in the form of workflows. workflows, whichcontain executable workflow objects that together fulfill the requirements of a request, are created in the development environment, and then executed in the run time environment. The major system component of the development environment is the workflow object builder. The major system component of the run time environment is the workflow Manager.
At run time, the workflow Manager is initiated by a request message which it receives as input. Since the workflow Manager is not responsible for the initial receipt of the Request (nor its resulting replies) , it is not encumbered by network dependencies that would limit the reusability of a workflow. The processing which begins with a request and ends with one or more replies is done within the workflow. A workflow can represent a very simple or a very complex function. Typically, the more complex the function, the more units of work there will be in the workflow. To complete a complex workflow, the workflow will decompose the message received and invoke a synchronous unit of work and, perhaps, one or more asynchronous units of work, to independently retrieve
information from different sources as necessary and process it. Asynchronous units of work may execute waited or nowaited. Based on design of the unit of work, the workflow recomposes the resultant information in the session control block memory management area into a reply, which is then sent back to the client. Between the workflow Manager and the workflow, the complexity of the business function is removed from the client. This concept of complex transaction enablement lets the client make simple single requests for services, and receive simple single replies or a series of replies, in return.
To gather information from the required sources, a workflow may provide connectivity between the workflow
Manager and multiple disparate back end systems. This contributes to the single system image viewed by the client. In this respect, the workflow becomes a network server component that any client in the enterprise can access just by issuing a simple request. (Also eliminated is the need for multiple logons) . Since Request design is based solely on actual business functions or processes, any client in the enterprise can issue the same request and access the same business function, promoting a great deal of reusability, convenience and consistency. At the center of MDP is workflow Management. The development and execution of workflows to satisfy the requirements of request messages, fast path business request messages and the signon and signoff request messages is the nucleus around which the enterprise can build an effective, efficient, and consistent processing environment .
A workflow may be organized into one or more units of work; each unit of work performs a part of the overall business request . A workflow contains one synchronous unit of work and optionally one or more units of work that may be dispatched to execute substantially
concurrently. The smallest unit of work that is capable of executing by itself is a workflow object. A workflow typically consists of multiple workflow objects.
Session Control Profiles link initiation of the execution of the workflow to reception of a Session Request Message.
The MDP receives a request message which contains a request profile ID, which in turn points to the first workflow object or profile in the workflow. Using data in the request message, workflow execution then begins.
The MDP may receive a standard or extended signon request message or a signoff request message, which may indicate the first workflow object or object profile. Using data in the standard or extended signon request message or signoff request message, workflow execution then begins.
MDP also supports the fast path business request message, a method to conserve memory by supporting the logical session for only those clients whose workflows are currently in progress and a method of supporting MDP to MDP communication.
The workflow may execute using data from one or more sources:
Data from the request message, Data created during workflow execution,
Data retrieved from user-defined files via user exits,
Using ancillary products, data acquired from other back end hosts or applications. Depending on design and on the outcome of the workflow, the workflow may result in one or more of these Disposition actions:
Reply message to the client,
Storage of the request on the store and forward queue for scheduled execution later,
Storage of this workflows data on another queue, for processing by another workflow or by a special purpose system request message,
Stoppage of processing with no further action. During a logical session, MDP may receive a subsequent message that points to a new workflow.
Further, MDP supports execution of multiple concurrent workflows, initiated by multiple messages from the same client . The workflow Management development environment provides menu-driven workflow building tools that allow the developer to:
Define and generate data definitions of all input, output and intermediate storage areas and message formats.
Define and generate workflow objects of different types to interact either synchronously or asynchronously with the workflow Manager and back end systems. Simulate the execution of, and debug, workflows.
Define parameter information necessary for interaction with Server Agent.
Access utilities that support the development process for generating, compiling and copying workflow object definitions.
The work flow management layer is made up of two principal environments that control the enablement, generation and processing of messages in the form of work flows. They are created in the work flow development environment 421 and then executed in the work flow manager run time environment 422. Work flows contain executable objects that together fulfill the requirements of a request .
The Major components of workflow development include the workflow object Builder which is a tool that is used to define and generate complex units of work in the form of a workflow. The component allows the developer to
define the attributes of each workflow object associated with the workflow. Data Dictionary Maintenance is also included in workflow development. A Data Dictionary Builder provides data definition capabilities over the user accessible item areas of the session control block. All item areas relating to user-defined message areas are variable length. This allows the developer to define the maximum space requirement for each business function, making for an efficient use of space. At run time, the work flow manager is initiated by a request message which it receives as input. Since the work flow manager is not responsible for the initial receipt of the request (nor its ultimate reply to the requester) , it is not encumbered by network dependencies which would limit the reusability of a work flow. The execution of an output reply by the work flow manager marks a completion of a work flow. The processing which begins with a request and ends with a reply is also called a unit of work. A work flow can -represent a very simple or a very complex function. Typically the more complex the function, the more pieces there will be to the associated work flow.
To complete a complex unit of work, the work flow will decompose the message received and invoke several tasks to independently retrieve information from whatever different sources are necessary. Upon completion of all individual tasks, the work flow manager manages all of the information placed into the session control block, to be described hereinafter, into one or more comprehensive replies which may then be sent back to the client. Between the work flow manager and the work flow, the complexity of the function is removed from the client. This enables the client to make simple single requests for services and receive simple single replies in return.
To gather information from the required sources, a work flow may request connectivity between the work flow manager and multiple disparate back end systems. This contributes to the single system image viewed by the front end client. The work flow just becomes a network server component that any client in the enterprise can access just by issuing a simple request. This eliminates the need for multiple logons. This also allows an enterprise to add value to existing back ends while evolving newly engineered functions and presentation capabilities on the client's side. Since request message design is based solely on actual business functions or processes, any client in the enterprise can issue the same request and access the same function promoting a great deal of reusability, convenience and consistency. All requests from the client and all replies to the client are formatted in a basic message format illustrated in Figure 5.
The common message header labels all message traffic to and from the Client. It uniquely identifies the requesting Client and associates the unit of work requested with that Client. The common message header is carried in all required Request and Reply Message exchanges associated with the request or the logical session.
The Message-Specific Context Header varies in content with each specific message type and defines static fields that must be populated by the requesting Client and becomes the context for each message type. The data in these fields correspond with functions performed by the various layers in the workflow Management environment .
The Message Context Area includes variable length data used to supply user-defined and formatted data to a particular Business or System Request. The developer decides the length, content and the request and reply
format during the workflow Development phase. After the Request is defined, the workflow Manager will associate the Request with a workflow. The workflow is developed to accept data from the request format and, eventually, map data to the reply format of this segment after processing has been completed. The format of the data in this segment can vary with each Request and may even vary within a Request. This segment is defined by the developer based on the needs of the Request. These three basic components provide a basis for both Request and Reply Messages. The Common Message Header and the Message-Specific Context Header are required of all messages and are fixed length segments. The Message Data Context Area is of variable length, defined by the developer, based on the needs of the system request or business function.
Figure 6 illustrates the message driven processor 450 in greater detail. A set of client agents, 610, act as protocol engines to insulate the work flow management layer 620 from the different protocol layers which wrap the illustrated in Figure 5.
On the back end, server agents 630 perform a similar function. A message handler 633 formats data to be sent to back end servers and passes it to either FEPI object 634, NVAS object 635 or dispatcher-responder pair 636A and 636B where the interaction with the back end server is handled. Independence from back end server protocols is achieved by server agents 630.
Work flow management will be described more in detail hereinafter.
Figure 7 illustrates the processing of a message from a client up to the work flow manager level shown in Figure 6. The message driven processor has a number of network ports, 710, each of which services a corresponding network. Each network is characterized by a communications protocol which specified how stations on
the network interact. Protocols LU6.2, LUO and LU2 are protocols generally utilized in an IBM environment. CICS stands for Customer Information Control System which is an IBM product permitting access to application programs associated with it, formatting information in a manner analogous to a formal protocol . MQI stands for Message Queuing Interface and represents protocols associated with the MQ™ Series software product by IBM. MQ™ Series simplifies communications by utilizing a simplified command set.
Returning to Figure 7, each of the client agents, 720, manages communications below the application layer passing only the application level message to queue 725 for delivery, in turn, to the input request manager 730. A client wishing to sign on to the message driven processor may do so in one of two modes. If a great deal of transaction volume is expected from that client over the course of a day, the client may wish to sign on and remain permanently signed on to the system. On the other hand, if only occasional access is required, a session may be established only for the duration of each request. Session profile/sign-on control 735 manages sign-on in accordance with the session profile which is selected based on the content of the sign-on message received from the client. Which method of sign-on is preferable depends on the amount of overhead required in establishing and tearing down session control blocks, described hereinafter.
A Client sends a sign-on request message in preparation for the day's processing. The sign-on request message may be transported from the LAN server to the host via a LU 6.2 transport. The LU 6.2 Client Agent program is initiated and any data conversions or protocol specific logic is performed at this time. The Client Agent starts the Input Request Manager.
MDP determines the file base and processing mode. The
Client Profile file is read and the Session Control Request Message is validated. The Session file is read to determine if a session had already been established for that Client. The Request Profile file is then read to determine the detail parameters of the Sign-on Request, and optionally may point to a workflow or workflow object to be executed at sign-on. The Reply Profile is read to determine the reply characteristics. Since this is the first sign-on of the day, a Session record is written. Sign-on processing controls overall processing of the Client's session, controlling access to workflows and data stored on the host, based in part on the Client's assignment to an MDP Office. Once all file processing has been successfully completed, the request information is formatted and a session control block is created. The Client Profile is rewritten with a Client Session ID. The Input Request Manager then initiates the workflow Manager.
The workflow to which the sign-on- request message may point as an option may support more complex processes such as logging on to the back end servers.
Alternatively, a fast path business request message may be sent at any time - without regard to whether an MDP session is established for this Client. It my be used to immediately begin processing a workflow, without previous sign-on. The Request Message and the Fast-Path Business Request Message may contain data for the workflow to process. Both the Request Message and the Fast Path Business Request Message point to a Request Profile ID. The Request Profile ID points in turn to the workflow.
Associated with each possible request submitted by a client is a request profile. These profiles are accessible in block 730 and 750 of Figure 7. A request profile is a decomposition of the incoming business
request into units of work or workflow required in order to satisfy the request.
To illustrate the use of a request profile, in the example shown in Figure 2, according to the invention a request in the form of a message to approve a loan illustrated as step 2 would be decomposed into four different requests for information as defined by the request profile, one to retrieve a credit history, one to retrieve an account balance, one to retrieve credit card status and one to confirm bank fund availability to fund the loan. The individual requests which make up the profile of the request from the client are then processed by the work flow manager environment where they are individually packaged for sending to the back-end servers. Once all of the replies to the separate transactions have been received back, the information is assembled into one or more reply messages and sent to the output reply manager 770 where it is queued for transmission to the client using the specified client agent. The outgoing application level message is sent to the client in the protocol appropriate for the network by the client agents and sent to the client.
Work flows are essentially composed of a series of work flow objects, whether they are individual objects or a plurality of objects grouped together in object profiles, and routing parameters for processing instructions defined at the request profile level to direct the order of execution of the work flow objects. A work flow object is a generated program designed to accomplish a specific task or function, allowing its reusability by multiple work flows. Work flow objects are generated dynamically by the work flow object builder and may themselves contain internal routing parameters, which are defined within the work flow object. Although work flow objects are designed to be executed from within a work flow, they can be created work flow independent.
The reusable nature of work flow objects allows them to be associated with multiple work flows, each of which may use the object in a different scenario. A work flow object processing sequence may be incorporated alone into a work flow or it may be part of an object profile which contains a processing series of work flow objects. Like work flow objects, object profiles can also be reused by multiple work flows.
Figure 8 illustrates a typical request message, its decomposition into a transactional work flow, the execution of the work flow and the composition of one or more reply messages to the client requestor and queuing steps required to complete the business flow.
A request is received at the input request manager 800 which accesses the request profile in storage 805. In this particular instance, the request requires three units of work to complete. These are labeled A, B and C in the drawing. Separate storage areas are set aside for the request and reply data. In each area, a separate storage area belongs to each of the units of work required to complete the request . The work flow manager 810 determines that units of work objects A and B can be executed concurrently and that unit of work C must await the completion of units of work A and B. Work flow manager 810 dispatches unit of work A at step 820 and unit of work B at step 830. Step A work flow object A involves viewing the data (821) associated with the client request message to extract the data needed to formulate the transaction associated with work flow object A. Once the request view of the data is obtained, the two branches 822 and 823 of processing utilizing that data can proceed culminating in steps A5 and A6 in unit of work A which access one or more host computers to retrieve data. A similar process occurs with work flow object B as illustrated in the work flow 830 including Bl through B3 shown in the drawing. As
units of work A and B are executed, the reply data is returned to storage area BR2 (807) and stored in respective blocks A and B. Step C, the final step in the work flow, takes the data from A and B, does data correction, checking and error handling, and passes reply data to area C of reply area BR2. Reply profile data 850 is utilized to determine how the data in the reply area is to be sent to the client using a client agent, if necessary. Once a reply message is sent, the storage areas dedicated to the request are freed up for use by other processes.
The data dictionary/message definition support 631 shown in ' Figure 6 is used to design, generate and maintain data dictionary entries (chapters) which map storage areas to data elements and structures
(principally in the session control block) , for use by work flows. Data item areas, user files, temporary storage and request and reply messages are normally defined and dynamically maintained in data dictionary chapters and are used to direct data placement during work flow processing.
The request and reply storage areas 806 and 807 of Figure 8 represents a common memory area for the operation of a work flow called a session control block. The session control block provides storage needed for memory and data management for the entire work flow which comprise a plurality of message control blocks. The session control block is composed of several item areas, maintained in temporary storage, that pertain to specific messaging objectives within the system. As shown in Figure 9, a session static area 901 is defined for each session with a client and is established during MDP logon. A message control block 930 is established for each concurrent request message received from the client. More than one message control block may be used concurrently. A message control block comprises a
workflow static area and one or more workflow dynamic area 920. Data dictionary maintenance provides data definition capabilities over the user definable item areas of the session control block. All user definable item areas are variable length.
The session control block allows the MDP session to maintain a connectionless, non-blocking conversation with a front end client and to maintain the data for all work flow objects. Each message control block is primarily made up of two temporary storage areas one containing static item areas and one dynamic item areas. The workflow static area of the message control block contains a workflow static item area 911 and a workflow dynamic area 920. The workflow static area (workflow area) has a system-reserved area containing static information that relates to one workflow. This item area cannot be modified, -but may be browsed.
The request area contains the request message and reply area which may contain one or more reply messages sequentially to be sent back to the client.
Figure 9 illustrates in more detail the operation of the session control block. When a request message is received, a message control block is created as discussed above. In the workflow static area 911, the request data received with the request message is written in block 913. Similarly, when all information has been received from the back end server, and from internal processing in the work areas of the workflow dynamic block the work flow manager .930 may assemble data into the reply message data format in the reply section 914 of the message control block. That message data is then passed to the output request manager 940 where it is sent to the client requestor. The global area is used to store event user data throughout the length of a workflow typically used to
collect data for use in multiple workflow objects and during asynchronous workflow processing.
The workflow dynamic area 920 contains 3 work areas, pre-defined in a set of data dictionary entries, and a dynamic system area containing data relating to a workflow object and its processing.
One should distinguish between the session control block created when an MDP session is established and a communication session. Typically, communication sessions are transitory, operating in the connectionless mode. That is, the client and the client agents interact only long enough to receive the message and acknowledge the message. The communication session, does not typically remain active during the processing required to obtain the request data. When the requested data has been obtained, one or more reply messages will be sent to the client requestor in the connectionless mode. The message control block, however, which defines the data request session, remains active throughout the lifetime of the processing until all reply messages are sent to the client. Thus, even though a communication session is not continuous throughout the processing, an MDP session is normally maintained until a logoff request is received from the client requestor. As set forth herein, a client requestor may logon to the MDP for only the duration required to process a single message via fast path processing, or, where high transaction volumes are expected, for a larger duration such as all day. As used in this sense, logging on involves establishing a session control block for the client requestor. Similarly, message control blocks will be freed up when the reply to the message from the client is sent.
Figure 10 is a flow chart of an example of the work flow process. from the time a request message is received (1001) to the time a transaction request is dispatched to
the server 1050. The reply process is depicted in a flow chart in Figure 11.
As shown in Figure 10, a customer service representative initiates (1001) a request message. The message is received at the MDP and a message control block is established (1005) as described above. The request profile for the type of the message received is accessed (1010) and the message control areas are updated. If an unexecuted unit of work from the profile can proceed concurrently with other units of work, the workflow manager dispatches the unit of work and processing of the work flow object begins. If it cannot, it checks.to see if there is an ongoing unit of work and if there is it will delay (1060) until a unit of work completes. If there is no ongoing unit of work, the next unit of work will be dispatched (1030) . Upon dispatch, the request view of the input message data is retrieved, a session to the back end host established (1045) and a transaction request sent to the host. As shown in Figure 11, when the reply comes back from the host 1101 the response mapped into a reply view of the data at 1110 and the reply is stored (1120) in the workflow dynamic area of the message control block. The results are assembled from the workflow dynamic areas to a Reply Message Data area 914 in the workflow static area of the message control block (1125) . If all necessary responses have not been received and no-wait is not active, nothing happens (1150) but if all responses have been received (1150) , the output reply manager is invoked and one or more reply messages are sent (1160) to the customer service representative. In a no-wait mode, multiple reply messages are generated from work flow dynamic blocks as responses are received.
There are several types of request messages. One is the session control message. Another is the business request. A third is a system request. In the run time
environment, when clients actually execute work flows to perform business functions, an MDP session must first be established for the client in the MDP before the process of sending requests and receiving replies can take place. To establish and end a session, a session control message must be sent from the client to the MDP.
A session control message will not necessarily have a work flow associated with it. All it may be is a simple message sent to the MDP requesting a session be started and a session control block be established. When ending a session, all the message may require is the deletion of the session control block and little else. However, the option of associating specific tasks with a session control message opens the door for the client to possibly perform automatic logons to back end systems, as well as any other standard start up tasks. Completion of these tasks can be indicated to the client in the form of one or more reply messages.
The work flow object builder is a flexible code- generator that creates work flow objects suited to perform specific elementary tasks. These objects, when strung together in routing sequence or profile, collectively form a work flow. A work flow, designed to fulfill tasks associated with a request, or unit of work, is triggered by a request profile and executed by the work flow manager. For example, some work flow objects may access back end systems via NV/AS™ (Net View/Access Services) , FEPI™ (front end programming interface to CICS) , MQI (MQ™ Series interface) and others mechanism or protocols) . Some units of work may run substantially concurrently (sometimes called asynchronously) as permitted by an object profile. Some work flow objects may be designed specifically for data manipulation or for checking data obtained by other work flow objects.
The final work flow object in a work flow or unit of work will typically construct one or more reply messages to be sent back to the front end client.
There are several types of work flow objects namely message handlers, dispatchers, responders, NVAS work flow objects and FEPI work flow objects. A work flow object that accesses information contained in one or more of the items in temporary storage from the session control block and uses it to make routing decision or to format output message views that may be required to obtain information from other systems is called a message handler. Message handlers are not typically designed for reusability by multiple work flows since much of their purpose is specific to a certain request. The decomposition of a request message and recomposition of one or more reply messages will most likely be found in this type of work flow object. Message handlers will also be used to perform miscellaneous processing functions such as VSAM file I/O, interface to a database, etc.* A dispatcher is a work flow object defined for use as part of a pair of objects. Used with the responder, dispatchers initiate transactions using an MQ series™, a CICS peer-to-peer, an LU6.2 or other mechanisms or protocols. Dispatchers are typically used when it is necessary to execute a task that is external to MDP. A dispatcher is primarily responsible for setting parameters associated with the external task, such as PUT queue name, responder name, etc. The dispatcher/responder pair is inherently a sequential (sometimes called synchronous) process. Once something is dispatched the work flow unit of work waits for a response. However, dispatcher/responder pairs may be part of a concurrent (asynchronous) object profile.
Responders get involved after the external target task is completed and the MDP resolution processes have been invoked. A responder receives information from the
target task in the session control block item area defined at dispatcher development time.
NV/AS, FEPI and other work flow objects which can accommodate a variety of different platforms perform 3270 emulation to retrieve data and map from back end applications into the session control block.
In the process of building a work flow object, the developer specifies the type of work flow object to generate and then is guided through a building process. The building process is set forth in Figure 12. The start of the development process involves a definition of message layouts (1200) . Here, specific field definitions for incoming and outgoing messages are defined and stored in a data dictionary 1405. Certain views of message data are generated in the form of copy books or structures (1210) and are available for use during the definition, design and development of the object. Certain implementation specific workflow object parameters are optionally defined at 1220. At 1230, data elements used as input and output within the module are defined, optional edits applied and named object data elements information stored at 1235. Object routing optionally defined at 1240 specifies, inter alia, the order in which workflow objects are executed, and the routing information is stored at 1245. The developer defines certain decision making logic at 1250 which is stored at 1255. Certain user exits are identified at 1260 through which calls to user developed sub-routines (1275) and standard library (copybook) functions can be incorporated selectively. User exits are named and their identifiers stored at 1265. Once a developer has been guided through this process, sufficient information has been stored to submit the object specified in the process of Figure 12 for code generation. Figure 13 illustrates the code generation process.
The work flow object generation process 1300 incorporates
all of the development information stored from a user during the development process and integrates it with work flow object skeletons 1320.
Each type of work flow object has a predefined source code skeleton consistent with its particular function which is used as the infrastructure for creation of object source code 1330. The object skeletons 1320 are fleshed out in object generation block 1300 by incorporating the information captured at 1310 and stored into the final source code. Once all of the user defined information has been integrated into the skeleton, a complete source code block exists at 1330 and can be optionally submitted for compilation (1340) . Once compiled into executable code, the object may be utilized as part of a work flow needed to satisfy a request (1350) .
Figure 14 is a high level flow chart of a skeleton of a message handler 1320 from Figure 13. The skeleton begins (1400) with reading the session control block 1405. Selective access to the debugger is provided between blocks 1405 and 1410 to permit the state of the input information from the SCB to be captured for evaluation. Initial decision making logic 1410 processes logic defined during the development process. Input block 1420 performs data validation and checking, edits and table translations that otherwise prepare the data for the main processing functions 1425. The main decision making logic is predefined for each type of work flow object and its source coding included in block 1425. Main user exit 1430 permits the incorporation of source code modules previously developed and stored in library for the inclusion of user developed routines into the overall source code stream. Output block 1435 is analogous to input block 1420 and prepares data for output from the work flow object. The next decision making logic 1440 is predefined for the object and user
exit 1445 permits the user one additional opportunity to customize the module by incorporation of library or custom subroutines . Routing for the output data is optionally defined at 1450 and ultimately, the session control block is updated with the final versions of data processed by the work flow object (1455) . Selective access to debugger is provided after block 1455 to permit the changes to the SCB caused by object execution to be captured for evaluation. The source code ends at 1460. Internal routing from one work flow object to another can be defined during the work flow building process to be either static or dynamic. Dynamic routing can be based on data content and/or context within the session control block. All the work flow object characteristics and parameters are stored in the work flow object definition and decision making files. These files are referenced during the batch work flow object generation process in which the parameters are converted into CICS command level source code, then compiled and linked into an executable module.
Debugger/simulator modules shown in of Figure 6 are available typically in the development environment to provide testing support for work flow objects.
Bypassing part of the protocol layer, the Debugger/simulator modules allow simulation and diagnostics of workflows to allow the developer to examine the session control block through all of the major processing steps in all of the workflow' s objects. It also allows performance analysis and automated testing. If the workflow acquires data from back end hosts and applications, this data is incorporated in the workflow' s processing as well. These two special development features help developers test workflows before subjecting them to the condition of network level testing with custom front end applications.
The simulator formats and submits certain session control messages in order to simulate a client who is requesting services. The simulator allows for the input of user data in all request messages. The data can be typed in free form or can be formatted via a data dictionary.
The simulator also allows the active message buffer to be written to the input request file. This file is used as the simulator's depository for request messages. With the potential for large or numerous messages, this file can be used to store data and eliminate the need for time consuming data re-entry.
The simulator can replay any message stored on the input request file by loading the record into the active message buffer. The data can then be modified prior to being sent in a request message. All input request messages can be updated on the file or deleted from the file. The data can also be used as a template to create additional request message data formats. In the case of an error, the simulator can display available information about the source of the error. The simulator can also display the header of the reply message that MDP generates in response to the simulator client's message as well as providing view capabilities of the session control block.
In addition, the simulator has been integrated with the workflow debugger to allow for simulation and diagnostics from a single terminal. This allows the simulator to turn debugging on and off on the processing of each message. The workflow debugger has the ability to capture data from the request item area of the session control block and store the data in the input request file. The simulator also provides the ability to terminate processing by performing the appropriate signoff request messages or by archiving the current session on the host.
The simulator may be used as an aid in network level testing with custom front end applications. The simulator can send a message that is identical to a target message sent from a front end application on a client or a client work station. The journal display can be used to confirm that the two messages are identical . If the simulator has already tested the workflow that is associated with the target message, and if journal display confirms that the simulation message and the target message are identical, then it is likely that the problem lies with the custom front end application.
The system provides run time diagnostics through the use of the workflow debugger, providing the ability to interactively debug the workflows that support the processing of Request Messages. This is accomplished by executing the workflow in a terminal-associated fashion, thereby allowing screen display and interactive user intervention at the host level.
When the workflow debugger is activated, pre- selected workflow objects will become terminal-associated at various exit points and will provide the following features:
Display of the session control block.
Symbolic mapping at the field level for each session control block item.
Field level data manipulation.
Save Request data to the Input Request file for use with the Simulator.
Debug processing control (i.e., abort Request Message, terminate debugging, etc.) .
The workflow debugger allows all items of the session control block to be symbolically viewed. An initial screen will be displayed showing all items and the symbolic chapter that will be used to map the item. The process of starting the workflow debugger is generated at two exit points in every workflow object.
The first exit point is before the main logic is performed, immediately after the session control block has been read into the program. The second exit point is at program completion, after any session control block updates have been processed. In addition, there are two symbolic views available to the workflow debugger for each item: active and prior. The user can toggle between these views.
Through the use of symbolics, session control block data can be displayed and manipulated at the field level. From the initial workflow debugger screen, a session control block item area can be selected and displayed via the Symbolic Mapping Utility. A list processor of symbolic fields used to map the selected item area displays, allowing the user to list and search for fields by name or offset. Left/right scrolling capabilities are available to view the field data. Field data values may be displayed in Character or Hex Mode.
Field data values can be updated by entering an Update Mode. The user can toggle between Update Mode and Browse Mode. When in Update Mode, field data values are modifiable. Field updates are applied to the session control block.
Fields can also be optimally initialized. Alphanumeric fields are initialized to spaces and numeric fields are initialized to zero.
If the user wishes to save the request area data stored in the session control block for future testing, the workflow debugger provides that capability. This data can then be saved and reused when testing with the Simulator (i.e., without having to reenter data repeatedly) .
The user may terminate debugging at will, continue while viewing the SCB at every exit point, suspend and reactivate debugging and re-execute a workflow object.
As shown in Figure 16, the work flow debugger provides on line addressability to items within the session control block and permits data field examination and modification. If necessary, the work flow debugger may be turned on in the run time environment for setting traps and handling exceptional data conditions for real time or later analysis. In operation, debugging is started from terminal 1610.
As a request is being processed, workflow objects are initiated. If a workflow object is enabled with debug support, it will initiate debugger module 1600 at the awaiting terminal at defined entry points (see figure 14) within the workflow objects. The debugger module allows interactive data display and manipulation. Once the session control block analysis is completed, the debugger stub 1630 is started by the debugger module. The debugger stub activates the workflow 1620, to resume execution, until the next debug entry point is encountered or workflow processing is complete. In the process of creating certain work flow objects such as FEPI work flow objects and NVAS work flow objects, it is often the case that the backend host expects a set of screens of data to be presented to it in a particular order. It is possible to manually design such screens using, for example, COBOL. However, when interacting with a terminal (3270 or otherwise) the host transmits a set of data and commands which identify the locations of variables on the screen. The terminal uses these data and commands to paint the screen and to extract data for sending to the host when data entry is complete. The system of the invention captures the screen information sent from the host and uses captured screens to emulate a screen based interaction of a terminal and the host by stuffing captured screens information with the proper data and presenting those screens to the host in the order the host expects.
Server agents are analogous to client agents. These provide the protocol interface drivers, state management and error recovery to create and maintain logical sessions to the back end systems. Figure 17 illustrates how hierarchal arrangements of
MDP systems can be utilized. As shown in Figure 17 the output to the back end servers from one layer of MDP processors is utilized as the client input to the next level of MDP processors. Thus, the work flow objects executed at the lowest level may constitute a client message for the MDP server at the next higher level. Thus, entire hierarchies of MDP processors can be utilized. This is particularly convenient when one MDP processor is utilized as an office server and a number of offices are serviced by a region and the next level in the hierarchy constitutes a regional processor which provides information to the local offices served by it. This allows local offices to develop their individualized business practices while still being able to access the regional offices ADP resources. There can be, of course, plural regional offices and each local office can access one or all of the regional offices and one or more national offices. Regional or national office can access one or all of the others as desired or required. In this disclosure, there is shown and described only the preferred embodiment of the invention, but, as aforementioned, it is to be understood that the invention is capable of use in various other combinations and environments. It is capable of changes or modifications within the scope of the inventive concept as expressed herein.
Claims
1. A message driven client-server system comprising: a. a .plurality of sets of one or more client processes running on respective client processors, selectively generating request messages; b. one or more server processes running on one or more host processors providing reply information; c. a message driven processor for translating a request message from a client process into one or more units of work required to satisfy the request and for selectively sending a transaction request message to one or more server processes,* d. means for providing message based connectivity between one or more client processes and said message driven processor; e. means for providing connectivity between the message driven processor and one or more server processes; and, f. means for assembling reply information from a server process into one or more reply messages and sending the reply message to the client process which originated the request message; whereby a message from a client processor is translated into units of work and transactions are selectively sent to the host processors and information retrieved is returned to the client in satisfaction of the request message.
2. A message driven client-server system in accordance with claim 1 in which: the means for providing message based connectivity between a client process and said message driven processor comprises a plurality of client agents which handle different communications protocols which may be used by the client processors.
3. A message driven client-server system in accordance with claim 1 in which: the means for providing connectivity between the message driven processor and the server processes comprise a plurality of server agents which handle respective requests of a type usable by the server process being accessed by a transaction.
4. A message driven client-server system in accordance with claim 1 in which: the message driven processor for translating a request message from a client process into one or more units of work required to satisfy the request comprises a request profile for each type of message which a client can send which associates the request message with said units of work.
5. A message driven client-server system in accordance with claim 1 in which: the message driven processor further comprises a session control block.
6. A message driven client-server system in accordance with claim 5 in which the data contained within the session control block is defined in a data dictionary.
7. A message driven client-server system in accordance with claim 5 in which the session control block comprises a session static area of memory and one or more message control blocks.
8. A. message driven client-server system in accordance with claim 7 in which the session control block comprises one or more message control blocks having a workflow static area including a request area where information from the client related to a request is stored, a reply area where information to be sent to the client in response to the request is stored and a global work area.
9. A message driven client-server system in accordance with claim 3 in which a session control block comprises a request area from which a request view of data is obtained for use in constructing work flow requests to be sent to a server as part of a transaction.
10. A message driven client-server system in accordance with claim 3 in which a session control block comprises a reply area to which a reply view of data obtained .from a one or more servers is sent to be packaged into one or more reply messages to be sent to the client which submitted the request message.
11. A message driven client-server system in accordance with claim 1 in which messages from a client are directed to a store and forward client which comprises : a. means for receiving a request from a client, b. means for setting processing of the request for a scheduled time, and c. means for forwarding the request from the client to the message driven processor for execution when the scheduled time arrives.
12. A method of accessing information from a server in response to a message containing a request from a client process comprising: a. retrieving a request profile associated with said message containing a list of units of work necessary to complete the request contained within the message; b. sending transaction requests from the message driven processor which require server action to satisfy the request of the request message to one or more host processors,* c. receiving one or more server responses; d. formatting information received from said one or more servers into one or more reply messages to be sent to the client process which sent said message containing a request.
13. A method of reducing the number of communications sessions required in a client server system in which a plurality of client processes running on one or more client processors retrieves information from one or more host processors comprising: a. sending a request message from-a client process to a message driven processor without establishing an ongoing communication session; b. sending transaction requests from the message driven processor which require server action to satisfy the request of the request message to one or more host processors; and c. receiving information back from said one or more host processors and assembling the information into one or more reply messages to be sent to the requesting client process; whereby communication sessions are not required between client processors and each host.
14. A method of communicating information between one or more client processes running on respective client processors and one or more server processes running on one or more host processors by way of message driven processor which translates a request message from a client process into one or more transactions at least one or more of which are sent to a server process, comprising: a. sending a request message from the client process to the message driven processor, the request message containing a Common Message Header identifying source and destination of the message, a Message Specific Context Header identifying a particular type of request and a Message Data Context Area containing data related to the request; and b. receiving from the message driven processor one or more reply messages containing information requested.
15. In apparatus for communicating information between one or more client processes running on respective client processors and one or more server processes running on one or more host processors by way of message driven processor which translates a request message from a client process into one or more transactions at least one or more of which are sent to a server process, a method of testing an executable workflow object comprising: a. simulating inputs required for the workflow object and applying them to the input of the object; b. simulating an object receiving an output from the workflow object; and c. testing execution flow of the workflow object.
16. The method of testing an executable workflow object set forth in claim 15 in which the step of testing execution flow of the workflow object further comprises: selectively stepping through work flow object execution one object at a time.
17. The method of testing executable workflow object set forth in claim 15 in which the step of testing execution flow of the workflow object further comprises: monitoring specified variables at specified points during program execution.
18. The method of testing executable workflow object set forth in claim 15 in which the step of testing execution flow of the workflow object further comprises: setting traps at certain points during workflow object execution to permit detailed analysis of the state of the workflow at specified points during workflow object execution.
19. Apparatus for communicating information between one or more client processes running on respective client processors and one or more server processes running on one or more host processors by way of a message driven processor which translates a request message from a client process into plural transactions at least two of which are sent to a server process, comprising: a. means at the message driven processor for dispatching transactions which do not depend on the results of each other concurrently to the one or more host processors; and b. means for assembling replies received from said one or more host processors into one or more reply messages to be sent to a client process which sent said request message.
20. A method for communicating information between one or more client processes running on respective client processors and one or more server processes running on one or more host processors, comprising: a. sending a request message from a client process to an intermediate process; b. establishing a session control block at the intermediate process comprising a session static area and one or more message control blocks containing a request data area and a reply data area; c. accessing a message profile characteristic of the particular message sent to the intermediate process to identify units of work required to satisfy the request of said message; d. establishing one or more workflow dynamic areas as part of the session control block for transactions; e. selecting transactions for dispatch to one or more server processes; f. dispatching, concurrently, those units of work which do not depend upon completion of earlier dispatched units of work by retrieving a request view of data contained in the session control block and formatting that data into a workflow request; g. establishing or accessing a previously established communications session to a host running the server process required to satisfy the transaction and sending a transaction request to the host; h. receiving a response from a replying host; i . mapping data received from a replying host into a reply view of data; j . storing the reply view of data in the session control block; and, k. assembling one or more reply messages from data stored in the session control block and sending the reply messages to the requesting client process.
21. A method of constructing screens for packaging information to be sent to a server process for retrieving information comprising: a. storing screen information received from a server process; b. populating variables contained within said screen information corresponding to specific areas on the screen with variable information to be sent to the server; and c. transmitting said variable information to said server process.
22. A message driven client-server system comprising: a. a plurality of sets of one or more client processes running on respective client processors; b. one or more server processes running on at least two host processors; c. first level message driven processor for translating a request message from a client process into one or more first level transaction messages required to satisfy the request; d. one or more second level message driven processors for translating a request- message from a client or a transaction message from a first level message driven processor into one or more second level transactions required to satisfy the request; e. means for providing message based connectivity between a client process and said first level message driven processor; f. means for providing connectivity between the first and second level message driven processors and the server processes,* and g. means for assembling reply information from a server process into one or more reply messages and sending the reply message to the client process which sent the request message; whereby a request message from a client processor is translated into one or more transactions and those transactions are selectively sent to one or more host processors in a hierarchy of host processors and information retrieved in response is returned to the client in satisfaction of the request message.
23. A method for processing messages from a client comprising: a. selectively generating request messages from a plurality of sets of one or more client processes running on respective client processors; b. sending one or more request messages from one or more client processes to an intermediate processor; c. at an intermediate processor, translating a request message from a client process into one or more units of work required to satisfy the request and for selectively sending at least one request message to one or more server processes running on one or more host processors; d. providing reply information from said one or more server processes to the intermediate processor; e. assembling reply information from a server process into one or more reply messages and sending the reply message to the client process which originated the request message; whereby a message from a client processor is translated into transactions and the transactions are selectively sent to host processors and information retrieved is returned to the client in satisfaction of the request message.
24. The method of claim 22 further comprising: a. receiving a request from a client, b. setting execution of the request for a scheduled time, and c. when the scheduled time arrives, forwarding the request from the client to the intermediate processor for processing.
25. In apparatus for communicating information between one or more client processes running on respective client processors and one or more server processes running on one or more host processors by way of message driven processor which translates a related request message from a client process into one or more units of work, comprising one or more workflow objects, at least one of which are sent to a server process, a method of generating executable workflow objects comprising: a. interrogating a user as to information needed to define a workflow object, b. incorporating that information into a skeleton of source code, so that the combined information and skeleton constitutes a complete source code list, c. compiling the source code list into executable code, and d. storing the executable code as a workflow object which can be selectively incorporated in workflows to satisfy a request from a client.
26. A message driven client-server system in accordance with claim 7 in which the session control block comprises one or more message control blocks having one or more workflow dynamic areas each including working storage used for processing of information needed to satisfy part of a request contained in said request message.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
AU42890/96A AU4289096A (en) | 1994-11-30 | 1995-11-29 | Methods and apparatus for implementing a message driven processor in a client-server environment |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/350,166 US5634127A (en) | 1994-11-30 | 1994-11-30 | Methods and apparatus for implementing a message driven processor in a client-server environment |
US08/350,166 | 1994-11-30 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO1996017296A1 true WO1996017296A1 (en) | 1996-06-06 |
Family
ID=23375493
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US1995/015432 WO1996017296A1 (en) | 1994-11-30 | 1995-11-29 | Methods and apparatus for implementing a message driven processor in a client-server environment |
Country Status (3)
Country | Link |
---|---|
US (2) | US5634127A (en) |
AU (1) | AU4289096A (en) |
WO (1) | WO1996017296A1 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1999063469A1 (en) * | 1998-06-05 | 1999-12-09 | I2 Technologies, Inc. | System and process for multi-enterprise collaboration |
GB2339622A (en) * | 1998-07-15 | 2000-02-02 | Ibm | Client/server computing with transactional interface between legacy and non-legacy systems |
US6119149A (en) * | 1998-06-05 | 2000-09-12 | I2 Technologies, Inc. | System and process allowing collaboration within and between enterprises for optimal decision making |
Families Citing this family (365)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5634127A (en) * | 1994-11-30 | 1997-05-27 | International Business Machines Corporation | Methods and apparatus for implementing a message driven processor in a client-server environment |
US5850518A (en) * | 1994-12-12 | 1998-12-15 | Northrup; Charles J. | Access-method-independent exchange |
JPH08190587A (en) * | 1995-01-06 | 1996-07-23 | Hitachi Ltd | Simulation system for application process |
US5889957A (en) * | 1995-06-07 | 1999-03-30 | Tandem Computers Incorporated | Method and apparatus for context sensitive pathsend |
JP3647512B2 (en) * | 1995-08-04 | 2005-05-11 | 富士通株式会社 | Maintenance method for wide area workflow system |
US6041362A (en) * | 1995-10-20 | 2000-03-21 | Electronics Data Systems Corporation | Method and system for integrating disparate information technology applications and platforms across an enterprise |
US6473609B1 (en) * | 1995-12-11 | 2002-10-29 | Openwave Systems Inc. | Method and architecture for interactive two-way communication devices to interact with a network |
US5809415A (en) | 1995-12-11 | 1998-09-15 | Unwired Planet, Inc. | Method and architecture for an interactive two-way data communication network |
US6742022B1 (en) * | 1995-12-11 | 2004-05-25 | Openwave Systems Inc. | Centralized service management system for two-way interactive communication devices in data networks |
JP3122606B2 (en) * | 1995-12-15 | 2001-01-09 | 株式会社日立製作所 | Message reception control method |
JP3434405B2 (en) * | 1996-03-19 | 2003-08-11 | 富士通株式会社 | Communication control device, communication control method, and intermediate communication control unit |
US6205415B1 (en) | 1996-04-01 | 2001-03-20 | Openconnect Systems Incorporated | Server and terminal emulator for persistent connection to a legacy host system with file transfer |
US5754830A (en) * | 1996-04-01 | 1998-05-19 | Openconnect Systems, Incorporated | Server and web browser terminal emulator for persistent connection to a legacy host system and method of operation |
US6205417B1 (en) * | 1996-04-01 | 2001-03-20 | Openconnect Systems Incorporated | Server and terminal emulator for persistent connection to a legacy host system with direct As/400 host interface |
US6205416B1 (en) | 1996-04-01 | 2001-03-20 | Openconnect Systems Incorporated | Server and terminal emulator for persistent connection to a legacy host system with direct OS/390 host interface |
US6233542B1 (en) | 1996-04-01 | 2001-05-15 | Openconnect Systems Incorporated | Server and terminal emulator for persistent connection to a legacy host system with response time monitoring |
US6216101B1 (en) | 1996-04-01 | 2001-04-10 | Openconnect Systems Incorporated | Server and terminal emulator for persistent connection to a legacy host system with client token authentication |
US6233543B1 (en) | 1996-04-01 | 2001-05-15 | Openconnect Systems Incorporated | Server and terminal emulator for persistent connection to a legacy host system with printer emulation |
US5857072A (en) * | 1996-04-30 | 1999-01-05 | Sprint Communications Co. L.P. | System and method for distributing data simultaneously to multiple computers on a network, with advanced notice to intended recipients |
US5859972A (en) * | 1996-05-10 | 1999-01-12 | The Board Of Trustees Of The University Of Illinois | Multiple server repository and multiple server remote application virtual client computer |
US5862340A (en) * | 1996-05-24 | 1999-01-19 | International Business Machines Corporation | Method operating in each node of a computer system providing and utilizing special records for collective communication commands to increase work efficiency at each node |
US6108689A (en) * | 1996-10-11 | 2000-08-22 | International Business Machines Corporation | Method and system for processing messages in a distributed computing environment |
US5964831A (en) * | 1996-10-29 | 1999-10-12 | Electronic Data Systems Corporation | Distributed on-line data communications system and method |
JP4330665B2 (en) * | 1996-10-30 | 2009-09-16 | 株式会社リコー | Client server system and image processing apparatus |
US5870545A (en) * | 1996-12-05 | 1999-02-09 | Hewlett-Packard Company | System and method for performing flexible workflow process compensation in a distributed workflow management system |
US6311225B1 (en) * | 1996-12-23 | 2001-10-30 | Nortel Networks Limited | Method and apparatus for transferring data between process modules |
US5951648A (en) * | 1997-03-03 | 1999-09-14 | Mylex Corporation | Reliable event delivery system |
US6144377A (en) * | 1997-03-11 | 2000-11-07 | Microsoft Corporation | Providing access to user interface elements of legacy application programs |
US5877759A (en) * | 1997-03-26 | 1999-03-02 | Netscape Communications Corporation | Interface for user/agent interaction |
CA2201254C (en) * | 1997-03-27 | 2002-08-20 | John Wright Stephenson | A system for automated interface generation for computer programs operating in different environments |
US6122633A (en) * | 1997-05-27 | 2000-09-19 | International Business Machines Corporation | Subscription within workflow management systems |
US6226666B1 (en) | 1997-06-27 | 2001-05-01 | International Business Machines Corporation | Agent-based management system having an open layered architecture for synchronous and/or asynchronous messaging handling |
US6338074B1 (en) * | 1997-07-23 | 2002-01-08 | Filenet Corporation | System for enterprise-wide work flow automation |
US6389479B1 (en) * | 1997-10-14 | 2002-05-14 | Alacritech, Inc. | Intelligent network interface device and system for accelerated communication |
US6226680B1 (en) | 1997-10-14 | 2001-05-01 | Alacritech, Inc. | Intelligent network interface system method for protocol processing |
US8621101B1 (en) | 2000-09-29 | 2013-12-31 | Alacritech, Inc. | Intelligent network storage interface device |
US7042898B2 (en) | 1997-10-14 | 2006-05-09 | Alacritech, Inc. | Reducing delays associated with inserting a checksum into a network message |
US7237036B2 (en) * | 1997-10-14 | 2007-06-26 | Alacritech, Inc. | Fast-path apparatus for receiving data corresponding a TCP connection |
US6697868B2 (en) * | 2000-02-28 | 2004-02-24 | Alacritech, Inc. | Protocol processing stack for use with intelligent network interface device |
US7133940B2 (en) * | 1997-10-14 | 2006-11-07 | Alacritech, Inc. | Network interface device employing a DMA command queue |
US7089326B2 (en) * | 1997-10-14 | 2006-08-08 | Alacritech, Inc. | Fast-path processing for receiving data on TCP connection offload devices |
US8782199B2 (en) | 1997-10-14 | 2014-07-15 | A-Tech Llc | Parsing a packet header |
US6807581B1 (en) | 2000-09-29 | 2004-10-19 | Alacritech, Inc. | Intelligent network storage interface system |
US6757746B2 (en) | 1997-10-14 | 2004-06-29 | Alacritech, Inc. | Obtaining a destination address so that a network interface device can write network data without headers directly into host memory |
US6591302B2 (en) | 1997-10-14 | 2003-07-08 | Alacritech, Inc. | Fast-path apparatus for receiving data corresponding to a TCP connection |
US6427173B1 (en) | 1997-10-14 | 2002-07-30 | Alacritech, Inc. | Intelligent network interfaced device and system for accelerated communication |
US7284070B2 (en) * | 1997-10-14 | 2007-10-16 | Alacritech, Inc. | TCP offload network interface device |
US8539112B2 (en) | 1997-10-14 | 2013-09-17 | Alacritech, Inc. | TCP/IP offload device |
US6434620B1 (en) | 1998-08-27 | 2002-08-13 | Alacritech, Inc. | TCP/IP offload network interface device |
US7185266B2 (en) * | 2003-02-12 | 2007-02-27 | Alacritech, Inc. | Network interface device for error detection using partial CRCS of variable length message portions |
US6427171B1 (en) | 1997-10-14 | 2002-07-30 | Alacritech, Inc. | Protocol processing stack for use with intelligent network interface device |
US6687758B2 (en) * | 2001-03-07 | 2004-02-03 | Alacritech, Inc. | Port aggregation for network connections that are offloaded to network interface devices |
US7167927B2 (en) | 1997-10-14 | 2007-01-23 | Alacritech, Inc. | TCP/IP offload device with fast-path TCP ACK generating and transmitting mechanism |
US6658480B2 (en) * | 1997-10-14 | 2003-12-02 | Alacritech, Inc. | Intelligent network interface system and method for accelerated protocol processing |
US7174393B2 (en) | 2000-12-26 | 2007-02-06 | Alacritech, Inc. | TCP/IP offload network interface device |
US7076568B2 (en) * | 1997-10-14 | 2006-07-11 | Alacritech, Inc. | Data communication apparatus for computer intelligent network interface card which transfers data between a network and a storage device according designated uniform datagram protocol socket |
US6470415B1 (en) | 1999-10-13 | 2002-10-22 | Alacritech, Inc. | Queue system involving SRAM head, SRAM tail and DRAM body |
GB2330923A (en) * | 1997-10-28 | 1999-05-05 | Ibm | Transaction manager |
US6359892B1 (en) * | 1997-11-04 | 2002-03-19 | Inventions, Inc. | Remote access, emulation, and control of office equipment, devices and services |
US6003025A (en) * | 1997-11-24 | 1999-12-14 | International Business Machines Corporation | Data transformer system for accessing database information |
JP3581779B2 (en) * | 1997-11-28 | 2004-10-27 | 株式会社日立製作所 | Multi-server workflow system |
US6088679A (en) * | 1997-12-01 | 2000-07-11 | The United States Of America As Represented By The Secretary Of Commerce | Workflow management employing role-based access control |
US6205482B1 (en) | 1998-02-19 | 2001-03-20 | Ameritech Corporation | System and method for executing a request from a client application |
US6862732B1 (en) | 1998-02-25 | 2005-03-01 | Metaserver, Inc. | Method and apparatus for event-driven processing of data |
US6233586B1 (en) | 1998-04-01 | 2001-05-15 | International Business Machines Corp. | Federated searching of heterogeneous datastores using a federated query object |
US6263342B1 (en) | 1998-04-01 | 2001-07-17 | International Business Machines Corp. | Federated searching of heterogeneous datastores using a federated datastore object |
US6272488B1 (en) | 1998-04-01 | 2001-08-07 | International Business Machines Corporation | Managing results of federated searches across heterogeneous datastores with a federated collection object |
US6430538B1 (en) * | 1998-04-30 | 2002-08-06 | Enterworks | Workflow management system, method and medium with personal subflows |
US6567783B1 (en) | 1998-06-05 | 2003-05-20 | I2 Technologies Us, Inc. | Communication across one or more enterprise boundaries regarding the occurrence of a workflow event |
US6728947B1 (en) | 1998-06-05 | 2004-04-27 | R. R. Donnelley & Sons Company | Workflow distributing apparatus and method |
US6397192B1 (en) * | 1998-06-05 | 2002-05-28 | I2 Technologies Us, Inc. | Synchronizing one or more workflows using one or more synchronization-join activities that include synchronization logic |
US7039597B1 (en) | 1998-06-05 | 2006-05-02 | I2 Technologies Us, Inc. | Method and system for managing collaboration within and between enterprises |
US6442528B1 (en) | 1998-06-05 | 2002-08-27 | I2 Technologies Us, Inc. | Exemplar workflow used in the design and deployment of a workflow for multi-enterprise collaboration |
US7664883B2 (en) * | 1998-08-28 | 2010-02-16 | Alacritech, Inc. | Network interface device that fast-path processes solicited session layer read commands |
US6356863B1 (en) * | 1998-09-08 | 2002-03-12 | Metaphorics Llc | Virtual network file server |
ES2200753T3 (en) | 1998-10-28 | 2004-03-16 | Verticalone Corporation | APPARATUS AND METHOD FOR AGGREGATION AND AUTOMATED SUPPLY OF TRANSACTIONS THAT INVOLVE INFORMATION OR PERSONAL ELECTRONIC DATA. |
US6668284B1 (en) * | 1998-11-04 | 2003-12-23 | Beckman Coulter, Inc. | Software messaging system |
US7085997B1 (en) | 1998-12-08 | 2006-08-01 | Yodlee.Com | Network-based bookmark management and web-summary system |
US8069407B1 (en) | 1998-12-08 | 2011-11-29 | Yodlee.Com, Inc. | Method and apparatus for detecting changes in websites and reporting results to web developers for navigation template repair purposes |
US7200804B1 (en) * | 1998-12-08 | 2007-04-03 | Yodlee.Com, Inc. | Method and apparatus for providing automation to an internet navigation application |
US7672879B1 (en) | 1998-12-08 | 2010-03-02 | Yodlee.Com, Inc. | Interactive activity interface for managing personal data and performing transactions over a data packet network |
US7117172B1 (en) | 1999-03-11 | 2006-10-03 | Corecard Software, Inc. | Methods and systems for managing financial accounts |
US6243737B1 (en) * | 1999-04-09 | 2001-06-05 | Translink Software, Inc. | Method and apparatus for providing direct transaction access to information residing on a host system |
US6920475B1 (en) * | 1999-04-23 | 2005-07-19 | Oracle International Corporation | Communication architecture for distributed computing environment |
US7979382B2 (en) | 1999-05-04 | 2011-07-12 | Accenture Global Services Limited | Component based information linking during claim processing |
US7617240B2 (en) * | 1999-05-04 | 2009-11-10 | Accenture Llp | Component based task handling during claim processing |
US6493869B1 (en) * | 1999-05-28 | 2002-12-10 | Microsoft Corporation | Inheriting code in a transformational programming system |
US6665866B1 (en) | 1999-05-28 | 2003-12-16 | Microsoft Corporation | Extensible compiler utilizing a plurality of question handlers |
US7752535B2 (en) | 1999-06-01 | 2010-07-06 | Yodlec.com, Inc. | Categorization of summarized information |
US6477565B1 (en) * | 1999-06-01 | 2002-11-05 | Yodlee.Com, Inc. | Method and apparatus for restructuring of personalized data for transmission from a data network to connected and portable network appliances |
US6792605B1 (en) * | 1999-06-10 | 2004-09-14 | Bow Street Software, Inc. | Method and apparatus for providing web based services using an XML Runtime model to store state session data |
US6889260B1 (en) | 1999-06-10 | 2005-05-03 | Ec Enabler, Ltd | Method and system for transferring information |
US6609248B1 (en) * | 1999-06-30 | 2003-08-19 | Microsoft Corporation | Cross module representation of heterogeneous programs |
US6460178B1 (en) * | 1999-06-30 | 2002-10-01 | Microsoft Corporation | Shared library optimization for heterogeneous programs |
US7013465B1 (en) * | 1999-08-17 | 2006-03-14 | Emc Corporation | System, device and method for interprocessor communication in a computer system |
US6493635B1 (en) * | 1999-11-01 | 2002-12-10 | 3Dgeo Development, Inc. | Remote access and automated dialog building for seismic processing |
US7076788B1 (en) * | 1999-11-01 | 2006-07-11 | Nokia Networks Oy | Method for describing software architecture |
US6876991B1 (en) | 1999-11-08 | 2005-04-05 | Collaborative Decision Platforms, Llc. | System, method and computer program product for a collaborative decision platform |
AU2001247984A1 (en) * | 2000-02-16 | 2001-08-27 | Bea Systems Inc. | Workflow integration system for enterprise wide electronic collaboration |
CA2299150A1 (en) * | 2000-02-23 | 2001-08-23 | Hummingbird Communications Ltd | A system and method for providing real-time information to a web browser |
US20020007422A1 (en) * | 2000-07-06 | 2002-01-17 | Bennett Keith E. | Providing equipment access to supply chain members |
US7559066B2 (en) * | 2000-08-08 | 2009-07-07 | International Business Machines Corporation | CICS BMS (basic message service) meta model |
EP1308016A2 (en) * | 2000-08-11 | 2003-05-07 | Manugistics, Inc. | System and method for integrating disparate networks for use in electronic communication and commerce |
US8019901B2 (en) * | 2000-09-29 | 2011-09-13 | Alacritech, Inc. | Intelligent network storage interface system |
US6720074B2 (en) * | 2000-10-26 | 2004-04-13 | Inframat Corporation | Insulator coated magnetic nanoparticulate composites with reduced core loss and method of manufacture thereof |
US20020078117A1 (en) * | 2000-12-19 | 2002-06-20 | Wang Baldonado Michelle Q. | System for creating efficient multi-step document conversion services |
JP2002189841A (en) * | 2000-12-20 | 2002-07-05 | Hitachi Ltd | Workflow management method and system, and recording medium storing its processing program |
EP1347390A4 (en) * | 2000-12-28 | 2009-04-08 | Future System Consulting Corp | Framework system |
US7657590B2 (en) * | 2001-02-07 | 2010-02-02 | Ubs Ag | Load balancing system and method |
US7240324B2 (en) * | 2001-02-28 | 2007-07-03 | Hewlett-Packard Development Company, L.P. | Event-based scheduling method and system for workflow activities |
US7184967B1 (en) * | 2001-03-06 | 2007-02-27 | Microsoft Corporation | System and method utilizing a graphical user interface of a business process workflow scheduling program |
US6910204B1 (en) * | 2001-04-13 | 2005-06-21 | Unisys Corporation | Software development methodology including creation of focus areas and decomposition of same to create use cases |
US6971001B1 (en) * | 2001-05-17 | 2005-11-29 | Accenture Global Services Gmbh | General and reusable components for defining net-centric application program architectures |
GB2376094A (en) * | 2001-05-30 | 2002-12-04 | Ibm | Flexible navigation of a workflow graph in a data processing system |
US7069536B2 (en) * | 2001-06-28 | 2006-06-27 | International Business Machines Corporation | Method, system, and program for executing a workflow |
US7100147B2 (en) * | 2001-06-28 | 2006-08-29 | International Business Machines Corporation | Method, system, and program for generating a workflow |
US7043714B2 (en) * | 2001-06-28 | 2006-05-09 | International Business Machines Corporation | Method, system, and program for using objects in data stores during execution of a workflow |
US20030018508A1 (en) * | 2001-07-19 | 2003-01-23 | Schwanke Robert W. | Data-triggered workflow processes |
US7613716B2 (en) * | 2001-07-20 | 2009-11-03 | The Mathworks, Inc. | Partitioning for model-based design |
US6920456B2 (en) | 2001-07-30 | 2005-07-19 | International Business Machines Corporation | Method, system, and program for maintaining information in database tables and performing operations on data in the database tables |
US7047535B2 (en) * | 2001-07-30 | 2006-05-16 | International Business Machines Corporation | Method, system, and program for performing workflow related operations using an application programming interface |
US7296056B2 (en) * | 2001-07-30 | 2007-11-13 | International Business Machines Corporation | Method, system, and program for selecting one user to assign a work item in a workflow |
US7228547B2 (en) * | 2001-07-30 | 2007-06-05 | International Business Machines Corporation | Method, system, and program for enabling access to a plurality of services |
US7698427B2 (en) | 2001-07-30 | 2010-04-13 | International Business Machines Corporation | Method, system, and program for transferring data from an application engine |
US20030097457A1 (en) * | 2001-08-08 | 2003-05-22 | Amitabh Saran | Scalable multiprocessor architecture for business computer platforms |
US7080066B1 (en) | 2001-08-09 | 2006-07-18 | Ncr Corporation | Systems and methods for refining a decision-making process via executable sequences |
US7174342B1 (en) * | 2001-08-09 | 2007-02-06 | Ncr Corp. | Systems and methods for defining executable sequences to process information from a data collection |
GB2378781B (en) * | 2001-08-16 | 2005-06-01 | Sun Microsystems Inc | Message brokering |
US8112529B2 (en) * | 2001-08-20 | 2012-02-07 | Masterobjects, Inc. | System and method for asynchronous client server session communication |
US7752326B2 (en) * | 2001-08-20 | 2010-07-06 | Masterobjects, Inc. | System and method for utilizing asynchronous client server communication objects |
US6928640B2 (en) * | 2001-08-23 | 2005-08-09 | Qbt Systems, Inc. | System and method for building source code for connecting to systems |
US7069331B2 (en) * | 2001-09-13 | 2006-06-27 | Utstarcom, Inc. | Trunk group implementation in networks |
US7127507B1 (en) * | 2001-09-27 | 2006-10-24 | Sprint Communications Company L.P. | Method and apparatus for network-level monitoring of queue-based messaging systems |
US8914807B2 (en) * | 2001-09-28 | 2014-12-16 | International Business Machines Corporation | Method, system, and program for generating a program capable of invoking a flow of operations |
US8924408B2 (en) * | 2001-09-28 | 2014-12-30 | International Business Machines Corporation | Automatic generation of database invocation mechanism for external web services |
US8166006B2 (en) * | 2001-09-28 | 2012-04-24 | International Business Machines Corporation | Invocation of web services from a database |
US20030121835A1 (en) * | 2001-12-31 | 2003-07-03 | Peter Quartararo | Apparatus for and method of sieving biocompatible adsorbent beaded polymers |
US20030126109A1 (en) * | 2002-01-02 | 2003-07-03 | Tanya Couch | Method and system for converting message data into relational table format |
US7028311B2 (en) * | 2002-01-04 | 2006-04-11 | Telefonaktiebolaget Lm Ericsson (Publ) | Communications node architecture and method for providing control functions in a telecommunications network |
US7698230B1 (en) | 2002-02-15 | 2010-04-13 | ContractPal, Inc. | Transaction architecture utilizing transaction policy statements |
US7496689B2 (en) * | 2002-04-22 | 2009-02-24 | Alacritech, Inc. | TCP/IP offload device |
US7543087B2 (en) * | 2002-04-22 | 2009-06-02 | Alacritech, Inc. | Freeing transmit memory on a network interface device prior to receiving an acknowledgement that transmit data has been received by a remote device |
US7257818B2 (en) * | 2002-08-29 | 2007-08-14 | Sap Aktiengesellschaft | Rapid application integration using functional atoms |
US7269665B2 (en) * | 2002-08-29 | 2007-09-11 | Sap Ag | Isolated mapping point |
US7213227B2 (en) * | 2002-08-29 | 2007-05-01 | Sap Aktiengesellschaft | Rapid application integration using an integrated development environment |
US7237225B2 (en) * | 2002-08-29 | 2007-06-26 | Sap Aktiengesellschaft | Rapid application integration using reusable patterns |
WO2004021186A2 (en) * | 2002-08-29 | 2004-03-11 | Sap Aktiengesellschaft | Rapid application integration |
US7225425B2 (en) * | 2002-08-29 | 2007-05-29 | Sap Aktiengesellschaft | Rapid application integration |
US7277940B2 (en) * | 2002-08-29 | 2007-10-02 | Sap Ag | Managing uneven authorizations in a computer data exchange |
US8020148B2 (en) * | 2002-09-23 | 2011-09-13 | Telefonaktiebolaget L M Ericsson (Publ) | Bi-directional probing and testing of software |
US7191241B2 (en) * | 2002-09-27 | 2007-03-13 | Alacritech, Inc. | Fast-path apparatus for receiving data corresponding to a TCP connection |
US7337241B2 (en) * | 2002-09-27 | 2008-02-26 | Alacritech, Inc. | Fast-path apparatus for receiving data corresponding to a TCP connection |
CA2406569C (en) * | 2002-10-04 | 2011-03-22 | Ibm Canada Limited-Ibm Canada Limitee | Method and apparatus for enabling associated portlets of a web portal to collaborate for synchronized content display |
CA2406713C (en) * | 2002-10-04 | 2009-06-30 | Ibm Canada Limited-Ibm Canada Limitee | Method and apparatus for relaying session information from a portal server |
CA2406565A1 (en) * | 2002-10-04 | 2004-04-04 | Ibm Canada Limited-Ibm Canada Limitee | Method and apparatus for using business rules or user roles for selecting portlets in a web portal |
NZ521983A (en) * | 2002-10-14 | 2005-05-27 | Maximum Availability Ltd | Journaling changes to system objects such as programs in the IBM OS/400 operating system |
US20040088262A1 (en) * | 2002-11-06 | 2004-05-06 | Alacritech, Inc. | Enabling an enhanced function of an electronic device |
US20040148299A1 (en) * | 2002-11-25 | 2004-07-29 | Microsoft Corporation | Automated workflow composable action model |
US20040103014A1 (en) * | 2002-11-25 | 2004-05-27 | Teegan Hugh A. | System and method for composing and constraining automated workflow |
US20040148213A1 (en) * | 2002-11-25 | 2004-07-29 | Microsoft Corporation | Automated workflow constraints |
US7272820B2 (en) * | 2002-12-12 | 2007-09-18 | Extrapoles Pty Limited | Graphical development of fully executable transactional workflow applications with adaptive high-performance capacity |
US7634737B2 (en) * | 2002-12-23 | 2009-12-15 | Sap Ag | Defining a resource template for locating relevant resources |
US7711694B2 (en) * | 2002-12-23 | 2010-05-04 | Sap Ag | System and methods for user-customizable enterprise workflow management |
US8195631B2 (en) * | 2002-12-23 | 2012-06-05 | Sap Ag | Resource finder tool |
US7849175B2 (en) * | 2002-12-23 | 2010-12-07 | Sap Ag | Control center pages |
US20040122693A1 (en) * | 2002-12-23 | 2004-06-24 | Michael Hatscher | Community builder |
WO2004079930A2 (en) * | 2003-03-05 | 2004-09-16 | Messagesoft, Inc. | Asynchronous mechanism and message pool |
GB0306746D0 (en) * | 2003-03-24 | 2003-04-30 | Medic To Medic Ltd | A graphical user interface |
US8126742B2 (en) | 2003-05-09 | 2012-02-28 | Accenture Global Services Limited | Automated assignment of insurable events |
JP4175190B2 (en) * | 2003-06-19 | 2008-11-05 | 株式会社日立製作所 | Business service management system and service provider evaluation method |
US7385937B2 (en) * | 2003-07-23 | 2008-06-10 | International Business Machines Corporation | Method and system for determining a path between two points of an IP network over which datagrams are transmitted |
US20050050057A1 (en) * | 2003-08-25 | 2005-03-03 | Microsoft Corporation | System and method for integrating management of resources between application services and applications |
US20050071243A1 (en) * | 2003-09-30 | 2005-03-31 | Anandhi Somasekaran | Non-disruptive business process debugging and analysis |
US20050080759A1 (en) * | 2003-10-08 | 2005-04-14 | International Business Machines Corporation | Transparent interface to a messaging system from a database engine |
US7546320B2 (en) * | 2003-10-09 | 2009-06-09 | International Business Machines Corporation | Computer implemented method, system and program product for reviewing a message associated with computer program code |
US20070011334A1 (en) * | 2003-11-03 | 2007-01-11 | Steven Higgins | Methods and apparatuses to provide composite applications |
US20050108272A1 (en) * | 2003-11-13 | 2005-05-19 | Christian Behrens | Intermediate software layer |
US6996070B2 (en) * | 2003-12-05 | 2006-02-07 | Alacritech, Inc. | TCP/IP offload device with reduced sequential processing |
US20070074180A1 (en) * | 2003-12-22 | 2007-03-29 | Nasa Hq's | Systems, Methods and Apparatus for Procedure Development and Verification |
US7799273B2 (en) | 2004-05-06 | 2010-09-21 | Smp Logic Systems Llc | Manufacturing execution system for validation, quality and risk assessment and monitoring of pharmaceutical manufacturing processes |
US7444197B2 (en) | 2004-05-06 | 2008-10-28 | Smp Logic Systems Llc | Methods, systems, and software program for validation and monitoring of pharmaceutical manufacturing processes |
DE102004023634B4 (en) * | 2004-05-10 | 2007-09-27 | Siemens Ag | Method for checking the completeness and consistency of an information library |
US8650152B2 (en) * | 2004-05-28 | 2014-02-11 | International Business Machines Corporation | Method and system for managing execution of data driven workflows |
US9552599B1 (en) | 2004-09-10 | 2017-01-24 | Deem, Inc. | Platform for multi-service procurement |
WO2006029637A1 (en) * | 2004-09-13 | 2006-03-23 | Sita Information Networking Computing N.V. | Method for accomplishing a data communication, system and software product |
US7805324B2 (en) * | 2004-10-01 | 2010-09-28 | Microsoft Corporation | Unified model for authoring and executing flow-based and constraint-based workflows |
US20060074735A1 (en) * | 2004-10-01 | 2006-04-06 | Microsoft Corporation | Ink-enabled workflow authoring |
US7565640B2 (en) * | 2004-10-01 | 2009-07-21 | Microsoft Corporation | Framework for seamlessly authoring and editing workflows at design and runtime |
US7464366B2 (en) * | 2004-10-01 | 2008-12-09 | Microsoft Corporation | Programming interface for a componentized and extensible workflow model |
US7451432B2 (en) * | 2004-10-01 | 2008-11-11 | Microsoft Corporation | Transformation of componentized and extensible workflow to a declarative format |
US20060074704A1 (en) * | 2004-10-01 | 2006-04-06 | Microsoft Corporation | Framework to model cross-cutting behavioral concerns in the workflow domain |
US7631291B2 (en) * | 2004-10-01 | 2009-12-08 | Microsoft Corporation | Declarative representation for an extensible workflow model |
US8170901B2 (en) * | 2004-10-01 | 2012-05-01 | Microsoft Corporation | Extensible framework for designing workflows |
US8248939B1 (en) | 2004-10-08 | 2012-08-21 | Alacritech, Inc. | Transferring control of TCP connections between hierarchy of processing mechanisms |
US7457793B2 (en) * | 2004-10-14 | 2008-11-25 | Sap Ag | Investigating execution of a customized transaction process in a computer application |
US7761396B2 (en) * | 2004-10-14 | 2010-07-20 | Sap Ag | Apparatus and product of manufacture for adaptive business transaction rule structures |
US7756808B2 (en) * | 2004-10-14 | 2010-07-13 | Sap Ag | Apparatus and product of manufacture for using condition data structures separately from rule data structures in business transactions |
US7457792B2 (en) * | 2004-10-14 | 2008-11-25 | Sap Ag | Customizing transaction processing in a computer application by using pre-defined functions |
US7457794B2 (en) * | 2004-10-14 | 2008-11-25 | Sap Ag | Searching for customized processing rules for a computer application |
US7756809B2 (en) * | 2004-10-14 | 2010-07-13 | Sap Ag | Apparatus and product of manufacture using execution points to select conditions and rules for business transaction processing |
US7925540B1 (en) | 2004-10-15 | 2011-04-12 | Rearden Commerce, Inc. | Method and system for an automated trip planner |
US7962381B2 (en) * | 2004-10-15 | 2011-06-14 | Rearden Commerce, Inc. | Service designer solution |
US20060085374A1 (en) * | 2004-10-15 | 2006-04-20 | Filenet Corporation | Automatic records management based on business process management |
US20060085245A1 (en) * | 2004-10-19 | 2006-04-20 | Filenet Corporation | Team collaboration system with business process management and records management |
US8214461B1 (en) | 2004-11-23 | 2012-07-03 | Hewlett-Packard Development Company, L.P. | Method of processing request by server computer system |
US7644410B1 (en) | 2004-11-23 | 2010-01-05 | Hewlett-Packard Development Company, L.P. | Resource management for shared computing environment |
US7665093B2 (en) * | 2004-12-22 | 2010-02-16 | Microsoft Corporation | Synchronization of runtime and application state via batching of workflow transactions |
US8521570B2 (en) * | 2004-12-28 | 2013-08-27 | Sap Aktiengesellschaft | Integration of distributed business process models |
US20060195817A1 (en) * | 2005-02-28 | 2006-08-31 | Microsoft Corporation | Visual workflow modeling tools for user interface automation |
US20060229888A1 (en) * | 2005-03-31 | 2006-10-12 | Renzo Colle | Defining transaction processing for a computer application |
US7600214B2 (en) | 2005-04-18 | 2009-10-06 | Broadcom Corporation | Use of metadata for seamless updates |
EP1715653B1 (en) * | 2005-04-19 | 2008-07-30 | Sap Ag | A system and method for mediating within a network |
US20060242640A1 (en) * | 2005-04-22 | 2006-10-26 | Heinz Pauly | System and method for business software integration |
US7627544B2 (en) * | 2005-05-20 | 2009-12-01 | Microsoft Corporation | Recognizing event patterns from event streams |
US7461091B2 (en) * | 2005-06-09 | 2008-12-02 | Sap Aktiengesellschaft | Controlling data transition between business processes in a computer application |
US20060288332A1 (en) * | 2005-06-21 | 2006-12-21 | Microsoft Corporation | Workflow debugger |
US7363628B2 (en) * | 2005-06-27 | 2008-04-22 | Microsoft Corporation | Data centric and protocol agnostic workflows for exchanging data between a workflow instance and a workflow host |
US7742954B1 (en) | 2005-07-07 | 2010-06-22 | Rearden Commerce, Inc. | Method and system for an enhanced portal for services suppliers |
US7281118B2 (en) * | 2005-08-05 | 2007-10-09 | International Business Machines Corporation | Sending thread message generated using DCR command pointed message control block storing message and response memory address in multiprocessor |
US20070088736A1 (en) * | 2005-10-19 | 2007-04-19 | Filenet Corporation | Record authentication and approval transcript |
US10402756B2 (en) * | 2005-10-19 | 2019-09-03 | International Business Machines Corporation | Capturing the result of an approval process/workflow and declaring it a record |
US7933786B2 (en) | 2005-11-01 | 2011-04-26 | Accenture Global Services Limited | Collaborative intelligent task processor for insurance claims |
US20070112781A1 (en) * | 2005-11-17 | 2007-05-17 | Mcmullen Cindy | System and method for providing search controls in a communities framework |
US8046696B2 (en) * | 2005-11-17 | 2011-10-25 | Oracle International Corporation | System and method for providing active menus in a communities framework |
US8185643B2 (en) * | 2005-11-17 | 2012-05-22 | Oracle International Corporation | System and method for providing security in a communities framework |
US20070112913A1 (en) * | 2005-11-17 | 2007-05-17 | Bales Christopher E | System and method for displaying HTML content from portlet as a page element in a communites framework |
US20070112799A1 (en) * | 2005-11-17 | 2007-05-17 | Bales Christopher E | System and method for providing resource interlinking for a communities framework |
US20070112856A1 (en) * | 2005-11-17 | 2007-05-17 | Aaron Schram | System and method for providing analytics for a communities framework |
US7590687B2 (en) * | 2005-11-17 | 2009-09-15 | Bea Systems, Inc. | System and method for providing notifications in a communities framework |
US8078597B2 (en) * | 2005-11-17 | 2011-12-13 | Oracle International Corporation | System and method for providing extensible controls in a communities framework |
US7805459B2 (en) * | 2005-11-17 | 2010-09-28 | Bea Systems, Inc. | Extensible controls for a content data repository |
US7680927B2 (en) * | 2005-11-17 | 2010-03-16 | Bea Systems, Inc. | System and method for providing testing for a communities framework |
US7493329B2 (en) * | 2005-11-17 | 2009-02-17 | Bea Systems, Inc. | System and method for providing generic controls in a communities framework |
US20070112798A1 (en) * | 2005-11-17 | 2007-05-17 | Bea Systems, Inc. | System and method for providing unique key stores for a communities framework |
US8255818B2 (en) * | 2005-11-17 | 2012-08-28 | Oracle International Corporation | System and method for providing drag and drop functionality in a communities framework |
US7738500B1 (en) | 2005-12-14 | 2010-06-15 | Alacritech, Inc. | TCP timestamp synchronization for network connections that are offloaded to network interface devices |
US7856436B2 (en) * | 2005-12-23 | 2010-12-21 | International Business Machines Corporation | Dynamic holds of record dispositions during record management |
US20070150349A1 (en) * | 2005-12-28 | 2007-06-28 | Rearden Commerce, Inc. | Method and system for culling star performers, trendsetters and connectors from a pool of users |
US9117223B1 (en) | 2005-12-28 | 2015-08-25 | Deem, Inc. | Method and system for resource planning for service provider |
US7680683B2 (en) * | 2005-12-29 | 2010-03-16 | Microsoft Corporation | Dynamically repositioning workflow by end users |
US20070156486A1 (en) * | 2005-12-29 | 2007-07-05 | Microsoft Corporation | Multiple concurrent workflow persistence schemes |
US8849691B2 (en) * | 2005-12-29 | 2014-09-30 | Microsoft Corporation | Modeling user input and interaction in workflow based applications |
US20070156487A1 (en) * | 2005-12-29 | 2007-07-05 | Microsoft Corporation | Object model on workflow |
US8370794B2 (en) * | 2005-12-30 | 2013-02-05 | Sap Ag | Software model process component |
US8321831B2 (en) | 2005-12-30 | 2012-11-27 | Sap Ag | Architectural design for internal projects application software |
US8402426B2 (en) * | 2005-12-30 | 2013-03-19 | Sap Ag | Architectural design for make to stock application software |
US8448137B2 (en) * | 2005-12-30 | 2013-05-21 | Sap Ag | Software model integration scenarios |
US8660904B2 (en) * | 2005-12-30 | 2014-02-25 | Sap Ag | Architectural design for service request and order management application software |
US8522194B2 (en) | 2005-12-30 | 2013-08-27 | Sap Ag | Software modeling |
US20070156500A1 (en) * | 2005-12-30 | 2007-07-05 | Wilfried Merkel | Architectural design for sell from stock application software |
US20070156550A1 (en) * | 2005-12-30 | 2007-07-05 | Der Emde Martin V | Architectural design for cash and liquidity management application software |
US8327319B2 (en) * | 2005-12-30 | 2012-12-04 | Sap Ag | Software model process interaction |
US8380553B2 (en) | 2005-12-30 | 2013-02-19 | Sap Ag | Architectural design for plan-driven procurement application software |
US8326703B2 (en) | 2005-12-30 | 2012-12-04 | Sap Ag | Architectural design for product catalog management application software |
US8407664B2 (en) | 2005-12-30 | 2013-03-26 | Sap Ag | Software model business objects |
US8396731B2 (en) | 2005-12-30 | 2013-03-12 | Sap Ag | Architectural design for service procurement application software |
US8316344B2 (en) | 2005-12-30 | 2012-11-20 | Sap Ag | Software model deployment units |
US8676617B2 (en) * | 2005-12-30 | 2014-03-18 | Sap Ag | Architectural design for self-service procurement application software |
US8868660B2 (en) * | 2006-03-22 | 2014-10-21 | Cellco Partnership | Electronic communication work flow manager system, method and computer program product |
US8396749B2 (en) * | 2006-03-30 | 2013-03-12 | Sap Ag | Providing customer relationship management application as enterprise services |
US7739135B2 (en) * | 2006-03-30 | 2010-06-15 | Microsoft Corporation | Asynchronous fault handling in process-centric programs |
US8442850B2 (en) * | 2006-03-30 | 2013-05-14 | Sap Ag | Providing accounting software application as enterprise services |
US8024405B2 (en) * | 2006-03-30 | 2011-09-20 | Microsoft Corporation | Declarative model for concurrency-control across lightweight threads |
US8326702B2 (en) * | 2006-03-30 | 2012-12-04 | Sap Ag | Providing supplier relationship management software application as enterprise services |
US8396761B2 (en) * | 2006-03-30 | 2013-03-12 | Sap Ag | Providing product catalog software application as enterprise services |
US8538864B2 (en) * | 2006-03-30 | 2013-09-17 | Sap Ag | Providing payment software application as enterprise services |
US8069439B2 (en) * | 2006-03-30 | 2011-11-29 | Microsoft Corporation | Framework for modeling continuations in workflows |
US20070239498A1 (en) * | 2006-03-30 | 2007-10-11 | Microsoft Corporation | Framework for modeling cancellation for process-centric programs |
US8438119B2 (en) | 2006-03-30 | 2013-05-07 | Sap Ag | Foundation layer for services based enterprise software architecture |
US20070239505A1 (en) * | 2006-03-30 | 2007-10-11 | Microsoft Corporation | Abstract execution model for a continuation-based meta-runtime |
US8321832B2 (en) | 2006-03-31 | 2012-11-27 | Sap Ag | Composite application modeling |
US7945891B2 (en) * | 2006-04-12 | 2011-05-17 | Microsoft Corporation | Time business process validations within data context |
US8312416B2 (en) * | 2006-04-13 | 2012-11-13 | Sap Ag | Software model business process variant types |
US7877757B2 (en) * | 2006-05-05 | 2011-01-25 | Microsoft Corporation | Work item event monitor for procession of queued events |
US20070265895A1 (en) * | 2006-05-09 | 2007-11-15 | Sap Ag | Ad-hoc workflow as a business process template |
US8799181B2 (en) * | 2006-05-09 | 2014-08-05 | Sag Ag | Business process federated repository |
US20070265900A1 (en) * | 2006-05-09 | 2007-11-15 | Moore Dennis B | Business process evolution |
US7933925B2 (en) * | 2006-06-01 | 2011-04-26 | International Business Machines Corporation | System and method for role based analysis and access control |
US8073719B2 (en) * | 2006-06-30 | 2011-12-06 | Rearden Commerce, Inc. | System and method for core identity with personas across multiple domains with permissions on profile data based on rights of domain |
US20080004919A1 (en) * | 2006-06-30 | 2008-01-03 | Rearden Commerce, Inc. | Triggered transactions based on criteria |
US7941374B2 (en) * | 2006-06-30 | 2011-05-10 | Rearden Commerce, Inc. | System and method for changing a personal profile or context during a transaction |
US20080004980A1 (en) * | 2006-06-30 | 2008-01-03 | Rearden Commerce, Inc. | System and method for regulating supplier acceptance of service requests |
US8095402B2 (en) * | 2006-07-10 | 2012-01-10 | Rearden Commerce, Inc. | System and method for transferring a service policy between domains |
US7606752B2 (en) | 2006-09-07 | 2009-10-20 | Yodlee Inc. | Host exchange in bill paying services |
US20080086542A1 (en) * | 2006-10-04 | 2008-04-10 | Title Resource Group, Llc | System and method for communicating document information |
US8037029B2 (en) * | 2006-10-10 | 2011-10-11 | International Business Machines Corporation | Automated records management with hold notification and automatic receipts |
US8051475B2 (en) * | 2006-11-01 | 2011-11-01 | The United States Of America As Represented By The Secretary Of The Air Force | Collaboration gateway |
US8225300B1 (en) * | 2007-02-14 | 2012-07-17 | The Mathworks, Inc. | Client program executable on multiple heterogeneous server platforms |
US20080201432A1 (en) * | 2007-02-16 | 2008-08-21 | Rearden Commerce, Inc. | System and Method for Facilitating Transfer of Experience Data in to Generate a New Member Profile for a Online Service Portal |
US20090006143A1 (en) * | 2007-06-26 | 2009-01-01 | Rearden Commerce, Inc. | System and Method for Interactive Natural Language Rebooking or Rescheduling of Calendar Activities |
US8566780B2 (en) * | 2007-06-26 | 2013-10-22 | Microsoft Corporation | Object model based mapping |
US8695001B2 (en) * | 2007-09-20 | 2014-04-08 | Microsoft Corporation | Loading services based on a request and setting permission level to enable execution of commands or services exposed based on a role of requester |
US8131663B1 (en) | 2007-10-12 | 2012-03-06 | Bonamy Taylor | Apparatus for generating software logic rules by flowchart design |
US20090113042A1 (en) * | 2007-10-31 | 2009-04-30 | International Business Machines Corporaton | Method for correlating periodically aggregated data in distributed systems |
US20090171758A1 (en) * | 2007-12-31 | 2009-07-02 | Shai Alfandary | Architectural design for physical inventory application software |
US8671032B2 (en) | 2007-12-31 | 2014-03-11 | Sap Ag | Providing payment software application as enterprise services |
US8510143B2 (en) * | 2007-12-31 | 2013-08-13 | Sap Ag | Architectural design for ad-hoc goods movement software |
US8671034B2 (en) * | 2007-12-31 | 2014-03-11 | Sap Ag | Providing human capital management software application as enterprise services |
US8447657B2 (en) | 2007-12-31 | 2013-05-21 | Sap Ag | Architectural design for service procurement application software |
US8401936B2 (en) * | 2007-12-31 | 2013-03-19 | Sap Ag | Architectural design for expense reimbursement application software |
US8315900B2 (en) * | 2007-12-31 | 2012-11-20 | Sap Ag | Architectural design for self-service procurement application software |
US8671033B2 (en) | 2007-12-31 | 2014-03-11 | Sap Ag | Architectural design for personnel events application software |
US8478769B2 (en) | 2008-02-22 | 2013-07-02 | Accenture Global Services Limited | Conversational question generation system adapted for an insurance claim processing system |
US8515786B2 (en) | 2008-02-22 | 2013-08-20 | Accenture Global Services Gmbh | Rule generation system adapted for an insurance claim processing system |
US20090248457A1 (en) * | 2008-03-31 | 2009-10-01 | Rearden Commerce, Inc. | System and Method for Providing Travel Schedule of Contacts |
US8539513B1 (en) | 2008-04-01 | 2013-09-17 | Alacritech, Inc. | Accelerating data transfer in a virtual computer system with tightly coupled TCP connections |
US8261334B2 (en) | 2008-04-25 | 2012-09-04 | Yodlee Inc. | System for performing web authentication of a user by proxy |
CN101640667B (en) * | 2008-07-30 | 2012-11-21 | 国际商业机器公司 | Process execution method, process execution system and configuration equipment and configuration method of process execution system |
US8341286B1 (en) | 2008-07-31 | 2012-12-25 | Alacritech, Inc. | TCP offload send optimization |
US8321250B2 (en) * | 2008-09-18 | 2012-11-27 | Sap Ag | Architectural design for sell from stock application software |
US8326706B2 (en) * | 2008-09-18 | 2012-12-04 | Sap Ag | Providing logistics execution application as enterprise services |
US8595077B2 (en) | 2008-09-18 | 2013-11-26 | Sap Ag | Architectural design for service request and order management application software |
US8315926B2 (en) * | 2008-09-18 | 2012-11-20 | Sap Ag | Architectural design for tax declaration application software |
US8818884B2 (en) * | 2008-09-18 | 2014-08-26 | Sap Ag | Architectural design for customer returns handling application software |
US20100070395A1 (en) * | 2008-09-18 | 2010-03-18 | Andreas Elkeles | Architectural design for payroll processing application software |
US8386325B2 (en) | 2008-09-18 | 2013-02-26 | Sap Ag | Architectural design for plan-driven procurement application software |
US20100082497A1 (en) * | 2008-09-18 | 2010-04-01 | Sap Ag | Providing Foundation Application as Enterprise Services |
US20100070336A1 (en) * | 2008-09-18 | 2010-03-18 | Sap Ag | Providing Customer Relationship Management Application as Enterprise Services |
US8380549B2 (en) | 2008-09-18 | 2013-02-19 | Sap Ag | Architectural design for embedded support application software |
US8352338B2 (en) * | 2008-09-18 | 2013-01-08 | Sap Ag | Architectural design for time recording application software |
US8374896B2 (en) | 2008-09-18 | 2013-02-12 | Sap Ag | Architectural design for opportunity management application software |
US8401928B2 (en) | 2008-09-18 | 2013-03-19 | Sap Ag | Providing supplier relationship management software application as enterprise services |
US9306793B1 (en) | 2008-10-22 | 2016-04-05 | Alacritech, Inc. | TCP offload device that batches session layer headers to reduce interrupts as well as CPU copies |
US8738476B2 (en) | 2008-12-03 | 2014-05-27 | Sap Ag | Architectural design for selling standardized services application software |
US8321308B2 (en) * | 2008-12-03 | 2012-11-27 | Sap Ag | Architectural design for manual invoicing application software |
US8401908B2 (en) | 2008-12-03 | 2013-03-19 | Sap Ag | Architectural design for make-to-specification application software |
US8321306B2 (en) | 2008-12-03 | 2012-11-27 | Sap Ag | Architectural design for selling project-based services application software |
US8311904B2 (en) | 2008-12-03 | 2012-11-13 | Sap Ag | Architectural design for intra-company stock transfer application software |
US8671035B2 (en) * | 2008-12-11 | 2014-03-11 | Sap Ag | Providing payroll software application as enterprise services |
US9354847B2 (en) | 2008-12-29 | 2016-05-31 | Microsoft Technology Licensing, Llc | Interface infrastructure for a continuation based runtime |
US8656346B2 (en) * | 2009-02-18 | 2014-02-18 | Microsoft Corporation | Converting command units into workflow activities |
US8555359B2 (en) * | 2009-02-26 | 2013-10-08 | Yodlee, Inc. | System and methods for automatically accessing a web site on behalf of a client |
US10552849B2 (en) * | 2009-04-30 | 2020-02-04 | Deem, Inc. | System and method for offering, tracking and promoting loyalty rewards |
US20100324948A1 (en) * | 2009-06-18 | 2010-12-23 | Microsoft Corporation | Managing event timelines |
US9697481B2 (en) * | 2009-12-23 | 2017-07-04 | Siemens Aktiengesellschaft | Method for operating a hospital information system |
US9224119B2 (en) | 2010-02-02 | 2015-12-29 | International Business Machines Corporation | Architecting and defining extensible methods and processes to build hybrid solutions |
EP2593911A1 (en) * | 2010-07-12 | 2013-05-22 | Zendesk Inc. | Methods and apparatus for automated workflow management |
US8468545B2 (en) * | 2010-08-18 | 2013-06-18 | 8X8, Inc. | Interaction management |
CN102542337B (en) * | 2010-12-13 | 2014-04-02 | 金蝶软件(中国)有限公司 | Service logic processing method for information system and device |
US9536264B2 (en) | 2011-11-14 | 2017-01-03 | Microsoft Technology Licensing, Llc | Host agnostic messaging in a continuation based runtime |
US9152533B1 (en) | 2011-12-06 | 2015-10-06 | Amazon Technologies, Inc. | Asynchronous programming system |
US9170915B1 (en) * | 2011-12-06 | 2015-10-27 | Amazon Technologies, Inc. | Replay to reconstruct program state |
CN103186826A (en) * | 2011-12-30 | 2013-07-03 | 鼎捷软件股份有限公司 | Service processing method and service processing device |
US9269071B2 (en) * | 2012-04-05 | 2016-02-23 | Sap Se | Coordination of collaboration partners |
US8739124B2 (en) | 2012-06-27 | 2014-05-27 | Sap Ag | Configuring integration capabilities for system integration |
EP2872993A4 (en) * | 2012-07-16 | 2016-03-02 | Hewlett Packard Development Co | Workflow compilation |
US9519879B1 (en) | 2012-08-24 | 2016-12-13 | Tibco Software Inc. | Just in time compilation (JIT) for business process execution |
US20140245319A1 (en) * | 2013-02-27 | 2014-08-28 | Greenbutton Limited | Method for enabling an application to run on a cloud computing system |
US20140316844A1 (en) * | 2013-04-22 | 2014-10-23 | Nipendo Ltd. | Messaging engine |
US9674260B2 (en) | 2013-07-09 | 2017-06-06 | John Henry Page | System and method for exchanging and displaying resource viewing position and related information |
US9449346B1 (en) | 2014-05-21 | 2016-09-20 | Plaid Technologies, Inc. | System and method for programmatically accessing financial data |
US9595023B1 (en) | 2014-05-21 | 2017-03-14 | Plaid Technologies, Inc. | System and method for facilitating programmatic verification of transactions |
EP3347846B1 (en) | 2015-09-08 | 2021-12-22 | Plaid Inc. | Secure permissioning of access to user accounts, including secure deauthorization of access to user accounts |
US20170161855A1 (en) * | 2015-12-08 | 2017-06-08 | C2C Solutions, Inc. | Optimized small screen device to display visual elements in a real property dashboard involving predictive analytics |
US10726491B1 (en) | 2015-12-28 | 2020-07-28 | Plaid Inc. | Parameter-based computer evaluation of user accounts based on user account data stored in one or more databases |
US10984468B1 (en) | 2016-01-06 | 2021-04-20 | Plaid Inc. | Systems and methods for estimating past and prospective attribute values associated with a user account |
US10031745B2 (en) * | 2016-02-02 | 2018-07-24 | International Business Machines Corporation | System and method for automatic API candidate generation |
US10365909B2 (en) * | 2016-04-21 | 2019-07-30 | Data Accelerator Ltd. | Method and system for deploying virtualized applications |
US10878421B2 (en) | 2017-07-22 | 2020-12-29 | Plaid Inc. | Data verified deposits |
US11468085B2 (en) | 2017-07-22 | 2022-10-11 | Plaid Inc. | Browser-based aggregation |
US11316862B1 (en) | 2018-09-14 | 2022-04-26 | Plaid Inc. | Secure authorization of access to user accounts by one or more authorization mechanisms |
CN109726900A (en) * | 2018-12-14 | 2019-05-07 | 广东工业大学 | A kind of the manufacture execution Workflow system and implementation method of message-driven |
US11887069B2 (en) | 2020-05-05 | 2024-01-30 | Plaid Inc. | Secure updating of allocations to user accounts |
US11327960B1 (en) | 2020-10-16 | 2022-05-10 | Plaid Inc. | Systems and methods for data parsing |
US11888759B2 (en) | 2021-06-23 | 2024-01-30 | Bank Of America Corporation | System for executing digital resource transfer using trusted computing |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4819159A (en) * | 1986-08-29 | 1989-04-04 | Tolerant Systems, Inc. | Distributed multiprocess transaction processing system and method |
US5039980A (en) * | 1990-01-26 | 1991-08-13 | Honeywell Inc. | Multi-nodal communication network with coordinated responsibility for global functions by the nodes |
US5249293A (en) * | 1989-06-27 | 1993-09-28 | Digital Equipment Corporation | Computer network providing transparent operation on a compute server and associated method |
US5325527A (en) * | 1993-01-19 | 1994-06-28 | Canon Information Systems, Inc. | Client/server communication system utilizing a self-generating nodal network |
US5325530A (en) * | 1993-01-29 | 1994-06-28 | International Business Machines Corporation | Controller for sequential programming tools executed in a parallel computing environment |
US5341499A (en) * | 1992-04-02 | 1994-08-23 | International Business Machines Corporation | Method and apparatus for processing multiple file system server requests in a data processing network |
US5414845A (en) * | 1992-06-26 | 1995-05-09 | International Business Machines Corporation | Network-based computer system with improved network scheduling system |
Family Cites Families (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4503499A (en) * | 1982-09-14 | 1985-03-05 | Eaton Corporation | Controlled work flow system |
US4794386A (en) * | 1986-04-11 | 1988-12-27 | Profit Technology, Inc. | Data integrator for video display including windows |
US4763356A (en) * | 1986-12-11 | 1988-08-09 | AT&T Information Systems, Inc. American Telephone and Telegraph Company | Touch screen form entry system |
US5455903A (en) * | 1991-05-31 | 1995-10-03 | Edify Corp. | Object oriented customer information exchange system and method |
US5627764A (en) * | 1991-10-04 | 1997-05-06 | Banyan Systems, Inc. | Automatic electronic messaging system with feedback and work flow administration |
GB2263988B (en) * | 1992-02-04 | 1996-05-22 | Digital Equipment Corp | Work flow management system and method |
EP0554854A3 (en) * | 1992-02-04 | 1996-02-28 | Digital Equipment Corp | System and method for executing, tracking and recovering long running computations |
US5535322A (en) * | 1992-10-27 | 1996-07-09 | International Business Machines Corporation | Data processing system with improved work flow system and method |
US5630069A (en) * | 1993-01-15 | 1997-05-13 | Action Technologies, Inc. | Method and apparatus for creating workflow maps of business processes |
IL111154A0 (en) * | 1993-10-21 | 1994-12-29 | Martino Ii John A | Systems and methods for electronic messaging |
US5548506A (en) * | 1994-03-17 | 1996-08-20 | Srinivasan; Seshan R. | Automated, electronic network based, project management server system, for managing multiple work-groups |
US5721912A (en) * | 1994-08-05 | 1998-02-24 | Data Integration Solutions Corp. | Graphical user interface for creating database integration specifications |
US5588150A (en) * | 1994-09-29 | 1996-12-24 | International Business Machines Corporation | Push down optimization in a distributed, multi-database system |
AU3415595A (en) * | 1994-10-04 | 1996-04-26 | Banctec, Inc. | An object-oriented computer environment and related method |
US5745901A (en) * | 1994-11-08 | 1998-04-28 | Kodak Limited | Workflow initiated by graphical symbols |
US5634127A (en) * | 1994-11-30 | 1997-05-27 | International Business Machines Corporation | Methods and apparatus for implementing a message driven processor in a client-server environment |
US5774661A (en) * | 1995-04-18 | 1998-06-30 | Network Imaging Corporation | Rule engine interface for a visual workflow builder |
JPH09325939A (en) * | 1996-06-05 | 1997-12-16 | Hitachi Ltd | Groupware system provided with agent function |
-
1994
- 1994-11-30 US US08/350,166 patent/US5634127A/en not_active Expired - Lifetime
-
1995
- 1995-11-29 WO PCT/US1995/015432 patent/WO1996017296A1/en active Application Filing
- 1995-11-29 AU AU42890/96A patent/AU4289096A/en not_active Abandoned
-
1997
- 1997-01-16 US US08/834,353 patent/US6253369B1/en not_active Expired - Fee Related
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4819159A (en) * | 1986-08-29 | 1989-04-04 | Tolerant Systems, Inc. | Distributed multiprocess transaction processing system and method |
US5249293A (en) * | 1989-06-27 | 1993-09-28 | Digital Equipment Corporation | Computer network providing transparent operation on a compute server and associated method |
US5039980A (en) * | 1990-01-26 | 1991-08-13 | Honeywell Inc. | Multi-nodal communication network with coordinated responsibility for global functions by the nodes |
US5341499A (en) * | 1992-04-02 | 1994-08-23 | International Business Machines Corporation | Method and apparatus for processing multiple file system server requests in a data processing network |
US5414845A (en) * | 1992-06-26 | 1995-05-09 | International Business Machines Corporation | Network-based computer system with improved network scheduling system |
US5325527A (en) * | 1993-01-19 | 1994-06-28 | Canon Information Systems, Inc. | Client/server communication system utilizing a self-generating nodal network |
US5325530A (en) * | 1993-01-29 | 1994-06-28 | International Business Machines Corporation | Controller for sequential programming tools executed in a parallel computing environment |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1999063469A1 (en) * | 1998-06-05 | 1999-12-09 | I2 Technologies, Inc. | System and process for multi-enterprise collaboration |
US6119149A (en) * | 1998-06-05 | 2000-09-12 | I2 Technologies, Inc. | System and process allowing collaboration within and between enterprises for optimal decision making |
US6332155B1 (en) | 1998-06-05 | 2001-12-18 | I2 Technologies Us, Inc. | System and process allowing collaboration within and between enterprises for optimal decision making |
US6397191B1 (en) | 1998-06-05 | 2002-05-28 | I2 Technologies Us, Inc. | Object-oriented workflow for multi-enterprise collaboration |
GB2339622A (en) * | 1998-07-15 | 2000-02-02 | Ibm | Client/server computing with transactional interface between legacy and non-legacy systems |
US6237018B1 (en) | 1998-07-15 | 2001-05-22 | International Business Machines Corporation | Apparatus method and computer program product for client/server computing with improved transactional interface |
Also Published As
Publication number | Publication date |
---|---|
AU4289096A (en) | 1996-06-19 |
US6253369B1 (en) | 2001-06-26 |
US5634127A (en) | 1997-05-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US5634127A (en) | Methods and apparatus for implementing a message driven processor in a client-server environment | |
US6243862B1 (en) | Methods and apparatus for testing components of a distributed transaction processing system | |
US7912895B2 (en) | System and method for managing service interactions | |
US8260844B2 (en) | Information messaging and collaboration system | |
US5758351A (en) | System and method for the creation and use of surrogate information system objects | |
US7363628B2 (en) | Data centric and protocol agnostic workflows for exchanging data between a workflow instance and a workflow host | |
US7103627B2 (en) | Web-based system and method | |
US8122444B2 (en) | Legacy application decommissioning framework | |
US6260078B1 (en) | Using a distributed object system to find and download java-based applications | |
EP0547903B1 (en) | Method and system for isolating data and information collection components from other components in a distributed environment | |
US5845289A (en) | Methodology for generating object structures for accessing conventional, non-object-oriented business applications | |
US8656342B2 (en) | Composing integrated systems using GUI-based applications and web services | |
US20060224702A1 (en) | Local workflows in a business process management system | |
US20020035606A1 (en) | Method and system for straight through processing | |
US20050251533A1 (en) | Migrating data integration processes through use of externalized metadata representations | |
JPH04229357A (en) | Unifying system of applied business program in different kind of network environment | |
US9313267B2 (en) | Using a same program on a local system and a remote system | |
US20060129985A1 (en) | Development and execution platform | |
Sung et al. | A component-based product data management system | |
EP0831406A2 (en) | Implementing a workflow engine in a database management system | |
JP2994299B2 (en) | Request for program execution and notification of result | |
WO1997028500A1 (en) | Method and apparatus of developing a business application computer-program | |
Voss | APPC/MVS distributed application support | |
Smith | System support for design and development environments | |
Whittington et al. | Using ToolTalk to Implement a Distributed Discrete Simulation Environment |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A1 Designated state(s): AL AM AT AU BB BG BR BY CA CH CN CZ DE DK EE ES FI GB GE HU IS JP KE KG KP KR KZ LK LR LS LT LU LV MD MG MN MW MX NO NZ PL PT RO RU SD SE SG SI SK TJ TM TT UA UG UZ VN |
|
AL | Designated countries for regional patents |
Kind code of ref document: A1 Designated state(s): KE LS MW SD SZ UG AT BE CH DE DK ES FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN ML MR NE SN TD TG |
|
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
122 | Ep: pct application non-entry in european phase |