FR3047819A3 - APPARATUS FOR GENERATORS OF POINTS OF DYNAMIC END AND DISCOVERY AND BROKERAGE OF DYNAMIC REMOTE OBJECTS - Google Patents

Abstract

The present invention generally relates to dynamic endpoint generators, and more specifically to an apparatus for dynamic endpoint generators that automatically publish an endpoint for commercial objects so that remote client devices can easily discover and access commercial objects.

Description

APPARATUS FOR GENERATORS OF POINTS OF DYNAMIC EXTREMITY AND DISCOVERY AND BROKERAGE OF REMOTE OBJECTS

DYNAMIC

TECHNICAL AREA

The present application generally relates to dynamic endpoint generators, and more specifically to methods and apparatus for dynamic endpoint generators that automatically publish an endpoint for commercial objects so that devices remote customers can easily discover and access commercial objects.

CONTEXT

With the growth of the number of information sources in organizations, it is becoming increasingly difficult for information consumers to access information in a logical and structured way in relation to the traditional business objects usually found in organizations. organizations (for example, customers, assets, suppliers, staff, etc.) · Data from existing systems are usually made available in a very technical way that requires significant technical and development skills to organizational techniques can use them. Non-technical users must be able to add information within a logical business object definition without involving technical or development skills. Technical and non-technical users of data must be able to access their information from multiple data / information sources in a structured manner as business objects, while maintaining the flexibility to add additional information definitions to business objects or create new business objects from existing or new data sources without the need for complex solution development.

Existing enterprise application integration (EAI) systems combined with development tools can be used to develop custom solutions that make data and information more accessible, but these solutions are typically hardware-coded and require technical and development skills important for their updating and evolution over time. In addition, information users are limited by static business forms and the information presented to them by solution applications or the custom applications they use on a daily basis. In addition, existing process automation tools do not provide the necessary level of modeling tools and concepts to enable technical and non-technical users to create a complete business process solution in a single modeling tooling environment. /automating.

These issues can be solved by using enterprise application integration (EAI) sources (eg, EAI software, web services, application APIs) to provide a higher-level framework (eg for example, brokerage and runtime adaptation services) with associated solution components (for example, user interfaces and tools) that enable technical and non-technical users to create logical business objects that include definitions of data (for example, customer number, last name, etc.) and actions or methods (for example, save, load, delete) from existing or new data sources. Users can combine data from multiple sources into a single business object definition, including data and method / action definitions. The logical business object is an intelligent object that exposes a unique logical data structure and a business object view, as well as a unique set of logical methods associated with the business object. The business object is dynamic and its definition can be changed by adding or removing data or actions without the need to involve technical or development resources to reconfigure or recompile the actual business objects. However, once a dynamic business object is created, remote client devices can not easily access and consume it. Today's technologies require you to define an endpoint before you can consume the business object through existing Web services technologies. An endpoint is used to specify the interaction requirements between the client device and the business object. For example, the client device sends a message to the endpoint of the business object when it wants to use the business object, and the message is formatted according to the information specified by the endpoint. A business object may have multiple endpoints providing different ways for the customer to consume that business object. Typically, an endpoint is defined by an address, a link, and a contract. An address is the location where the endpoint is located. A binding specifies how a business object can be consumed, such as a protocol or encoding information. A contract for each object lists the operations exposed by the business object. All of this information must be specified before a remote client device can use a business object.

This approach presents several problems. The contract must be generated manually for each object. Since the endpoint includes the contract, the endpoint is also manually generated for each object. Manual generation of a contract (and therefore of the endpoint) can be long and costly, with a risk of user error. In addition, the endpoint may become out of date if it is not updated as soon as the business object is updated, at the risk of the user trusting endpoint information that is not updated. not represent the commercial object in a precise way.

Therefore, there is a need in the art for a more efficient, economical and accurate way to allow client devices to access and consume remote commercial objects.

The disclosed method and apparatus herein enables technical and non-technical users to bring clients to discover, access, and consume objects without the need to manually generate an endpoint for each object. An endpoint can be any information that a client device needs before it can communicate with a business object. The client may request to consume or use a business object, and the endpoint information, such as the contract, is automatically built and published. For the customer, everything happens as if an endpoint was already in place, whereas it was generated when the customer requested the business object. The endpoint is automatically built and published when the business object is created.

This whole process takes place without the existence of address, binding, or contract information representing the object actually entered. Endpoint information is dynamic and precisely represents the most recent information about the business object. In this way, a client device can easily discover and request an endpoint for a commercial object.

Thus, a dynamic endpoint generation system is provided that allows a client device to consume a commercial object, the endpoint including an address, a link, and a contract, including a structured processor for causing the system to perform: the loading of a definition of the business object, the definition including properties and methods; performing an iteration through the definition; and mapping the definition to protocols supported by the endpoint, the mapping comprising: (i) mapping the commercial object properties to data contracts; (ii) the mapping of business object methods to operating contracts; and (iii) verifying that business object method signatures include inputs and outputs supported by the endpoint; wherein the endpoint is generated in response to at least one of: (a) the request for the business object by the client device, (b) the creation of the business object, and (c) the update of the commercial object.

In addition, the following may be provided separately or in combination, in whole or in part: - in the system, the processor is structured to further cause the system to perform the generation of. NET endpoints intended to be used in a WCF framework and the generation of Atom, XML and JSON endpoints for use in a REST framework; the commercial object belongs to a category, and the endpoint is generated for the category; the processor is structured to further cause the system to perform the generation of the endpoint based on a configuration; - configuration includes service configuration, WCF configuration, REST configuration and managed configuration; - the managed configuration includes configuration if a static endpoint is generated for the business object and the endpoint is isolated; the isolation comprises at least one of: (i) memory isolation, (ii) address isolation and (iii) security link isolation; -the configuration of the isolation allows the configuration of at least one of: (i) if a server rebuilds all endpoints on the server, or (ii) if the server rebuilds less than all endpoints on the server;

Also concerned is a computer-readable medium storing instructions for generating a dynamic endpoint allowing a client device to consume a commercial object, the endpoint including an address, a link and a contract, the instructions leading to a computing device to be performed: loading a definition of the commercial object, the definition comprising properties and methods; performing an iteration through the definition; and mapping the definition to protocols supported by the endpoint, the mapping comprising: (i) mapping the commercial object properties to data contracts; (ii) the mapping of business object methods to operating contracts; and (iii) verifying that business object method signatures include inputs and outputs supported by the endpoint; wherein the endpoint is generated in response to at least one of: (a) the request for the business object by the client device, (b) the creation of the business object, and (c) the update of the commercial object. Other features and advantages will be described below and will become apparent from the detailed description below with reference to the accompanying figures.

BRIEF DESCRIPTION OF THE FIGURES

Figure 1 is a high-level block diagram of exemplary communication system.

Fig. 2 is a more detailed block diagram showing an example of a computing device.

Fig. 3 is a block diagram showing exemplary connections between a plurality of data sources and an electronic form via an object broker.

Figure 4 is a block diagram showing exemplary connections between data sources and commercial objects.

Figure 5 is a more detailed view of an example of a customer order page and connections associated with a customer business object and a sales order object.

Figure 6 is a flowchart of an exemplary object broker process.

Figure 7 is a flowchart of an exemplary form process.

Figure 8 is an exemplary process map with a localized region of the highlighted process map.

Figure 9 is a screenshot of an exemplary activity band.

Figure 10 is a screenshot of an exemplary design assistant in a partially rotated state.

Fig. 11 is a flow chart of an exemplary configuration assistant process.

Fig. 12 is a diagram showing an example of a system implementing a dynamic endpoint generator to enable an application to consume commercial objects.

Figure 13 is a flowchart illustrating an exemplary process of generating, deploying, and publishing a business object, automatically generating a dynamic endpoint for the business object, and authorizing a client device to consume the business object. business object using the dynamic endpoint.

Fig. 14 is a flowchart illustrating an example of endpoint configuration for a commercial object.

DETAILED DESCRIPTION

The present system is most easily realized in a network communication system. A high level block diagram of an exemplary network communication system 100 is illustrated in FIG. 1. The illustrated system 100 comprises one or more client devices 102, one or more routers 106, and a plurality of different data sources. comprising database servers 110 and / or databases 112. Data transferred to client devices 102 from data sources 108 and data transferred from client devices 102 to data sources 108 are managed by one or more object broker servers 114. These devices may communicate with each other via a connection to one or more communication channels 116 such as the Internet and / or other data networks, including in particular an appropriate wide area network or a local area network. It should be appreciated that the devices described herein may be directly connected to one another instead of going through a network.

The data sources 108 store a plurality of files, programs and / or web pages in one or more databases 112 for use by the client devices 102. For example, a data source may store information of customers. The data sources 108 may be connected directly to a database server 110 and / or via one or more network connections.

A data source 108 and / or an object broker server 114 may interact with a large number of other devices. Therefore, each data source 108 and / or object broker server 114 is typically a high-end computer with a large storage capacity, one or more fast microprocessors, and one or more high-speed network connections. Conversely, with respect to a typical server, each client device 102 typically includes a lower storage capacity, a single microprocessor, and a single network connection.

A more detailed block diagram of the electrical systems of a computing device (e.g., a portable client device 102, a personal computer client device 102, a router 106, a database server 110, and / or a server Object broker 114) is illustrated in FIG. 2. Although the electrical systems of these computing devices may be similar, the structural differences between these devices are well known. For example, a typical portable client device 102 is small and lightweight compared to a typical database server 110.

The exemplary computing device 102, 106, 110, 114 comprises a main unit 202 preferably having one or more processors 204 electrically coupled by an address / data bus 206 to one or more memory devices 208, other computer circuits 210, and one or more interface circuits 212. The processor 204 may be any suitable processor, such as a microprocessor of the Intel Pentium® family of microprocessors. The memory 208 preferably comprises a volatile memory and a non-volatile memory. Preferably, the memory 208 stores a software program that interacts with the other devices in the system 100, as will be described hereinafter. This program can be executed by the processor 204 in any suitable manner. The memory 208 may also store digital data indicative of documents, files, programs, web pages, etc. extracts from another computing device and / or loaded via an input device 214.

The interface circuit 212 may be implemented using any appropriate interface standard, such as an Ethernet interface and / or a Universal Serial Bus (USB) interface. One or more input devices 214 may be connected to the interface circuit 212 to input data and commands into the main unit 202. For example, the input device 214 may be a keyboard, a mouse, a display touch, a pad, a ball, an iso point and / or a voice recognition system.

One or more displays, printers, speakers, and / or other output devices 216 may also be connected to the main unit 202 through the interface circuit 212. The display 216 may be a CRT display (CRT), a liquid crystal display (LCD), or any other type of display. The display 216 generates visual displays of data generated during the operation of the computing device 102, 106, 110, 114. For example, the display 216 may be used to display web pages received from the object broker server 114 comprising data from a plurality of data sources 108. The visual displays may include human input prompts, operating time statistics, calculated values, data, and so on.

One or more storage devices 218 may also be connected to the main unit 202 through the interface circuit 212. For example, a hard disk, a CD player, a DVD player, and / or other storage devices can be connected to the main unit 202. The storage devices 218 can store any type of appropriate data.

The computing device 102, 104 may also exchange data with other network devices 220 via a network connection 116. The network connection may be any type of network connection, such as a connection. Ethernet, digital subscriber line (DSL), telephone line, coaxial cable, etc. Users of the system 100 may be required to register with one or more of the computing devices 102, 106, 110, 114. In this case, each user may choose a user identifier (for example, an e-mail address). mail) and a password that can be requested for the activation of services. The user ID and password may be transmitted over the network 116 using encryption built into the user's web browser. Alternatively, the user identifier and / or the password may be affected by the computing device 102, 106, 110, 114.

In one embodiment, a user at a client device 102 views and / or modifies data from a plurality of different data sources 108 via an interactive electronic form. An exemplary block diagram showing connections between a plurality of data sources 108 and an electronic form 302 via an object broker process 304 is illustrated in FIG. 3. In general, the broker process objects 304 (described in detail hereinafter with reference to FIG. 6) compiles data in a variety of different native formats from the different data sources 108 (for example, different legacy database systems) in standardized business objects 306, 308 (for example, in a declarative format such as XML (Extensible Markup Language)). A user can then view the data using one or more electronic forms 302, 310, 312. In addition, the user can manipulate data and / or add data via the electronic forms 302, 310, 312. In this case, the object broker process 304 accepts the data via the business objects 306, 308 and stores the data in the data sources 108 in the correct native format.

In this example, the data sources 108 include an enterprise resource planning (ERP) data source 314, a customer relationship management (CRM) data source 316, a custom data source 318, a source add-in data 320 and a function data source 322. In addition, role service 323 and object data storage 325 are included in the system. Typically, an ERP data source 314 stores accounts payable, accounts receivable, inventory, and so on. Typically, a CRM data source 316 stores data about leads, quotes, orders, and so on. A custom data source 318 is a data source 108 that is not considered a standard commercial product. For example, a company may have a custom data source that stores manufacturing information in real time. Some data sources 108 may use an intermediate server for communications. For example, the ERP data source 314 uses a BizTalk 324 server.

The add-in data source 320 stores data associated with user-added form fields that are not supported by any of the other data sources 108. For example, a company may launch a map program frequent buyer and she may need to store a card number for each participant. As a result, a user can add a frequent buyer number field to an existing form that contains inheritance data. Since the existing data sources 108 in this example do not have a frequent buyer number field, the frequent buyer number field and the associated data are stored by the complement data source 320.

To manipulate data in a particular data source 108, the object broker process 304 preferably uses methods embedded in the associated data source 108. For example, each data source 108 typically includes methods for storing data. / extracting data from / from the data source 108 (for example, the CRM data source may support a "LoadContact" method as will be described in detail below). In addition, the system 300 allows a user to create his own functions. For example, a user may need to apply a discount to some customers. Nevertheless, the existing data sources 108 do not necessarily include a method for calculating the discount. Therefore, the user can create a "CalcDiscount" function as will be described hereinafter. The user-defined functions can use data from multiple data sources 108. The definitions of these user-defined functions are then stored in the function data source 322.

User-defined functions can be created using a graphical user interface tool. For example, parameters for a user-defined function can be defined by selecting a graphical representation of the parameter associated with a business object. Preferably, the user-defined functions are stored as snippets. Snippets include a structure portion that defines the function and a user interface portion that provides the user with a way to test the function. For example, the structure portion may be stored in XML form, and the user interface portion may be stored as HTML in the same file.

Some user-defined functions may be executed by client devices 102, which reduces communication with server 110, 114. Other user-defined functions may require server-side execution. Preferably, it is determined whether a particular function is to be performed on the client side or the server side, and an indicator of this determination is stored with the function snippet. For example, user-defined functions that have been built from certain predefined primitives (for example, add, multiply, loop, lower, etc.) can be determined to be executable by the client device 200, while other user-defined functions including database lookups (e.g., SQL statements) can be determined to be executable by a server 110, 114.

From the perspective of the user, the data of the data sources 108 (as well as the data calculated from the data in the data sources 108, for example a discount) are displayed using one or more electronic forms 302, 310, 312. In addition, the user can manipulate the data and / or add data via the electronic forms 302, 310, 312. The forms 302, 310, 312 can be combined in pages 302 and a form can be used. For example, the customer order page 302 combines the customer contact form 310 with the order list form 312 (as will be described in detail hereinafter with reference to the Figure 5). In addition, portions of the form and / or entire forms on a larger page may be locked so that only certain users can edit that portion of the form or page.

To facilitate forms 302, 310, 312 combining data from different data sources 108, the system 300 employs an object broker process 304 (described in detail hereinafter with reference to FIG. 6) and a form process. 326 (described in detail below with reference to FIG. 7). In one embodiment, the object broker process 304 is an ASP code executing on the object broker server 114 and the form process 326 is a JavaScript executing on a client device 102. The process Object broker 304 compiles data in a variety of different native formats from different data sources 108 into standardized business objects 306, 308 (e.g., XML files). In addition, the object broker process 304 accepts the data via the business objects 306, 308 and stores the data in the data sources 108 in the correct native format.

More specifically, the object broker process 304 uses a plurality of broker services to communicate with the data sources 108. Preferably, a broker service is used for each data source 108. In this example, the broker process is used for each data source 108. Item Broker 304 includes an ERP 328 Broker Service, a CRM 330 Broker Service, a 332 Custom Broker Service, a 334 Complement Broker Service, and a 336 Broker Broker Service. Each Broker 328 Service, 330, 332, 334, 336 is adapted to communicate with the associated data source 108 using the native formats and protocols of the data source.

Each broker service 328, 330, 332, 334, 336 then automatically exposes the properties and methods of the associated data source 108 as standardized properties and methods 338 for use by the business objects 306, 308. For example, the ERP broker service 328 communicates with the ERP data source 314 through the BizTalk server 324 and exposes the properties and methods of the ERP data source 314 to the client business object 306 and to the client. 308 commercial object in the form of XML files. If new properties and / or methods become available from a data source 108, the associated broker service preferably detects these new properties and / or methods and automatically exposes them for use by the objects. Commercial objects 306, 308. Commercial objects 306, 308 may include some or all of the disclosed properties and methods 338. Each business object 306, 308 then exposes its included properties and methods 340 to the form process 326.

The form process 326 uses commercial object methods 340 in response to form events and fills out the forms 302, 310, 312 with data from the commercial object properties 340. For example, a user can press a "Load" button on the client control page 302, which causes the form process 326 to use one or more methods 340 exposed by the business objects 306, 308. object broker 304 to extract the appropriate data from one or more data sources 108. The data is then returned as commercial object properties 306, 308, and the form process 326 uses the data to fill the forms 310 , 312.

In addition, the form process 328 may store values in the commercial object properties 340 and use methods for the new / changed data to be stored in the appropriate data source 108 through the broker process. For example, a form may accept a new value for a client address and use an UpdateContact method to cause the new address to be stored in the appropriate data source 108.

A more detailed block diagram showing these connections between the exemplary data sources 108 and the exemplary business objects 306, 308 is illustrated in FIG. 4. In this example, the client business object 306 is connected to the ERP data source. 314 and the CRM data source 316. The control business object 308 is connected to the ERP data source 314, the add-in data source 320 and the function data source 322. These logical connections can be defined in any appropriate manner. For example, a graphical user interface may be used to allow a user to draw connection lines between graphical representations of data sources 108 and graphical representations of business objects 306, 308.

These logical connections are updated by the object broker process 304. For example, data for completing the customer contact form 310 and the order list form 312 are brought into the customer business object 306 and in the order business object 308 from the data sources 108 by the object broker process 304. Similarly, new and changed data from the customer contact form 310 and the order list form 312 are sent from the client business object 306 and the business object 308 to the data sources 108 by the object broker process 304. In addition, the role service 323 can generate a definition of object reduced on the basis of these complete object definitions. For example, the role service 323 can extract a role associated with a particular user and a plurality of properties and / or authorized methods associated with that role. Unauthorized properties and / or methods are then removed from the business object definition (for example, a user is not allowed to write to the client business object, so the UpdateBalance and UpdateContact methods are removed). The exemplary client business object 306 includes a client identifier property, a name property, an address property, a remaining balance property, a balance loading method, a balance update method, a contact loading method and a contact update method. The client identifier property in the client business object 306 is connected to the client identifier property in the ERP data source 314 and / or the client identifier property in the CRM data source 316 The name property and the address property in the client business object 306 are connected to the name property and the address property in the CRM data source 316. The remaining balance property in the object Customer 306 is connected to the remaining balance property in the ERP data source 314. The balance upload method and the balance update method in the customer business object 306 are connected to the load method and the balance updating method in the ERP data source 314. The contact loading method and the contact update method in the client business object 306 are connected to the method of updating the balance. The exemplary commercial order object 308 includes a control number property, a client identifier property, a property of the client, a contact owner, and a contact update method in the CRM data source. delivery date, a tax property, a total property, a status property, a purchase order method, an order loading method, an order update method, a checkout method, a checkout method discount calculation method and a tax calculation method. The order number property and the status property in the order business object 308 are connected to the order number property and the status property in the ERP data source 314. The client identifier property in the control business object 308 is connected to the client identifier property in the ERP data source 314 and / or the client identifier property in the add-in data source 320. The delivery date property , the tax property and the total property in the order business object 308 are connected to the delivery date property, the tax property, and the total property in the add-in data source 320. The method order creation method, the command loading method, the command update method and the command delete method in the order business object 308 are connected to the order creation method, the order loading method, the order update method and the order deletion method in the ERP data source 314. The discount calculation method and the method in the business object 308 are connected to the discount calculation method and the tax calculation method in the function data source 322. It should be realized that the names of the properties and / or methods in the data sources 108 need not be identical to the corresponding names of the properties and / or methods in the business objects 306, 308.

A more detailed view of the customer control page 302 and the connections associated with the customer business object 306 and the business object 308 is illustrated in FIG. 5. In this example, if the user presses a load button 502, the binding software associated with the form process 326 calls the contact load method of the client business object 306 and the order load method of the order business object 308. For both method calls, the form process 326 provides the value of the customer number field 504 from the customer contact form 310. Alternatively, the form process 326 can obtain the value of the customer number field 504 from of the client identifier property of the client business object 306 and / or the business control object 308. These logical connections may be defined in any suitable manner. For example, a graphical user interface may be used to allow a user to trace connections between forms 302, 310, 312 and graphical representations of business objects 306, 308. Preferably, the user may design forms using only a web browser. For example, an asynchronous Java and XML interface (AJAX) can be used.

When the form process 306 calls the contact load method of the customer business object 306 with the value of the customer number field 504 as a parameter (for example, using AJAX), the object broker process 304 converts the method call into the native language of the associated data source 108 and extracts the associated data from the data source 108 in its native format. Specifically, the CRM 330 broker service invokes the native contact load method of the CRM data source 316 and receives the contact name and address of the CRM 316 data source. The CRM 330 broker service then stores the name and contact data in the client business object 306. For example, the CRM broker service 330 may be an ASP code running on the object broker server 114 that sends an XML file (or another standardized file) to the form process 326, which is a JavaScript code running on the client device 102 which displays the client contact form 310. Once the client business object 306 is updated with the new data of name and address, the form process 326 fills the name field 506 and the address field 508 of the customer contact form 310. Using this method, an HTML form can be updated without posting all the information. formulai re on a server and renew the rendering of the entire HTML form.

Likewise, when the form process 326 calls the order business object control change method 308 with the value of the customer number field 504 as parameter, the object broker process 304 converts the call from method in the native language of the associated data source 108 and extracts the associated data from the data source 108 in its native format. Specifically, the ERP broker service 328 invokes the native command loading method of the ERP data source 314 and receives a list of command numbers, an associated list of totals, and an associated status list of the ERP data source 314. For example, the data can be returned in the form of a database table. These values are ultimately used to fill the order number column 510, the amount column 512 and the status column 514 of the control panel 516 in the order list form 312. Nevertheless, in this example, the delivery date column 518 can not be provided by the ERP data source 314, because the ERP data source 314 does not have this information.

The delivery date data is stored in the complement data source 320 (i.e., the delivery date field was subsequently added by the user). Therefore, when the form process 326 invokes the command load object control method 308 with the value of the client number field 504 as a parameter, the complement broker service 334 invokes the method of loading the client number field 504 as the parameter. delivery date of the add-in data source 320 and receives a list of delivery dates and associated order numbers from the add-in data source 320. The object broker process 304 and / or the form process 326 perform the correlation between the delivery dates on the one hand and the amount data and the status data received from the ERP data source 314 on the other hand using the order number data that is common to both lists.

The object broker process 304 then stores the list of order numbers, the associated list of delivery dates, the associated list of totals, and the associated list of statuses in the order business object 308. For example, the service ERP broker 328, complement broker service 334, and / or other software (for example, ASP code running on the object broker server 114) may send an XML file (or another file standardized) to the form process 326 (for example, a JavaScript executing on the client device 102). Once the business object 308 is updated with the new data, the form process 326 fills the control panel 516 in the order list form 312.

A flowchart of an exemplary object broker process 304 is illustrated in FIG. 6. Preferably, the object broker process 304 is realized in one or more software programs stored in one or more memories and executed by one or more multiple processors. For example, the object broker process 304 may be an ASP code (or any other type of software) running on the object broker server 114. Although the object broker process 304 As described with reference to the flowchart shown in Fig. 6, it should be appreciated that many other methods can be used to perform actions associated with the object broker process 304. For example, the order of many steps can be changed and some of the steps described may be optional.

In general, the object broker process 304 receives standardized method calls from the form process 326 and converts the standardized method calls into native method calls. The object broker process 304 then sends the native method calls to the source or associated data sources 108 and receives one or more native responses from the source or data sources 108. The object broker process 304 then converts the response or native responses into one or more standardized responses and sends the response or standardized responses to the form calling process 326.

More specifically, the object broker process 304 receives a method call from the form process 326 using a standardized protocol (block 602). The standardized method call is associated with a business object and includes property values (i.e., parameters) needed for that method. For example, a client device 102 may display the client control page 302 as an HTML document. By using an onBlur event trigger, the client device 102 can execute JavaScript code that sends an XML file 604 representing "LoadContact (1234567)" on the Internet 116 through an HTTP request to an ASP script. executing on the object broker server 114. It should be understood that any suitable protocol can be used instead of HTML, JavaScript, XML, HTTP, and / or ASP. For example, VBScript can be used instead of JavaScript, and Perl can be used instead of ASP.

The exemplary XML request 604 includes the "LoadContact" method call 606 delimited by a "Method" openness tag 608 and a "Method" closure tag 610. In addition, the exemplary XML request 604 includes the property value " CustomerlD »612 delimited by an" CustomerlD "opening label 614 and a" Customer ID "closing label 616.

The object broker process 304 then forwards the standard method call to the broker service associated with the method call (block 618). For example, the object broker process 304 may send the XML file 604 containing the LoadContact method call 606 to the CRM broker service 330.

The broker service associated with the method call then converts the standardized protocol method call into a native protocol for the associated data source 108 (block 620). For example, the CRM broker service 330 can formulate a native request 622 for the CRM data source 316 from the received XML file 604. The native request 622 can use any protocol. For example, the native request 622 may be an SQL request that knows the CRM data source 316 which contains the customer contact data in a "FullName" field 624 and a "HomeAddress" field 626 of an indexed "ContactsTable" 628 by a "CustNum" field 630.

The broker service associated with the method call then sends the native request to the associated data source 108 and receives a native response from the data source 108 (block 632). For example, the CRM broker service 330 may be an ASP script running on the object broker server 114 that sends the native request 622 to the CRM data source 316 as a SQL request and receives a native response 634. as a comma delimited list. In this example, the native response 634 includes the name value 634 and the address value 636 of the contact associated with the property value "CustomerlD" 612.

The broker service then converts the native response into the standardized protocol (block 638). For example, the broker service 330 can wait for a SQL response from the CRM data source 316 and generate an associated XML response 640. In this example, the XML response 640 includes all the information from the original XML request 604 (c that is, the "LoadContact" method call 606 delimited by a method "Open" tag 608 and a "Method" closure tag 610 and the "CustomerlD" property value 612 delimited by a tag. 'CustomerlD' opening 614 and a 'CustomerlD' closing label 616). In addition, the XML response 640 includes the name value 634 delimited by a "Name" opening tag 642 and a "Name" closing tag 644, as well as the address value 640 delimited by an opening tag " Address "646 and a closing tag" Address "648.

The broker service then sends the standardized response to the call function in the Form 326 process (block 646). For example, the CRM broker service 330 can send the XML response 640 to a JavaScript associated with the client control page 302 on a client device 102. As will be described hereinafter, the form process 326 can then use XML response 640 to populate the XML-based client command page 302.

A flowchart of an exemplary form process 326 is illustrated in Figure 7. Preferably, the form process 326 is performed in one or more software programs that are stored in one or more memories and executed by one or more processors. For example, the form process 326 may be a JavaScript code (or any other type of software) running on a client device 102. Although the form process 326 is described with reference to the flowchart shown in FIG. In Figure 7, it should be appreciated that many other methods may be used to perform the actions associated with the form process 326. For example, the order of many steps may be changed and some of the steps described may be optional.

In general, the Form 326 process detects events associated with a form (for example, the HTML 302 client ordering page) and sends standardized method calls (for example, the XML request 604) to the broker process. 304. When the form process 326 receives the response or the standardized responses (for example, the XML response 640) from the object broker process 304, the form process 326 can then use the response or the standardized responses. to fill out the form (for example, the HTML 302 client ordering page).

More specifically, the form process 326 detects an event requiring the update of a form and / or page (block 702). For example, the form process 326 may be a JavaScript code running on a client device 102 in association with the customer order page 302. When a user presses the load button 502 on the contact form from client 310, the form process 326 detects the onClick event associated with the Load load button 502 and executes a portion of the JavaScript code associated with this onClick event (i.e., the event handler).

When the event handler is executed, the form process 326 generates an appropriate method call in the standard protocol (block 704). For example, the client device 102 may execute JavaScript code that generates the XML file 604 representing "LoadContact (1234567)". As described above, the exemplary XML request 604 includes the "LoadContact" method call 606 delimited by a "Method" openness tag 608 and a "Method" closure tag 610. In addition, the request Exemplary XML 604 includes the "CustomerlD" property value 612 delimited by an "CustomerlD" opening tag 614 and a "CustomerlD" closing tag 616.

The form process 326 then sends the standardized method call to the object broker process 304 (block 706). For example, the client device 102 may send the XML request 604 on the Internet 116 via an HTTP request to an ASP script running on the object broker server 114. The broker process of object 304 then communicates with associated data sources 108 using the native protocols and sends a standardized response to the form process 326 (block 708). For example, the client-side JavaScript associated with the form process 326 may receive the XML response 640 of the server-side ASP script associated with the object broker process 304.

As described above, the exemplary XML response 640 includes all information from the original XML request 604 (i.e., the label-delimited "Load-Contact" method call 606 method "opening" 608 and a "Method" closing label 610 and the "CustomerlD" property value 612 delimited by an "CustomerlD" opening label 614 and a "CustomerlD" closing label 616). In addition, the XML response 640 includes the name value 634 delimited by a "Name" opening tag 642 and a "Name" closing tag 644, as well as the address value 640 delimited by an opening tag " Address "646 and an" Address "closure tag 648. The form process 326 can then use the standardized response to fill out the client's form (block 710). For example, the client-side JavaScript can fill the name field 506 and the address field 508 of the HTML-based client contact form 310.

A workflow design tool 800 allows a user to define a resource map. In this example, the workflow design tool 800 includes a file explorer section 804 and a design template 806. The file explorer section 804 allows the user to find and organize a file. plurality of files associated with the workflow. The design pattern 806 allows the user to draw a graphical representation of the resource card 802. In this example, there is shown a resource card 802 comprising a staff item 808 and a client object 810. The object 808 and the client object 810 each comprise one or more input nodes 812 and one or more output nodes 814. The input nodes 812 are connected to the output nodes 814 by process arrows 816. in this example, a support process 816a and a sales process 816b each exit the personnel object 808 and each enter the client object 810. Similarly, an 816c control process exits the client object 810 and enters the staff object 808.

By defining workflows in terms of known resources (for example, the staff object 808 and the client object 810) and the interactions between these resources (for example, the client object 810 needs the support of Personnel Object 808), the workflow designer can discover and design each process starting at a high level and down to underlying processes and automated workflows.

802 resource cards also allow a business object inheritance to show classes of a business object and child objects of that business object. Child objects can be associated with parent objects by modifying properties associated with the parent object and / or by adding properties to the parent object.

A unique combination of parent / child objects may have a unique binding definition within another resource on the pattern. For example, the parent client object 810 may include a child object of a public client and a child object of a private client. The sales process 816b between the 808 staff object and the 810 customer object may be different depending on the type of 810 client object (that is, an 816b sales process for 810 public customers). and another sales process for private customers 810). Similarly, the staff object 808 may be a parent object with sales staff and support staff in the form of two child resources. The workflow design tool 800 is used to create a process map 902. In this example, the support process 816a is defined. The exemplary support process 816a includes a start step 904, a rejection step 906, and an approval step 908. In this example, only one of these steps 904, 906, 908 must be performed. Therefore, a new step 910 is set to select one of the three steps 904, 906, 908. The new step 910 comprises a plurality of actions 912 and a plurality of corresponding output nodes 814. In this example, the new step 910 step 910 includes an approval action 914, a rejection action 916 and a redirection action 918. The user connects the rejected output node 814a to the input node 812a of the rejection step 906 by moving the process 816d. The associated line logic is automatically configured for the user.

Another process card 1000 is shown in FIG. 8. In this exemplary process card 1000, a portion 1002 of the process card 1000 is highlighted. Specifically, an approval step 1004 and a notification step 1006 are included in a highlighted portion 1002. This portion 1002 may define a localized region of the process map 1000 while other portions of the process map 1000 ( for example, the remainder of the process map 1000 in this example) are considered global regions. Using process inheritance, this localization of certain process regions allows a process owner to maintain control of the overall process while allowing other users to customize certain 1002 portions. For example, the overall process can determine when something is approved and where the notification is routed, but an office in one organization can perform a set of actions in response to approval, and another office in the organization can perform another set of actions in response to the approval. 'approval. Local processes may even include additional process steps that are specific to the localized region. The process 1000 is updated as part of a single process definition so that changes to the global portion automatically apply to all instances of the process 1000 and changes to the local portion 1002 apply only 'to associated places.

In addition, individual steps and / or process portions 1002 may be locked. In this example, an approval step 1008 is individually locked, and the local portion 1002 is also locked. Each locked step and each locked portion includes a lock icon 1010 to indicate a locked status. By locking a process step 1008 and / or a process portion 1002, process designers may limit another user's ability to change certain configuration parameters, add or remove dependencies, and so on. in the logic defined and locked. Lock attributes can also be manipulated by wizards and templates in a manner programmed to allow lower-level design blocks to hide or lock their implementation logic.

A collaborative framework allows any workflow designer within the workflow design tool 800 to visually share his design pattern 806 with another user on the network 116. A process designer can also engage in a voice or text conversation with other stakeholders to discuss the process being designed. In this way, the process designer can involve other users in process design by using collaboration and application sharing tools. For example, by right-clicking on the 806 design pattern, the process designer can contact a particular person in the accounting department to ask who should be notified when a purchase is approved. Text messages and / or voice recordings between collaborators may also be recorded in a database for later reference. For example, when evaluating a process to revise it, the process designer can listen to a collaborative conversation to determine why a particular step has been implemented in the current way.

Each step in the graphical representation of the process preferably comprises a band of activity. An exemplary activity band 1100 is illustrated in FIG. 9. In this example, the activity band 1100 includes one or more event icons 1102 that represent the events associated with the process step. For example, the user can move an e-mail sending event in a process step. In such a case, an e-mail event icon 1104 is added to the activity band 1100. If the number of event icons 1102 exceeds the width of the activity band 1100, the user can browse event icons using 1106 arrow buttons.

When a particular event icon 1102 is selected, the user is presented with a configuration wizard to configure that portion of the process. Preferably, each step of a process is presented to the user as a cube, and the configuration wizard rotates in the view to create an effect of a single entity on which the user is working. For example, when a user clicks on the e-mail event icon 1104, the 1100 activity band runs in an e-mail event setup wizard 1200. A partially-rotated view of an assistant The exemplary e-mail event setup 1200 is illustrated in FIG. 10. The e-mail configuration wizard 1200 can be used to design dynamically constructed e-mails used by one or more workflow processes. job. For example, the notification step 1006 of the approval process 1000 shown in Fig. 8 includes an output 814 which may be an automatic e-mail message. The E-mail Configuration Wizard 1200 can be used to design how this e-mail message is built. The E-mail Configuration Wizard can use a reference wizard that allows a user to use a process while designing another process. For example, a reference wizard might allow a user to call any method in a .NET set, web service, or WCF service as part of a process design.

Preferably, the configuration wizard 1200 comprises a main display portion 1202 and a next Next 1204 button. The main display portion 1202 displays a page of the setup wizard 1200. The next Next 1204 button advances the main display portion 1202 on the next page of the setup wizard 1200. A previous button (not shown) changes the main display portion 1202 to display the previous page of the setup wizard 1200. The wizard The configuration 1200 also includes a page palette 1206. The page palette 1206 comprises a plurality of thumbnails 1208 to 1220. Each of the thumbnails 1208 to 1220 represents one of the pages in the configuration wizard 1200. The user can pass quickly to any page in the 1200 setup wizard by clicking on the associated thumbnail. When a user moves to a particular page in the setup wizard 1200, the main display portion 1202 is traced to reflect that page.

In addition, the user can quickly see a pop-up window of any page in the 1200 Setup Wizard without going to that page (that is, without drawing the page content in the portion of the page. main display 1202) by dragging the slider on the associated thumbnail. For example, the third page 1212 of the exemplary e-mail setup wizard 1200 may be displayed as a pop-up window. In this example, the third page 1212 of the setup wizard 1200 includes a topic input box 1402 and a body input box 1404. The topic input box 1402 of the configuration wizard E-mail 1200 is used to define the subject line of the automatic e-mail. The body input box 1404 of the e-mail configuration wizard 1200 is used to define the body of the automatic e-mail. The values entered in a page of the Process Configuration Wizard 1200 are visible in the pop-up window view. For example, if the user entered "Approval Report" in the topic entry box 1402 of the third page 1212 of the E-mail Configuration Wizard 1200, "Approval Report" is visible in the subject entry box 1402 of the pop-up window. In this way, the user can enter values in different pages of the Configuration Wizard 1200 that are consistent with other entries without needing to remember other entries and / or leave the current page.

A flowchart of an exemplary configuration assistant process 1500 is illustrated in FIG. 11. Preferably, the configuration assistant process 1500 is performed in one or more software programs that are stored in a plurality of memories and that are executed. by one or more processors. Although the configuration wizard process 1500 is described with reference to the flowchart shown in FIG. 11, it should be appreciated that many other methods of performing the actions associated with the configuration wizard process 1500 may to be used. For example, the order of many steps may be changed, and some of the steps described may be optional.

The process 1500 begins when a client device 102 detects an event associated with a graphical representation of a process step 1008 (block 1502). For example, the user can click a Setup button in the 1100 activity band. In response, the client device 102 causes the display of an animated sequence (block 1504). For example, the client device may display the three-dimensional rotational activity band to show an "e-mail configuration wizard" side of a cube. In this way, the user receives visual feedback that the two objects (for example, activity band 1100 and e-mail setup wizard 1200) are linked. The configuration wizard includes a plurality of configuration pages in a thumbnail pallet 1206 and a current configuration page in a main display portion 1202 (block 1506). For example, the first page of an e-mail setup wizard may prompt the user to enter the recipient's e-mail address and the subject of the e-mail message. While client device 102 displays configuration wizard pages and receives user configuration information, client device 102 also searches for a plurality of events such as mouse movements and mouse clicks.

If a first type of event associated with one of the thumbnails 1208-1220 is detected (block 1508), the client device 102 preferably displays a larger version of the associated thumbnail (block 1510). For example, if the user moves the mouse cursor over a particular thumbnail 1208-1220, a popup window 1212 representing a larger version of that thumbnail can be displayed. Preferably, the larger version of the imager is a separate window 1212 which is smaller than the main display portion 1202. Nevertheless, any suitable type of image may be used. For example, the larger version of the thumbnail may "temporarily" replace the main display portion 1202.

If a second type of event associated with one of the thumbnails 1208-1220 is detected (block 1512), the client device 102 preferably deletes the larger version of the associated image (block 1514). For example, if the user moves the mouse cursor out of a particular thumbnail, the pop-up window representing the larger version of that thumbnail may be removed. If the larger version of the thumbnail is a separate window, this window is removed from the display and the content "below" the deleted window is retraced. If the larger version of the imager has replaced the main display portion 1202, then the previous contents of the main display portion 1202 (e.g., the current configuration page) is traced in the main display portion. 1202.

The larger version of the imager also presents the configuration information previously entered by the user. For example, if user has entered the recipient's email address on the first page of the setup wizard, moved to another page of the setup wizard and then wished to call back the email address entered without back to the first page, the user can simply move the mouse over the first thumbnail to recall the information entered.

If a third type of event associated with one of the thumbnails 1208-1220 is detected (block 1516), the client device 102 preferably replaces the main display image with a full-size version of the associated imager ( block 1518). For example, if the user clicks with the mouse on a particular thumbnail, the main display portion 1202 preferably passes to that page in the setup wizard. Unlike the mouse passing example on the imager, the exit of the mouse out of the thumbnail does not return the main display portion 1202 to the previous page (i.e. the user has moved to this configuration page instead of temporarily viewing this configuration page). At any time, the user can enter one or more configuration options (block 1520), and the configuration options are stored (block 1522). If the user exits the configuration wizard (block 1524), the process 1508-1520 for searching user actions and configuration options is repeated. While the dynamic business object can be a useful tool in today's organizations, once a dynamic business object has been created, it can not be easily accessed and consumed by remote client devices. Some existing technologies require that before the business object is consumed through existing Web services technologies, an endpoint must be defined. An endpoint is used to specify the interaction requirements between the client device and the business object. For example, the client device sends a message to the endpoint of the business object when it wants to use the business object, and the message is formatted according to the information specified by the endpoint. A business object can have multiple endpoints allowing different ways for customers to consume that object. Other existing technologies may provide a default endpoint to which the user can not configure endpoint settings or settings.

Typically, an endpoint is defined by an address, a link, and a contract. An address is the location where the endpoint is located. A binding specifies how a business object can be consumed, such as a protocol or encoding information. A contract for each object lists the operations exposed by the business object. All of this information must be specified before a remote client device can use a business object.

Current approaches present several problems. In some cases, the contract must be manually generated for each object. Since the endpoint includes the contract, the endpoint is also manually generated for each object. The manual generation of a contract (and therefore of the endpoint) can be long and expensive, with the risk of error on the part of the user. In addition, the endpoint may become stale if it is not updated as soon as the business object is updated, with the risk that the user relies on endpoint information. which do not accurately represent the commercial object.

The present system makes business objects available to clients through endpoints, where the endpoints are dynamically generated. It is not necessary to manually generate an endpoint. Endpoints can be stored on a server. Endpoints associated with objects are generated automatically when business objects are created, or endpoints can be created when the business object is requested. In one embodiment, the endpoints are generated based on configuration criteria that allow the user to apply varying levels of isolation to the endpoints, as will be explained hereinafter. Regardless of the use of configuration criteria, there is no need to manually generate endpoint information because the endpoint is automatically generated when the business object is requested by a client device or is created . Client devices can communicate with the endpoint and use contracts associated with business objects as if the contracts had been generated manually. Business object properties can be exposed through data contracts and business object methods can be exposed through operating contracts.

The present system frees resources and improves performance because new objects can be designed, deployed and consumed without the need to generate endpoints. Client devices only need to know the dynamic endpoint and connect to it. The client devices can thus use objects without the need to first generate, build or publish contracts. Endpoint information, such as a contract, is generated by the same service that created the business objects. The endpoint information is therefore complete and compatible with the commercial object, and it does not require additional intervention by a programmer or programming tools. In addition, since the endpoint is generated when the business object is created or requested, the endpoint may allow integration with new environments that did not exist when the business object was designed.

In one embodiment, a business object may be periodically updated to create new versions. With static contracts, each new version of the business object would require a contract update on the server so that customers could consume the business object. Otherwise, the contract (or endpoint information) becomes stale and the customer no longer has the most recent or accurate contract to consume the business object. This problem is avoided in the present system by the use of dynamically generated contracts. Since this system uses dynamic contracts, the contract is never out of date. If the business objects are changed, the contract is automatically modified or updated. The consumer client device continues to point to the only known entity, i.e., the dynamic endpoint, and the dynamic endpoint updates the information and knowledge about the objects business processes and system resources. The dynamic endpoint continues to generate contracts for other objects in the system even when new objects are added or when existing objects are changed.

In one embodiment, the earlier versions of the endpoints are updated even when new endpoints are generated. This can be useful when a client device chooses or requires the use of a specific version of a contract or endpoint, even after a new contract or point is generated. end.

In one embodiment, the server constructs and publishes contracts for all objects that are updated or stored on the server. In one embodiment, the server constructs and publishes contracts for only a subset of the business objects stored on the server by excluding some of the business objects. The subset can be determined based on configuration criteria.

Alternatively, the criteria can be determined at the same time that the server builds and publishes contracts. This allows a user to exercise granular control over the dynamic nature of the system.

For example, the dynamic endpoint generator can implement a category system. In one embodiment, each object has a single endpoint. In one embodiment, each business object is placed in a category, and each category has a single endpoint. When multiple business objects share the same category (and therefore the same endpoint), these business objects can be selected or deselected by the dynamic endpoint generator. This allows a user to dynamically update only certain categories of business objects.

For example, a user working on a project can place all business objects related to that project into a category. The user can select only this category (and therefore the endpoint) and the dynamic endpoint generator dynamically updates the contracts for business objects belonging to this category. Other business objects in other categories are excluded by the dynamic endpoint generator, which reduces the number of business objects that are dynamically updated and decreases the memory usage, the refresh time and the startup time. Users can create subcategories and choose to dynamically generate contracts for objects belonging to certain subcategories. Users can accurately control the business objects that need to be dynamically updated.

Fig. 12 is a screenshot of an embodiment of a system 1600 implementing a dynamic endpoint generator 1602 to enable a commercial object application 1604 to consume commercial objects. Various business objects are stored on a business object server 1606. For example, the business object server 1606 contains a client business object 1608, a business object of area 1610, a business object of product 1612, a business object of 1614 and other commercial objects 1616. The business objects communicate with the business object data source 1618. In one embodiment, the system generates an endpoint when the business object is created.

In one embodiment, the system has not generated contracts for commercial objects and generates only endpoints when the business objects are requested. For example, an organization may need to store the first name, last name, and social security number of its customers. A user specifies his fields when defining the client business object 1608. The business object application 1604 may need to interact with the client business object 1608. For example, the object application 1604 wants to create a new client by using the 1608 client business object. However, the 1604 business object application does not have endpoint information for the 1608 client business object. of business object 1604 requests or wishes to consume the client business object 1608, it sends a request to the dynamic endpoint generator 1602. The dynamic endpoint generator 1602 automatically builds and publishes information endpoint, including a data contract, for the 1608 client business object. The 1604 business object application can then consume the 1608 client business object if the 1608 client business object did not previously have an endpoint. In one embodiment, the dynamic endpoint generator 1602 generates an endpoint when a business object is created.

In one embodiment, after the business object application 1604 consumes the client business object 1608, the definition of the client business object 1608 is changed. For example, the organization may now require the storage of its customers' addresses in addition to the first name, last name, and social security number of its customers. The address information can be retrieved from a database other than the databases containing the first name, the last name and the social security number. A user modifies the 1608 client business object definition. When the 1608 client business object is updated, the new 1608 client business object property is republished and the 1602 dynamic endpoint generator is re-published. is automatically notified of the change of the client business object 1608. The dynamic endpoint generator 1602 updates its own information and publishes an updated endpoint for the client business object 1608. From in this manner, the business object application 1604 still has the most up-to-date endpoint information for the client business object 1608.

In one embodiment, the business objects are exposed to a client device through a Web infrastructure such as WCF (Windows Communication Foundation), which is part of the .NET framework. The client device can use standard WCF mechanisms. In one example, the contract or endpoint is generated in a declarative format. The declarative format can be XML. In one embodiment, the contracts are published as standard Web Service Definition Language (WSDL) templates. Endpoints or contracts can also be published using Representational State Transfer (REST), for example by implementing XML, Atom (Atom Syndication Format and / or Publishing Protocol), or JSON (JavaScript Object Notation). Endpoints may include support for Secure Sockets Layer (SSL) or Transport Layer Security (TSL).

Figure 13 is a flowchart illustrating an exemplary 1700 process of generating, deploying, and publishing a business object, automatically generating a dynamic endpoint for the business object and allowing a client device to consume the business object. business object using the dynamic endpoint. Preferably, the process 1700 is performed in one or more software programs stored in one or more memories and executed by one or more processors. For example, the process 1700 may be a JavaScript code (or any other type of software) running on a client device 102. Although the process 1700 is described with reference to the flowchart shown in FIG. 13, it should be appreciated that many other methods can be used to perform the actions associated with the 1700 process. For example, the order of many steps can be changed, and some of the steps described may be optional. Similarly, some steps can be combined in one step.

In general, a new business object is created, the dynamic endpoint generator automatically generates endpoint information for the business object, and a client device can consume the business object without the need to manually generate a contract or other endpoint information, such as a contract, for the business purpose.

Specifically, a design tool can be used to create a new product business object, and the business object is then deployed and published to a 192.168.1.38:7 server. A dynamic endpoint "http://dix.denallix.com:8000/Demo" for the business object is generated. A Remote ProductsSvcClient client device can communicate with the endpoint so that the endpoint provides link information, metadata, data, and method contracts to the client device. The client device can use methods like ProductsSvc_Create, ProductsSvc_Save, ProductsSvc_Delete,

ProductsSvc_Load, and ProductsSvc_GetList, that can be associated with the product business object. The ProductsSvcClient client device consumes the product business object and, using one or all of the methods, creates ACME Widgets and ACME Gadgets product records. The user can use a 1800 design tool to create a new business object. The tool includes 1802 templates for creating projects, processes, or business objects. If the user wishes to create a new blank business object, the user selects the business object model 1804. The user can also access other recently used business objects and reuse them as Client 1806 and Employee 1808. Then , the user presses the Create button to create the new business object called 1810 Products.

Each business object is usually associated with properties and methods. In one example, the product business object 1810 has five default methods 1902 that the user can call when using the product business object 1810. The methods are part of a SmartBox service 1904 which is the disposition of the user. Other services may also be available to the user, and the user may use and combine services from multiple sources. The new 1810 business object does not have an associated 1906 property yet. The user can add properties that define the business object. The business object of product 1810 can be defined by the properties of product identifier 2002, name 2004 and category 2006. Other properties can also be made available to the user, and the user can use and combine properties from multiple sources. The 2002 product identifier is listed as the primary property because the product identifier value is unique for each product. Once methods 1902 and 1906 properties of the product business object are defined, business object 1810 can be deployed to a server.

Once a business object is deployed, it must be published. Publishing a business object allows customers who may wish to use the business object to discover it. Once the business object is made available on the server, a dynamic endpoint is automatically generated so that a customer can consume the business object.

In one embodiment, the user may be able to configure various endpoint parameters, such as if an endpoint is enabled for a business object, if the business object is not allowed to have endpoints, if isolation is used for the endpoint, and if custom links are used for the endpoint.

Fig. 14 illustrates an exemplary flow chart 2300 of endpoint information configuration for a commercial object in response to the creation and publication of a commercial object. A SmartObject business object is published in step 2302. The dynamic endpoint generator checks to see if endpoints are enabled in the configuration criteria in step 2304. If endpoints are enabled in the configuration criteria in step 2304. are not enabled, an endpoint is not created, as shown in step 2306. If endpoints are enabled, the dynamic endpoint generator checks whether the business object is is not allowed to be part of a server refresh or to have endpoints created, as shown in step 2308. If the business object is not allowed, an endpoint is not created, as shown in step 2310. If the business object is authorized, the dynamic endpoint generator proceeds to create an endpoint for the business object in step 2312.

To generate an endpoint, the dynamic endpoint generator, in one embodiment, loads the business object definition and maps the data types to data types supported by endpoint in step 2314. In step 2316, the dynamic endpoint generator generates data contracts for each type of commercial object data. In step 2318, the dynamic endpoint generator generates contracts and / or operating links for each business object method. In step 2320, the dynamic endpoint generator generates a service contract for each category in the category system. For example, the dynamic endpoint generator generates endpoints not only for the business object published in step 2302, but also for all business objects belonging to the same category as the business object or for all categories recognized by the dynamic endpoint generator. In step 2322, a user can configure whether an isolation should be used for the endpoint. If no isolation is to be used, then the shared memory / application domain is unloaded in step 2324.

A user can configure whether custom links should be used in step 2326. If custom links are to be used, then an endpoint is created in shared memory with custom security bindings in step 2328. no custom link should be used, so an endpoint is created in shared memory with shared security links in step 2330.

If isolation is to be used in step 2322, then an isolated memory / application domain is created in step 2332. In step 2338, a user can configure whether custom links should be used. If custom links are to be used, then an endpoint is created in the isolated memory with custom security bindings in step 2336. If no custom bindings are to be used, then an endpoint is created in the isolated memory with shared security links in step 2338.

The configuration criteria can be predetermined or can be specified when creating the endpoint. The configuration can be performed at various different levels. For example, a user may be able to perform configuration at the service level, at a WCF / REST protocol level, or at a managed level. By using these three levels of configuration, a user can granularly control exactly where and how an endpoint is generated.

The service configuration controls the default functionality of services, such as whether services are enabled to work or not, or whether the endpoint generator looks for certain events such as the creation of a new business object. The WCF / REST configuration allows a user to override the default services capability and specify an endpoint address per endpoint type, for example WCF or REST.

Table 1, in the appendix at the end of the description, shows an example of an exemplary code for a default configuration with activated endpoints.

A managed endpoint configuration allows a user not only to specify a stub endpoint for a specific business object or category of business objects, but also to generate an isolated endpoint with its own address. Without the managed endpoint configuration, all endpoints generated would be stored at a single address, for example http: //dix.denallix.corn: 8000 / Demo, and the location of each business object would be appended at this address. With the managed endpoint configuration, a user can specify addresses for certain endpoints, allowing such endpoints to be isolated.

An endpoint can be isolated in at least three ways: when it is stored in a different memory space from other endpoints, when it is located at a Uniform Resource Identifier (URI) different from other endpoint, and when the security links are different at the WCF / REST protocol level. Endpoint isolation in a different memory space allows for a security boundary around critical endpoints, and also allows for individual refresh or not refresh of isolated endpoints when other endpoints are updated. Endpoint isolation for not updating may be useful when the associated object is frequently changed. Similarly, a user may wish to refresh only a specific endpoint, which may be the case when associated objects are being developed or implemented. In one embodiment, only one endpoint is isolated for dynamic generation.

A second type of isolation made possible by a managed endpoint configuration is URI isolation, which isolates access to an endpoint. For example, a user may be able to host all the public endpoints of a common URI, but to host some private endpoints to a different URI. To access these private endpoints, a client device must know the specific URI. Thus, discovery and access to endpoints can be isolated.

A third type of isolation made possible by a managed endpoint configuration is security link isolation, which isolates access to an endpoint based on the link configuration. For example, a user may be able to host all public WCF and REST endpoints using a common security binding for the WCF and REST protocols, but to host some private endpoints using a configuration unique security binding for WCF or REST protocols.

In one embodiment, the various levels of configuration settings allow the inheritance of configuration parameters. In one embodiment, the service configuration overrides the default settings, the WCF / REST configuration overrides the service configuration settings (so that the user can configure all endpoints corresponding to endpoints of WCF / REST type), and the managed endpoint configuration overrides the WCF / REST configuration settings (so that the user can configure individual business objects or business object categories). Each subsequent configuration level, ranging from service configuration to WCF / REST configuration and managed endpoint configuration, applies stronger logic that increases endpoint conditions as you go along. of their generation.

Table 2, in anexe at the end of the description, shows an example of an exemplary pseudo code for setting configuration options in one embodiment.

Table 3, at the end of the description, illustrates an example of using endpoint configuration options, in which WCF endpoints inherit a default service level configuration. REST endpoints override the default service level configuration, and managed endpoints also override the default service level configuration.

In one embodiment, the dynamic endpoint generator automatically generates an endpoint for a commercial object as soon as the business object is created. The dynamic endpoint generator loads a definition of the business object and iterates through the definition. The business object definition can include properties and methods. The object definition is mapped to each supported endpoint type, such as WCF or REST, properties are mapped to data contracts, and methods are mapped to operation contracts. The methods can have signatures that describe the method. For example, method signatures can define a minimum set of information needed for a method to work properly, such as the input and output data types of a method.

The dynamic endpoint generator ensures that the signatures for the business object methods contain inputs and outputs that are supported by each endpoint type. If this is not the case, the dynamic endpoint generator creates such signatures for each business object method.

In one embodiment, any business resource may be made available to a customer via a dynamic endpoint. For example, business objects, processes, or worklists can be exposed through a dynamic endpoint.

By using the disclosed systems, developers have instant, platform-independent, dynamic access to any business object. In one embodiment, standardized back-end systems such as SAP, Siebel, Oracle DB, Oracle EBS, and SQL are exposed through the dynamic endpoint. In one embodiment, proprietary back-end systems may be exposed, for example using adapters. Adapters make it easy to expose objects that are stored on proprietary systems.

In summary, those skilled in the art may realize that methods and apparatus for dynamically generating, discovering, accessing, and consuming business objects have been disclosed. The foregoing description has been presented for purposes of illustration and description.

It is not intended to be exhaustive or to limit the invention to the disclosed exemplary embodiments. Many modifications and variations can be made in the light of the above-mentioned lessons. It is intended that the scope of the invention is not limited by this detailed description of examples, but that it is limited by the appended claims. TABLE 1 <smoServices enableEndpoints = "true" enableEvents = "true" enableCrossDomainPolicy = "true" enableMetadata = "true" scheme-'http "server =" api.denallix.com "port =" 8888 "serviceRoot =" SmartObjectServices "specialCharacterReplacement = "_" defau! tSecurityLabel = "K2" individualSmartObjects = "true"> <wcf binding = "wsHttpBinding" bindingConfiguration = "wsHttpBinding + Windows" /> <rest binding = "webHttpBinding" bindingConfiguration = "webHttpBinding + Windows" /> <managedEndpoints > <excluded garlic = "false" /> </ managedEndpoints> </ smoServices> <system.serviceModel> <bindings> <basicHttpBind ing> <binding name = "basicHttpBinding + Windows + HTTPS"> <security mode = "Transport"> "Transport clientCredentialT ype =" Wi ndows "/> </ security> </ binding>" binding name = "basicHttpBinding + Basic + HTTPS"> "security mode =" Transport ">" transport clientCredentialType-'Basic "/>" / security> </ binding> "binding name =" basicHttpBinding + Windows ">" security mode = "TransportCredentialOnly"> "transport clientCredentialT yp e = "Wi ndows" /> </ security> </ binding> "binding name =" basicHttpBinding + Basic ">" security mode = "TransportCredentialOnly"> "transport clientCredentialType =" Basic "/>" / security> </ binding > "/ BasicHttpBinding> <wsHttpBinding>" binding name = "wsHttpBinding + Windows"> "security mode =" Message "/>" / binding> "binding name =" wsHttpBinding + TWMC + HTTPS ">" security mode = "T ransportWithlVlessageCredential ">" ClientCredentialType = "Windows" message> </ security> </ binding> "binding name =" wsHttpBindIng + HTTPS ">" security mode = "Transport"> "transport clientCredentialType =" Wi ndows "/> </ security </ binding> </ wsHttpBinding> <webHttpBinding> "binding name =" webHttpBinding + Basic ">" security mode = "T ransportCredentialOnly"> "transport clientCredentialType =" Basic "/> </ security> </ binding>" binding name = "webHttpBinding + Windows"> <security mode = TransportCredentiaIOnly ">" transport clientCredentialType = MWindows "/> </ security> </ binding>" binding name = "webHttpBinding + Basic + HTTPS"> " security mode = 'Transport'> 'transport clientCredentialType-'Basic "/> </ security>" / binding> "binding name-'webHttpBinding + Windows + HTTPS"> "security mode = Transport"> "transport clienîCredentialType-'Windows" /> </ security> </ binding> "/ webHttpBind i ng> </ bindings>" / system .serviceMode 1> TABLE 2

Services • enableEndpoints (Boolean) - determines whether the SmartObject Services K2 service will start o True - starts SmartObject Services K2 and loads configured endpoints o False (default / omitted) - does not start SmartObject Services K2 and does not load endpoints • enableEvents (Boolean) - determines whether changes to SmartObjects will be reflected dynamically without restarting the K2 server o True (default / omitted) - when Smart Objects are created / updated / deleted, the service dynamically reloads the AppDomain (Application Domain) containing the assigned Smart Objects o False - when Smart Objects are created / updated / deleted, the service will not reflect the changes without restarting the K2 server. • enableCrossDomainPolicy (Boolean) - determines whether service endpoints have inter-domain support o True - allows inter-domain support for browser-based applications, such as Silverlight, to make calls to the service endpoint from a different domain • Files - The files that control the cross-domain support level are crossdomain.xml and clientaccesspolicy.xml. These files can be found and edited in the DirectoryjlHost Server \ Bin \ SmOServices directory. • NOTE: The server value must be a fully qualified DNS name or machine name for cross-domain support to work properly. o False (default / omitted) - Disables cross-domain support which removes the ability for browser-based applications, such as Silverlight, to make calls to the service endpoint from a different domain • enableMetadata (Boolean) - determines whether a Service Metadata Document (aka, WSDL) will be generated for the endpoint via? wsdl o True (default / omitted) - a Service Metadata Document will be created for the endpoint o False - a Service Metadata Document will not be created for the system • endpoint (String, required) - the default system (http or https if SSL is enabled) for endpoints. o Default: http • server (String) - the DNS name or fully qualified domain name of the server hosting the endpoints o Default: (Full Machine Name) • port (string) - the default port for endpoints o Default: 8888 o Omitted: 80 • serviceRoot (string) - default service root for endpoints o Default: SmartObjectServices • specialCharacterReplacement (string) -allows administrators to control which character is used instead of unauthorized generated characters such as spaces o Default / Omitted: • defaultSecurityLabel (string) - sets the default security label to be added, in advance, to the user's name for basic authentication processes o Default: K2 o Omitted: no security label will not be installed beforehand, the name of the user must also contain the label

WCF

The <wcf> section contains the default binding configuration for optional WCF endpoints and WCF specific Service URIs.

• binding (string, required) - defines the default binding type for the WCF endpoint o Support for basicHttpBinding, wsHttpBinding o Default: wsHttpBinding • bindingConfiguration (string, required) - defines the configuration in the <system.serviceModel> section that contains the binding details for the endpoint o Default: wsHttpBinding + Windows • bindingConfiguration (string, required) - sets the configuration in the <section system.serviceModel> which contains the details of the binding for the endpoint • scheme (system) - if present, overwrites the system by default and requires a server • server (Server) - if present, overwrites the default server and requires a system • port (String) - if present, overrides the default port • serviceRoot (String) - if present, overwrites l a default service root • defaultSecurityLabel (String) - if present, overwrites the default security label • individualSmartObjects (Boolean) - if present, will generate an endpoint for each individual Intelligent Object in addition to the category-level endpoint o Default: false

REST

The <wcf> section contains the default binding configuration for optional REST endpoints and REST Service URIs.

• binding (string, required) - defines the default binding type for the REST endpoint o Support for webHttpBinding o Default: webHttpBinding • bindingConfiguration (string, required) - defines the configuration in the <system.serviceModel> section that contains the binding details for the endpoint o Default: webHttpBinding + Windows • scheme (system) - if present, overrides the default system and requires a server • server (Server) - if present, overwrites the default server and requires a system • port (String) - if present, overrides the default port • serviceRoot (String) - if present, overwrites the default service root • defaultSecurityLabel (String) - if present, overrides the default security label

Managed endpoints

The category is the top-level default object that is linked to the endpoint through the URI. For example, if a category or Intelligent Object exists at the same level, the endpoint will be linked to the category. In addition to the default binding of Intelligent Object processes within a category endpoint, Intelligent Objects can be configured to also have their own endpoints (direct URI navigation to Intelligent Object) . If a category and an Intelligent Object are found to have the same endpoint, the category wins and will be linked to the endpoint and an error will be logged for the collision.

Endpoint Management allows the administrator to control which categories and Smart Objects are available through the WCF and REST services. There are two main sections: Excluded and Static. • Excluded means that Category Path and Smart Objects in this category are excluded. Each sub-category is not automatically excluded and will require a separate entry. • Static means that the specific category and, depending on the scenario, a specific Intelligent Object, is included.

excluded

Configures excluded endpoints to prevent an endpoint of a category or subcategory, and Intelligent Object processes in that category / subcategory, from being generated. • gar (all) (Boolean, required) - determines whether all categories will be excluded o True (default) - excludes all categories of endpoint generation. This allows only static endpoints to be available. o False - generates endpoints for all non-explicitly excluded categories • The <endpoints> section contains an <endpoint> for each category path to explicitly exclude o categoryPath (String, required) - path to Category / Subcategory • Example 1: Excludes the Task Allocation category from endpoint generation. All subcategories would still be included. <endpoint categoryPath-'Task Allocation "!> • Example 2: Excludes the Workflow Reports / Workflow General sub-category from the endpoint generation, the parent category, Feed Reports, and all subcategories will always be included. <endpoint categoryPath = "Workflow Reports / General Workflow"! o excludeSubCategories (Exclude Subcategories) (Boolean, optional) - path to category / subcategory • True - excludes parent category and all subcategories of endpoint generation • False (default) - generates endpoints for all subcategories not explicitly excluded • Example 1: Excludes the category Task Allocation and all its subcategories of endpoint generation. <endpoint categoryPath & 'Task Allocation "excludeSubCategories" true "!>

Static

Configures static endpoints to allow an injection of an Intelligent Object to an endpoint, the URI designation of the Intelligent Object, the creation of a custom Application Domain, the modification of the Intelligent Object URI default binding type and selection of the definition version of a specific Intelligent Object • categoryPath (Path to Categories) (String, required) - path to category / subcategory o Example 1: All Smart Objects included in a category. <endpoint categoryPath-'MyCategoryfMyProject "!> o When specified without a specific Intelligent Object name in the smartobjectName (Intelligent Object Name) attribute or individualSmartObjects = true (Individual Intelligent Objects = true), then all Intelligent Objects in this category path will be generated, and if a specified category path does not exist, it will be monitored so that when an Intelligent Object is deployed on that category path at a later stage, then the point of endpoint will be generated • smartobjectName (string, optional) - the name of the specific Intelligent Object o specified (specified) - if specified, the Intelligent Object will have an endpoint generated o missing - if not specified, all Smart Objects on the path of the specified category will be generated • alias (string, optional) - the new path to be used to navigate to the endpoint for this Intelligent Object or Category. NOTE: The path search will use the screen name while the generated link will always use the system name. o If there is a collision with an existing Category or Intelligent Object, it is the latter that wins. For example, if you configure two static endpoints with exactly the same alias, the second one in the list will overwrite the first, and there will be only one endpoint, o Example: alias-'MySmartObjectAlias " will generate an Intelligent Object endpoint binding on http://api.denallix.com:8888/SmartObjectServices/MySmartObject • isolationLevel (string, optional) - used to specify the Domain. Application that the endpoint should use o Shared - (default / omitted) - By default, all endpoints will use a single Application Domain Do not set the isolation level or specify the Isolation level-'shared 'has the same effect which is to use the Service Application Scope. • single - setting the -unique "isolation level will ensure that the endpoint for this Intelligent Object has its own Application Domain, which allows isolation of all other endpoints. useful when the Smart Object changes often, while the endpoint recharge will not affect another endpoint • smartobjectVersion (optional Smart Object Version) - used to specify a specific version of the Intelligent Object definition to bind to the endpoint The most recent version of the Intelligent Object definition will be linked by default o Example: 5 • The <wcf> or <rest> section, if it exists, overwrites the WCF and / or REST configuration for the service for that static endpoint.

o binding (string) - if it exists, overrides the default binding type configured for the WCF or REST service

Support for basicHttpBinding, wsHttpBinding, webHttpBinding

o bindingConfiguration (string) - if it exists, overwrites the default binding configuration for the WCF / REST service o scheme (system) - if present, overrides the default system and requires an o server (server) server (String) - if present, overwrites the default server and requires a system o port (String) - if present, overwrites the default port o serviceRoot (Service Root ) (String) - if present, overwrites the default service root o defaultSecurityLabel (String) - if present, overwrites the default security label o individualSmartObjects (Individual Intelligent Objects ) (Boolean) - if present, will generate an endpoint for each individual Intelligent Object in addition to the category-level endpoint • Default: false TABLE 3 <smoServices enableEndpoints = "true" enableEvents = "true" enableCr ossDomainPolicy = "false" enableMetadata = "true" scheme-'http "server =" api.denallix.com "port =" 8888 "serviceRoot =" SmartObjectServices "specialCharacterRepIocation =" _ "defaultSecurityLabel =" K2 "> <wcf binding =" basicHttpBinding + Basic "bindingConfiguration =" wsHttpBinding + Basic "defaultSecurityLabel-'K2SQL" /> <rest birtding-'webHttpBinding "bindingConfiguration-'webHttpBinding + Windows + HTTPS" scheme = "https" server-'api.denallix.com "port = "8890" serviceRoot = "SmartObjectServices" /> <managedEndpoints "<excluded all =" false "> <endpoints> <endpoint categoryPath-'Task Allocation" excludeSubCategories = "true" /> <endpoint categoryPath = "Workflow Reports / Workflow General" / »</ Endpoints> </ excluded> <static> <endpoints <endpoint categoryPath =" K2 Examples / Employee "" <binding = "webHttpBinding" bindingConfiguration-'webHttpBinding + Windows "scheme =" http "server =" denallix .denallix.com "port =" 8889 "serviceRoot =" SmartObjects "defaultSecurityLabel-'K2SQL" / "</ endpoint" </ endpoints> </ static> </ ma nagedEndpoints> </ smoServices>

Claims (7)

A dynamic endpoint generation system for enabling a client device to consume a commercial object, the endpoint including an address, a link, and a contract, comprising a structured processor for causing the system to perform: loading a definition of the business object, the definition including properties and methods; performing an iteration through the definition; and mapping the definition to protocols supported by the endpoint, the mapping comprising: (i) mapping the commercial object properties to data contracts; (ii) the mapping of business object methods to operating contracts; and (iü) verifying that commercial object method signatures include inputs and outputs supported by the endpoint; wherein the endpoint is generated in response to at least one of: (a) the request for the business object by the client device, (b) the creation of the business object, and (c) the update of the commercial object. The system of claim 1, wherein the processor is structured to further cause the system to perform the generation of .NET endpoints for use in a WCF framework and the generation of Atom, XML and JSON endpoints. intended for use in a REST framework. 3. The system of claim 1, wherein the business object belongs to a category, and the endpoint is generated for the category. The system of claim 1, the processor being structured to further cause the system to perform endpoint generation based on a configuration. The system of claim 4, wherein the configuration comprises the service configuration, the WCF configuration, the REST configuration, and the managed configuration. The system of claim 5, wherein the isolation comprises at least one of: (i) memory isolation, (ii) address isolation and (iii) security link isolation . 7. Computer-readable medium storing instructions for generating a dynamic endpoint allowing a client device to consume a commercial object, the endpoint including an address, a link, and a contract, the instructions providing a device computer to perform: the loading of a definition of the commercial object, the definition including properties and methods; performing an iteration through the definition; and mapping the definition to protocols supported by the endpoint, the mapping comprising: (i) mapping the commercial object properties to data contracts; (ii) the mapping of business object methods to operating contracts; and (iii) verifying that business object method signatures include inputs and outputs supported by the endpoint; wherein the endpoint is generated in response to at least one of: (a) the request for the business object by the client device, (b) the creation of the business object, and (c) the update of the commercial object.