US20030233401A1 | 2003-12-18 | |||
US20140244351A1 | 2014-08-28 | |||
US20140229628A1 | 2014-08-14 |
WHAT IS CLAIMED IS: 1. A system for integrating an application with a plurality of persistence systems, comprising: a processor; and a memory comprising instructions configured to cause the processor to: receive, from a client, a request for access to an application, the application developed for a first persistent system, the application operational on a platform, the platform providing functionality of the first application for information on the first persistent system and information on a second persistent system; provide, to the client, instructions that when implemented cause a user interface to be dynamically generated in a browser of the client, the user interface for using the application; and provide a data model to translate input from and output to the user interface for use by the application. 2. The system of claim 1, wherein the first persistent system is an enterprise database and the application is an on-premises third-party application. 3. The system of claim 1, wherein the second persistent system is a cloud-based system and the application is a cloud-based third-party application. 4. The system of claim 1, wherein providing the data model comprises defining an entity class and providing a first mapping to an object of the first persistence system and a second mapping to an object of the second persistence system. 5. The system of claim 1, wherein the processor is further configured to receive a request from the user interface to perform a persistence operation against an object of the first persistence system and an object of the second persistent system. 6. The system of claim 5, wherein the persistence operation is one from the group of create, read, update, delete, bulk save, and bulk delete. 7. The system of claim 4 wherein the processor is further configured to associate the entity class with a query and the query is declarative. 8. The system of claim 7, wherein the query adheres to an agnostic schema of the first or the second persistent system. 9. The system of claim 1, wherein the data model includes an agnostic schema for the first or the second persistent system. 10. A computer-implemented method for integrating an application with a plurality of persistence systems, comprising: receiving, from a client, a request for access to an application, the application developed for a first persistent system, the application operational on a platform, the platform providing functionality of the first application for information on the first persistent system and information on a second persistent system; providing, to the client, instructions that when implemented cause a user interface to be dynamically generated in a browser of the client, the user interface for using the application; and providing a data model to translate input from and output to the user interface for use by the application. 1 1. The method of claim 10, wherein the first persistent system is an enterprise database and the application is an on-premises third-party application. 12. The method of claim 10, wherein the second persistent system is a cloud- based system and the application is a cloud-based third-party application. 13. The method of claim 10, wherein providing the data model comprises defining an entity class and providing a first mapping to an object of the first persistence system and a second mapping to an object of the second persistence system. 14. The method of claim 10, further comprising receiving a request from the user interface to perform a persistence operation against an object of the first persistence system and an object of the second persistent system. 15. The method of claim 14, wherein the persistence operation is one from the group of create, read, update, delete, bulk save, and bulk delete. 16. The method of claim 13, further comprising associating the entity class with a query and the query is declarative. 17. The system of claim 16, wherein the query adheres to an agnostic schema of the first or the second persistent system. 18. The system of claim 10, wherein the data model includes an agnostic schema for the first or the second persistent system. |
HETEROGENEOUS PERSISTENCE SYSTEMS
CROSS -REFERENCE TO A RELATED APPLICATION [0001] This application claims the benefit under 35 U.S.C. § 1 19(e) of U.S.
Provisional Patent Application No. 62/204,657, entitled "Keystone Configurable
Development Platform Including Configurable Price Quote Application," filed August 13, 2015, the entire content of which is incorporated by reference in its entirety. BACKGROUND
1. Field of the Invention
[0002] The specification generally relates to a system and method for facilitating rapid application development that integrates with multiple persistent systems. In particular, the specification relates to a system and method for simultaneously performing access and operations against multiple, heterogeneous persistence systems within the same application.
2. Description of the Background Art
[0003] For many years there have been large enterprise computing systems to run databases and related applications for a variety of functions including accounting, inventory, customer relationship management, etc. These systems are very expensive, required custom coding, and require significant support and infrastructure. In order to address these problems, a number of applications are now being offer on cloud based systems (e.g., a type of Internet- based computing that provides shared computer processing resources and data to computers and other devices on demand) where the cost, support and infrastructure can be distributed over many users making it more accessible for everyone. However, this has created a problem where the needed data is distributed over the different systems, sometimes with some stored at the enterprise while other data is in the cloud. Similarly, there are application that are only operational on the enterprise and not on the cloud, and vice versa. This has led to companies having to duplicate systems and a fracturing of the data and how it can be used. SUMMARY
[0004] The techniques introduced herein overcome the deficiencies and limitations of the prior art, at least in part, with a system and method for simultaneously performing access and operations against multiple, heterogeneous persistence systems within the same application.
[0005] According to one aspect of the subject matter described in this disclosure, a system for integrating an application with a plurality of persistence systems, includes a processor; and a memory comprising instructions configured to cause the processor to:
receive, from a client, a request for access to an application, the application developed for a first persistent system, the application operational on a platform, the platform providing functionality of the first application for information on the first persistent system and information on a second persistent system; provide, to the client, instructions that when implemented cause a user interface to be dynamically generated in a browser of the client, the user interface for using the application; and provide a data model to translate input from and output to the user interface for use by the application.
[0006] In general, another aspect of the subject matter described in this disclosure includes a method that includes receiving, from a client, a request for access to an application, the application developed for a first persistent system, the application operational on a platform, the platform providing functionality of the first application for information on the first persistent system and information on a second persistent system; providing, to the client, instructions that when implemented cause a user interface to be dynamically generated in a browser of the client, the user interface for using the application; and providing a data model to translate input from and output to the user interface for use by the application.
[0007] Other implementations of one or more of these aspects include corresponding systems, apparatus, and computer programs, configured to perform the actions of the methods, encoded on computer storage devices.
[0008] These and other implementations may each optionally include one or more of the following features. For instance, the first persistent system is an enterprise database and the application is an on-premises third-party application; the second persistent system is a cloud-based system and the application is a cloud-based third-party application; and wherein providing the data model comprises defining an entity class and providing a first mapping to an object of the first persistence system and a second mapping to an object of the second persistence system. Additionally, the system or method may receive a request from the user interface to perform a persistence operation against an object of the first persistence system and an object of the second persistent system; or may associate the entity class with a query and the query is declarative. Additional features may include that the persistence operation is one from the group of create, read, update, delete, bulk save, and bulk delete; that the query adheres to an agnostic schema of the second persistent system; or that the data model includes an agnostic schema for the second persistent system.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] The techniques introduced herein are illustrated by way of example, and not by way of limitation in the figures of the accompanying drawings in which like reference numerals are used to refer to similar elements.
[0010] Figure 1 is a high-level block diagram of an embodiment of an example system including a development platform for integrating with multiple, heterogeneous persistent systems.
[0011] Figure 2 is a block diagram of an embodiment of a computing device including a development platform for integrating with multiple, heterogeneous persistent systems.
[0012] Figure 3 is a block diagram of an embodiment of components of a web engine for generating a user interface for an application deployed by a development platform.
[0013] Figure 4 is a block diagram of an embodiment of an object relational mapping
(ORM) engine for providing persistence services against one or more third-party applications.
[0014] Figure 5 is a block diagram of an embodiment of a core engine for providing system functionality for the development platform.
[0015] Figures 6A-6C are block diagrams of embodiments of components provided by the web engine for generating a user interface for the application deployed by the development platform.
[0016] Figure 7 is a block diagram of an embodiment of a providers and executors module for providing provider and executor objects utilized in the development platform.
[0017] Figure 8 is a block diagram of an embodiment of a data provider type class of objects and executor type class of objects including in the providers and executors module of the development platform. [0018] Figure 9 is a sequence diagram for execution of a non-paged query against a third-party application platform, according to one embodiment of the disclosed technologies.
[0019] Figures 10A-10B are sequence diagrams for execution of a paged query against a third-party application platform, according to one embodiment of the disclosed technologies.
[0020] Figure 11 is a sequence diagram for execution of a basic, single-entity record create operation against a third-party application platform, according to one embodiment of the disclosed technologies.
[0021] Figure 12 is a sequence diagram for execution of a basic, single-entity record update operation against a third-party application platform, according to one embodiment of the disclosed technologies.
[0022] Figure 13 is a sequence diagram for execution of a basic, single-entity record delete operation against a third-party application platform, according to one embodiment of the disclosed technologies.
[0023] Figures 14A-14B are sequence diagrams for execution of a mixed mode
(create, update, delete combined in a single batch) bulk save operation, according to one embodiment of the disclosed technologies.
[0024] Figure 15 is a block diagram of an embodiment of a configuration engine for informing the development platform about an application deployed on the development platform, and includes metadata about the application.
[0025] Figure 16 is a sequence diagram for generating a user interface, including set up of page navigation components, according to one embodiment of the disclosed technologies.
[0026] Figures 17A-17B are sequence diagrams for generating a user interface, including rendering a page when a user accesses the page for the first time, according to one embodiment of the disclosed technologies.
[0027] Figure 18 is a block diagram of an embodiment of a rules engine for defining conditions that may be evaluated against objects.
[0028] Figure 19 is a sequence diagram for generation of condition evaluators and an evaluation of a condition, according to one embodiment of the disclosed technologies.
[0029] Figure 20 is a sequence diagram for creation and retrieval of a rule set, validating a rule set and saving a rule set, according to one embodiment of the disclosed technologies. [0030] Figure 21 is a graphic representation of an embodiment of a user interface illustrating an example page layout and high-level configurable user interface elements.
[0031] Figure 22 is a graphic representation of an embodiment of a user interface illustrating an example navigation panel and container level configurable user interface elements.
DETAILED DESCRIPTION
[0032] The development platform 108 is a configurable development platform intended to facilitate rapid application development that integrates with third-party applications (optionally operating on other systems) 190 and 192, for example Customer Relationship Management (CRM) software such as Microsoft Dynamics CRM and
Salesforce. The term persistence system may also be used within this Specification to refer to either of the above mentioned third-party applications/platforms, another third-party application platform, an enterprise database, or a cloud-based application or system. Given a single data model used by development platform 108, virtually no code changes are required to port an application, for example, a Configure, Price, and Quote (CPQ) application, developed for one persistence system, e.g. Salesforce platform, to another heterogeneous persistence system, e.g. Microsoft Dynamics CRM platform, and vice-versa. The development platform 108 provides a well-defined application programming interface (API) with predictable behavior for an application to interact with the development platform, enabling application developers to focus on implementing business functionality instead of focusing on system functionality which is essential to any robust, scalable, perfbrmant and secure enterprise web-enabled application.
[0033] In one embodiment, development platform 108 includes several components or modules including a Core engine 1 10, a Web engine 120, Providers and Executors module 130, Administration (Admin) module 150, a Rules engine 160, an Object Relational Mapping engine 170, and a Configuration module 180. The arrows in Figure 1 indicate the direction of the dependency of the modules and points away from the user of the module. An application deployed on the platform, e.g. enterprise solution Response CPQ, formerly Atlas CPQ application, has two modules shown in dash-outlined boxes, namely Application Provider module 140 and Application Web module 124, which are not a part of the development platform 108. The dependency between the Providers and Executors module 130 and the Application Provider module 140 is bidirectional. Further, calls into the Application Providers module 140 - shown as a dotted arrow - are executed via references obtained using reflection, a feature of all modern programming languages. This approach prevents a circular dependency from occurring between the two modules. The Application Web module 124, the second piece of an application deployed on the platform lives within the Web Engine 120. Each of the modules and the services it provides transition from initialization, active and shutdown phases. In the initialization phase, services acquire the resources needed to operate. In the active phase, the service is ready to receive messages and process requests. In the shutdown phase, the services release resources before de-activation.
[0034] In one embodiment as shown in Fig. 1, the development platform 108 integrates with both on-premises and online third-party application platforms 190 and 192, e.g. Salesforce platform and MS Dynamic CRM. An application, such as a CPQ business software, hosted on the development platform 108 may be an on-premises or cloud-based application, as well. The term on-premises will herein refer to a type of software delivery model that is installed and operated from a customer's in-house server and computing infrastructure and utilizes an organization's native computing resources. It is one method of using enterprise and consumer applications. The term cloud-based will herein refer to software that is hosted on remote servers where data is sent into "the cloud" over the internet where it is processed and returned to the user and where all application functions are performed off-site or over the internet, not on the user's desktop. In cloud computing, users access software applications remotely through the Internet 102 or other network 102 via a cloud application service provider.
[0035] The development platform 108 advantageously provides several unique features including, but not limited to: 1) multiple user authentication options - e.g. standard, SAMLv2 SSO, WS -Federation, Active Directory, One Time Password (OTP), 2) built in XSS and XSRF protection, 3) ability to simultaneously access and operate against multiple, heterogeneous persistence systems within the same application, 4) a declarative query definition mechanism which is syntactically agnostic of underlying persistence system, 5) an identical API for create, read, update, and delete (CRUD) operations, including bulk operations, which are agnostic of the underlying persistence system, 6) a scalable, fast cache for optimized performance, 7) asynchronous execution of long -running tasks, 8) a template- enabled email notification feature, 9) user interface (UI) widgets that map directly to persistence system data types, 10) composite UI components representing HTML forms, tables and trees, and 1 1) polling for incoming email message events and a processing API for such messages.
[0036] Figure 1 is a high-level block diagram of an embodiment of an example system 100 including a development platform 108 for integrating with multiple,
heterogeneous persistent systems (e.g., third-party application platforms) 190 and 192 The term persistent system and third-party application platform are used interchangeably to refer to the systems upon which the third party applications or other applications operate. The system 100 comprises a network 102, a server 1 12 including the development platform 108, one or more on premise third-party applications 190, one or more cloud-based third-party applications 192, one or more client devices 104a-104n associated with one more users 103a- 103n.
[0037] The network 102 can be a conventional type, wired or wireless, and may have numerous different configurations including a star configuration, token ring configuration or other configurations. Furthermore, the network 102 may include a local area network (LAN), a wide area network (WAN) (e.g., the Internet), and/or other interconnected data paths across which multiple devices may communicate. In some embodiments, the network 102 may be a peer-to-peer network. The network 102 may also be coupled to or include portions of a telecommunications network for sending data in a variety of different communication protocols. In some embodiments, the network 102 may include Bluetooth communication networks or a cellular communications network for sending and receiving data including via short messaging service (SMS), multimedia messaging service (MMS), hypertext transfer protocol (HTTP), direct data connection, WAP, email, etc. Although Figure 1 illustrates one network 102 coupled to the client devices 104a-104n and the server 1 12, in practice one or more networks 102 can be connected to these entities.
[0038] In one embodiment, the server 1 12 hosts the development platform 108 and is coupled to the network 102. In some embodiments, the server 1 12 may be either a hardware server, a software server, or a combination of software and hardware. The server 1 12 may be may be implemented by a computing device including a processor, a memory, applications, a database, and network communication capabilities. In the example of Figure 1, the components of the server 112 are configured to implement a development platform 108 described in more detail below. In one embodiment, the server 1 12 provides instructions for dynamically generating a user interface of an application deployed on development platform 108. The user interface may be used for requesting create, read, update, and delete (CRUD) operations against one or more persistent systems, e.g., third-party application platforms 190 and 192 or for requesting specific business functionality not necessarily associated with a data-set that may be performed by the Action Execution Service Module 662. The server 1 12 is coupled to the network 102 for communication with the client devices 104a-104n. The server 112 may be coupled to the network 102 for communication with the persistent systems 190, 192 or directly coupled to the persistent systems 190, 192.
[0039] The client device 104 may be a computing device that includes a memory, a processor and a camera, for example a laptop computer, a desktop computer, a tablet computer, a mobile telephone, a smartphone, a personal digital assistant (PDA), a mobile email device, a webcam, a user wearable computing device or any other electronic device capable of accessing a network 102. The client device 104 provides general graphics and multimedia processing for any type of application. The client device 104 includes a display for viewing information provided by the development platform 108 of server 112 via a browser 106. While Figure 1 illustrates two client devices 104a and 104n, the disclosure applies to a system architecture having one or more client devices 104.
[0040] The development platform 108 includes several modules or engines for carrying out its functions, including Core engine 110, Web engine 120 including Application Web module 124, Providers and Executors module 130, Application Providers module 140, Administration (Admin) module 150, Rules engine 160, Object-Relational Mapping (ORM) engine 170, and Configuration module 180, each of which will be described in more detail below.
[0041] Figure 2 is a block diagram illustrating one embodiment of a computing device, e.g. server 1 12 including a development platform 108. The computing device 1 12 may also include a processor 202, a memory 204, a communication unit 208, a display device 210, and an input device 212 according to some examples. The components of the system 1 12 are communicatively coupled to a bus or software communication mechanism 206 for communication with each other. In some embodiments, the computing device may be a client device 104, a server 1 12, or a combination of a client device 104 and a server 1 12.
[0042] The processor 202 comprises an arithmetic logic unit, a microprocessor, a general purpose controller or some other processor array to perform computations, provide electronic display signals to display device 210. The processor 202 is coupled to the bus 206 for communication with the other components of the computing device 112. Processor 202 processes data signals and may comprise various computing architectures including a complex instruction set computer (CISC) architecture, a reduced instruction set computer (RISC) architecture, or an architecture implementing a combination of instruction sets. Although only a single processor is shown in Figure 2, multiple processors may be included. The processing capability of the computing device 1 12 may be limited to supporting the display of images and the capture and transmission of image. The processing capability might be enough to perform more complex tasks, including various types of feature extraction and sampling. It will be obvious to one skilled in the art that other processors, operating systems, sensors, displays and physical configurations are possible. The computing device 1 12 also includes an operating system executable by the processor such as but not limited to WINDOWS®, Mac OS X, or UNIX® based operating systems.
[0043] The memory 204 stores instructions and/or data that may be executed by processor 202. The memory 204 is coupled by the bus 206 for communication with the other components of the computing device 112. The instructions and/or data may comprise code for performing any and/or all of the techniques described herein. The memory 204 may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, flash memory or some other memory device known in the art. In one embodiment, the memory 204 also includes a non-volatile memory or similar permanent storage device and media such as a hard disk drive, a floppy disk drive, a CD-ROM device, a DVD-ROM device, a DVD-RAM device, a DVD-RW device, a flash memory device, or some other mass storage device known in the art for storing information on a more permanent basis.
[0044] The communication unit 208 is coupled to the bus 206 and the network 102.
An alternate embodiment, the communication unit 208 may provide a port for direct physical connection to the network 102. The communication unit 208 includes a transceiver for sending and receiving instructions and data. In one embodiment, the communication unit 208 includes a Wi-Fi transceiver for wireless communication with an access point. In another embodiment, the communication unit 208 includes a Bluetooth® transceiver for wireless communication with other devices. In yet another embodiment, the communication unit 208 includes a cellular communications transceiver for sending and receiving data over a cellular communications network such as via short messaging service (SMS), multimedia messaging service (MMS), hypertext transfer protocol (HTTP), direct data connection, WAP, email, etc. In still another embodiment, the communication unit 208 includes ports for wired connectivity such as but not limited to USB, SD, or CAT-5, etc. The communication unit 208 links the processor 202 to the network 102 that may include multiple processing systems. The network of processing systems may comprise a local area network (LAN), a wide area network (WAN) (e.g., the Internet), and/or any other interconnected data path across which multiple devices may communicate. The communication unit 208 also provides other conventional connections to the network 102 for distribution of files (media objects) using standard network protocols such as TCP/IP, HTTP, HTTPS and SMTP.
[0045] The display device 210 is a liquid crystal display (LCD) or any other similarly equipped display device, screen, or monitor. The display device 210 represents any device equipped to display electronic images and data as described herein. In different
embodiments, the display is binary (only two different values for pixels), monochrome
(multiple shades of one color), or allows multiple colors and shades. In one embodiment, the display device 210 uses reflective light rather than emitting light for use outdoors and uses less power.
[0046] The input device 212is operatively coupled the processor 202 and is any one of a variety of types such as a keyboard and cursor controller, a scanner, a still or video camera, a keypad, a touch screen, a detector, an RFID tag reader, a switch, or any mechanism that allows a user to interact with system 100. In one embodiment, the input device 212 is a keyboard and cursor controller. Cursor control may include, for example, a mouse, a trackball, a stylus, a pen, a touch screen and/or pad, cursor direction keys, or other mechanisms to cause movement of a cursor. In another embodiment, the input device 212 is a microphone, audio add-in/expansion card designed for use within a general purpose computer system, analog-to-digital converters, and digital signal processors to facilitate voice recognition and/or audio processing.
[0047] Referring now to Figures 5 and 15, two components of the platform 108 are described in more detail. Figure 5 shown an embodiment of the core engine 110 and Figure 15 shows an embodiment of the configuration engine 180.
[0048] Figure 5 is a block diagram of Core Engine 1 10 for providing the system functionality of the development platform 108. Core Engine 110 is one of two modules that is used by all other components of development platform 108, as well as applications deployed on the platform 108. The Core Engine 110 includes several modules or components for providing services, including Cryptography Service Module 510, Caching Service Module 520, License Management Service Module 530, Logging Service Module 540, Email Service Module 550, Work Management Service Module 560, Security
Management Service Module 570, and User Service Module 580.
[0049] Cryptography Service Module 510 provides encryption and decryption of passwords and certain configuration values that may have embedded passwords, e.g.
connection strings. It is a singleton with two static methods - Encrypt(), which takes a raw string and returns a base-64 encoded encrypted string and Decrypt(), which takes an encrypted base-64 string and returns the raw string.
[0050] Caching Service Module 520 provides high-performance 0(1) cache service for storing frequently used data. Caching Service Module 520 uses a hash map to store keyed information backed by an LRU linked list of entries to pick candidates for eviction when a cache instance reaches capacity. Each instance of the cache also takes a TTL value for cache entries. However, the value is lazily checked - i.e., an entry is only checked for expiration upon access of that entry. Each instance of the cache also accepts a callback object that is notified whenever an entry is removed either because the entry expired or because the cache reached capacity (but not if the entry is intentionally removed). Caching Service Module 520 automatically tracks cache hits and misses to aid performance tuning. The methods provided by this service are:
Object Get(object k)
Set(object k, object v)
Remove(object k)
Integer Accesses(): The number of times the cache was accessed
Integer Hits(): The number of times an entry matching the key was found
Integer Size(): The current number of entries in the cache
The object used as the key must define consistent Equals() and Hashcode() methods.
[0051] License Management Service Module 530 provides services to examine the validity of a license granted to the application deployed on the platform and raises an error if the check fails. License Management Service Module 530 also ensures that an application is deployed to the same DNS name the license was assigned to, and that the current date falls within the license data validity period for every web request received by the platform 108. Further, License Management Service Module 530 ensures that when users are added, the total user count does not exceed the maximum number of users defined by the license. [0052] Logging Service Module 540 provides an asynchronous logging API to minimize the impact of logging on performance. The service automatically rolls over log files upon reaching a size of 2MB. It includes a singleton with static methods. The Logger maintains a FIFO queue of logging messages passed to one of the Log methods exposed by this service. A message is defined as a single string or a single string and an accompanying Exception or Error object with stack trace. A single background thread reads messages off of the queue and writes the messages to the log file asynchronously. Before each write, the number of bytes written to the log file is checked and if it exceeds the 2MB limit, the service renames the current log file with an appended time stamp and creates a new file. A single log message does not span multiple log files. The messages provided by this service are:
Init(): Called during module initialization. At this time, the Logger acquires a handle to the log file and starts the background logging thread.
Log(string m): Adds the message to the logging queue.
Log(string m, Exception e): Adds the message to the logging queue together with an error.
Close(): Called during module shutdown. The Logger releases the handle to the current log file and terminates the background logging thread.
[0053] Email Service Module 550 provides bi-directional communication with a configured email server. Outbound emails (via SMTP) is initialized from configuration parameters provided via the Configuration Module. Such emails are template -based with data filled in by a specific application-specific provider (please see discussion of Providers and Executors 130). Handling inbound email requires an active mailbox on the email server that this service can monitor (only POP3 supported at this time). Users of the service is allowed to register a single callback object with this service that gets notified each time a new email is received. The service leverages the Work Management Service Module 560 to ping the mailbox at periodic intervals. This feature is only activated if a callback object is registered. The service provides the following methods:
SendMail(string tpl, string[] to, MailContent data): Send an email using
specified template and provided data for the template, to provided set of email addresses.
SendMail(string tpl, string[] to, MailContent data, bool async): Same as above, except the email is sent out asynchronously if async is true. This feature leverages the Work Management Service Module 560 to dispatch the email. Composition of the email is performed
synchronously.
RegisterCallback(ICallback cbk): Register a callback object to be notified when an email is received.
[0054] Work Management Service Module 560 provides a service for allowing applications to run long-running tasks asynchronously. It holds a pool of threads that wait in the suspended state until it is notified of pending work and a FIFO queue onto which users of the service push work. The number of threads in the pool is configurable and provided by the Configuration Module. Upon initialization, the Work Manager Service creates the configured number of threads and adds them to the pool. Upon creation, they immediately go into a wait state on a common monitor. Users of the service push implementations of the IWork interface to the Work Manager. This interface declares a single Process() method. Upon receiving the work object, it is pushed to the FIFO queue and the threads are notified. The threads then compete and one of them gets to dequeuethe work object and invoke the Process() method. Once the Process() method returns, the thread returns back to a wait state. To shut down the service, the Work Manager 560 Done() method is invoked. This enqueues a special implementation of the IWork instance - one for each thread in the thread pool. Once each thread dequeues this special instance, it shuts down. This allows each thread to complete any pending work before terminating. Methods provided by this service are:
Add(IWork w): To add work to the Work Manager.
Wait(): Pauses all threads. In-flight work will be completed, but no new work will be dequeued.
Done(): Shuts down the Work Manager. This method is intended for system use only.
Security Management Service Module 570 provides a service to intercept all requests and verify them for authorized access. Security Management Service Module 570 is installed as an HttpModule. Note: Such a configuration setting is US-specific, but all other web servers equivalent feature. The service makes the following checks:
Unauthenticated access: If detected the request is re-directed to the appropriate login handler. Unauthorized access: If access to protected or internal access is requested (e.g. the configuration file), access is denied via a 401 HTTP response.
Unauthorized access method: Access to SOAP endpoints via HTTP Gets are disallowed.
Unauthorized access role: Access to the Admin SOAP endpoints are
disallowed for users that do not have the Administrator role.
[0055] Security Management Service Module 570 also provides XSRF protection by generating a one-time random token generated when a user logs in that is supplied to the Web Module containers (see further description of the Web Engine 120). This token is required to be sent back for every HTTP request either as an HTTP header, a query parameter or as a form value. If the offered token value does not match the one generated for the user, access is denied via a 401 HTTP response.
[0056] Finally, Security Management Service Module 570 calculates whether a user has the appropriate role to access or perform a particular operation on a particular field or column, a composite UI component or a page (see further description of the Web Engine 120 section for definitions of these terms). Security Management Service Module 570, however, does not automatically detect attempts to access such artifacts - the service must be invoked pro-actively to calculate access. This invocation occurs from the Providers and Executors module 130 and in some cases from the AJAX/JSON Endpoints 320 in Figure 6C). By default the implementation is open whereby all user roles have read and write access to everything. Each of the artifacts listed above can be protected by defining a permission setting per role in configuration. Depending on the type of artifact, each role may have one of DENIED, UNRESTRICTED or READONLY access types. Artifacts that are not naturally writeable (e.g. composite UI components or toolbar controls) and are, for example, not allowed to have a READONLY access type. The methods this service provides are:
Permission.ACCESS Adjudicate(Permission[] permissions): Given a set of permissions attached to a particular artifact, return the type of access - UNRESTRICTED, READONLY,
DENIED - granted for the current user's role.
[0057] User Service Module 580 provides some pertinent information about the logged in user. These attributes are typically user information stored in the backend persistence system and retrieved and stored in an HTTP Session object after a successful login. The methods provided by this service are:
Euid GetUserPk(): Returns the primary key for the current user's record.
String GetLoginId(): Returns the login id for the current user.
String GetUserRole(): Returns the current user's role.
String GetUserName(): Returns the full name of the current user.
String GetUserEmail(): Returns the current user's email address.
[0058] Figure 15 is a block diagram of one embodiment of a configuration engine 180 for informing the development platform 108 about an application deployed on the development platform 108, and includes all of the metadata 1510 about the application. In one embodiment, configuration engine 180 informs the development platform with all of the metadata 1510 about an application deployed on the development platform 108. The configuration engine 180 includes configuration management module 1500 for providing functions for managing and accessing the metadata 1510. This metadata allows the platform to interact with the application as and when necessary. In one embodiment, the configuration may be stored in an XSD schema based XML file that lives within the application web component 124 within the web engine module 120 of the development platform 108. The metadata 1510 includes of the following parts:
[0059] Application Settings 1520: The web page application header and footer style, the Work Manager thread pool size, the view class, application toolbar, supported languages (internationalization), application and session initializers.
[0060] Page Definitions 1530: Each application deployed on the platform includes a set of pages. Each page includes one more combinations of toolbars, forms, tables and trees, which in turn consist of widgets - fields and columns - and controls - buttons, dropdowns etc. This section defines the composition of each page in the application. See user interfaces of Figures 21 and 22 for various UI components such as table 2120, field set 2130 and application toolbar 2230. Each of the composite UI components - forms, tables and trees - is linked to a Data Provider 1540.
[0061] Data Providers 1540: This component specifies the classes that implement interfaces defined in the Providers and Executors module 130 and live in the Application Providers module 140.
[0062] Picklists 1560: These are definitions of List of Value fields, also called Picklists, one of the field types that may be used in forms and tables. The configuration allows to link these fields directly with fields on the data model in the persistence system. The configuration also allows overriding/replacing or excluding certain values from a particular picklist field.
[0063] Lookups 1570: Lookups are another type of fields that represent reference types - a pointer to a specific instance of an entity or a specific record in the data model. This section defines the various types of lookups used in the application.
[0064] Data Models 1580: This is where the data models that form the glue between the ORM Engine 170 and the Application Providers module 140 are defined. This section of metadata includes the set of entities that comprise the data model and for each entity, the queries that may be run against it.
[0065] Administration (Admin) Settings 1580: The Admin Settings define supported authentication schemes, one or more named persistent systems used by the application and email server configuration.
[0066] The Web Engine 120 provides the face of the deployed application to the external world. The Web Engine 120 provides instructions for generating a user interface for an application deployed by development platform 108. The Web Engine 120 hosts web- containers 310 - the vehicle on which the pages that comprise the application are delivered to a user's browser 106, among other artifacts. The web engine 120 is the largest module in the platform 108. An application hosted on the platform 108 is a single-page web application when viewed from a client perspective. Containers 310 may host a set of pages, derived from the page definitions 1530 defined in the Configuration Engine 180. There are two containers provided by default - a multi-page container and a single-page container. The multi-page container is intended for access via an independent Universal Resource Locator (URL). In one embodiment a single-page container is intended to be embedded in a third-party web application platform 190 or 192, e.g. Microsoft Dynamics CRM or Salesforce, although a single-page container may be employed for other purposes.
[0067] Figure 3 is a block diagram of one embodiment of components of web engine
120 for generating a user interface for an application deployed by the development platform 108. The Web Engine 120 provides the instructions for generating a user interface via the browser 106 of the client device 104. The foundation of the user interface (UI) is the third- party Javascript library ExtJS 316. The Web module 120 includes wrappers around this library that exposes a uniform interface to create composite UI components. It also is a bridge between UI events triggered from ExtJS 316 to the Application Web JS event handlers 634. On the server-side, the Web module 120 also provides application-agnostic AJAX/JSON endpoints 320 whose methods represent standard operations that may be performed on a composite UI component - e.g. load, save, update, etc., as well as specific actions that do not necessarily relate to a specific UI component that may be performed by the Action Execution Service Module 662. The Web module 120 interacts with the server-side application implementation, the Application Providers Module 140 via the Providers and Executors Module 130.
User Authentication
[0068] In some embodiments, all web requests that arrive at the Web Module 120 go through the Security Management Service module 570 of Core Engine 110. When a request arrives from an unauthenticated user, the Security Management Service module 570 redirects the request to a Login web page. Login checks for the configured authentication scheme with the Configuration Module 180. Depending on the authentication scheme, Login invokes the appropriate method in the Admin Module 150 or re-directs again to an authentication provider if an SSO or similar third-party authentication provider scheme is configured. The authentication options are:
[0069] Standard: This is the default authentication scheme. The user supplies a username and a password and the admin module matches them against stored credentials in the persistence system, i.e. 190 or 192. This scheme may be used in conjunction with the other schemes.
[0070] One Time Password (OTP): In this scheme, an application is allowed to create an OTP record in the persistent system 190, 192. The record is assigned a unique identifier and a one-time password comprising of a set of alpha-numeric characters of any length. A user may request authentication using this scheme by sending two parameters to the Login page on first time access - the requestld and otp=true. Upon validation of the request, the user is challenged for the one-time password. The user is allowed two failed attempts to enter the correct password. If the number of attempts exceed 3, the OTP record is deactivated and cannot be used again and the user is denied access. If the user enters the correct password, the user is allowed access, the OTP record is deactivated and cannot be used again. A TTL or expiration date may also be set for the OTP record. Any attempts to log in, even if the correct one-time password is provided, after the expiration date are denied access. This scheme may be used in conjunction with any of the others.
[0071] SAML v2.0: In this scheme, the Admin module 150 sends out a SAML authentication request to the configured IdP. The response is received by an HTTP handler SSOLogin.ashx.
[0072] WS -Federation: This option is handled entirely by Login page using the open source OWin library from Microsoft.
[0073] Auto-Login: This is the same as Active Directory authentication. Login page invokes the Admin module 150 to handle this.
[0074] Microsoft Live Id: Also handled via the Admin module 150.
[0075] The development platform 108 also allows for definition of an application specific authorization provider via the Providers and Executors Module 130. After successful authentication and if any defined authorization provider allows access, the user is redirected to the original URL to which access was attempted. This is typically one of the web containers 310 - Home or One View.
UI Markup Generation
[0076] Once a web container 310 is loaded onto a browser 106, the next step is to retrieve the UI configuration. This is served up by the Configuration Service Module 652 of the AJAX endpoints component 320 and occurs in three steps for the multi-page container (Home) and in two steps for the single-page container (One View). Home first pulls in the page level and summary information for pages that are configured for that container and that the user has permission to view in the first two steps. This summary information is used to generate the page toolbar, for example page toolbar 21 10, navigation tab and certain master data - in particular the list of values for all configured picklists. Individual page configuration is retrieved lazily in the third step when the user navigates to the page the first time. Each page definition 1530 in the configuration specifies a Javascript layout function which is invoked to generate the markup for the page. This function is defined in Layout Function Module 630 of the Application Web JS component 312. The platform provides functions for creating various UI components: grids, forms, toolbars and trees, for example, toolbars 21 10 and 2140 and form 2150. These are then stitched together by the layout function into a single view. Once the layout for the page is rendered, the load function of the Load Function Module 632 is called. Similar to the layout function, the load function is optionally specified in each page configuration. This function is intended to load data into the page. The load function interacts with controller scripts in the Web JS component 314 of the Web Module, which in turn interacts with the AJAX endpoints 320 of the server part of the Web Module 120.
Main-Views. Controllers and Widgets
[0077] This section describes the Javascript APIs and components provided by the
Web JS component 314 of the Web Engine module 120. These are categorized into Main- Views, Controllers and Widgets. This section describes the Javascript APIs and components provided by the Web JS part of the Web Module. These are categorized into Main-Views 610, Controllers 612 and Widgets 614.
[0078] Main-Views: The main view components 610 is the overall page layout.
There are two parts to each main view - the navigation menu and the page section. The navigation menu lists out the pages available to the user. On clicking a particular page name, the page is presented to the user in the page section. There are two available main views - GTP (e.g., shown in Figures 21 and 22), which lays out the navigation menu on the left in a tree structure with collapsible nodes and the page section on the right; and TAB, which lays out the pages in a tab layout with the navigation menu as tab headers. The main view to be used is configurable in config.xml.
[0079] Controllers: Controller components 612 are wrappers around composite UI elements grids, forms, charts, toolbars and trees. They provide a uniform API to create and manipulate these elements as provided by the underlying Ext JS library 316. These are invoked from the application specific layout functions of module 630 to create these various elements and arrange them on the page. The controllers 612 also provide functions to manipulate the elements and the data they contain including but not limited to, clearing, loading, adding rows to, removing rows from, updating rows of grids, saving, creating and deleting data in forms, loading trees etc. The controllers 612 automatically interact with the providers associated with grids, forms and trees via the AJAX end points 320 as necessary to manipulate the data it displays.
[0080] Widgets: Widget components 614 are the fields within the composite UI elements. Most are wrappers around fields provided by Ext JS library 316. Some are custom. Each of them have a corresponding server-side representation that they are transformed to when controllers 612 interact with the providers. The widgets available are: Datetime: Represents a date time object. Currently only supports setting the date. Dates are always displayed in the user's time zone.
Link: Read-only field that reacts to the click event to invoke an application defined Javascript function. Used only in grids.
Lookup: Compound field with dual triggers. One trigger clears the value. The second pops up a grid that allows the user to select a particular record and set it as a value. Used in forms and grids to represent a reference to a particular record.
Money: Represents a monetary value. It has two parts - the currency and the amount. The value is displayed formatted with the currency symbol.
Selection: Represents a field whose value is picked from a list of discrete values.
[0081] The A J AX End Points. The A J AX End Points 320 are the mechanism by which the web containers 310 and the Application Web JS component 312 communicate with the server 1 12. They are grouped together by function. The wire format is JSON and it leverages the native serialization/de-serialization features of the platform. The services provided are:
[0082] The User Management Service: The User Management Service Module 650 is primarily used by the standard username/password challenge authentication scheme and the OTP challenge authentication scheme. In the standard username/password challenge scheme, the development platform maintains properly hashed username and password credentials in the persistence system 190 or 192. In addition to a method to authenticate the user given a username and password pair, this service also provides methods to reset and change a user's password. The service also provides a method for OTP authentication. This service is also used to track usage statistics, the metrics for which are defined by the application deployed on the platform.
[0083] The Configuration Service: The Configuration Service Module 652 delivers page configuration data to the web containers. It provides three methods:
[0084] Initialize: This is called when the web container 310 is first loaded after the user logs in. This is the first step in generating the page layout. It is passed in the user's metadata. This metadata is passed to any configured session initializer. The session initializer is given the opportunity to modify or add to the user's metadata. This method then retrieves all picklists and any page-level toolbar targeted to that web container. All of this data is then returned back to the web container 310 and is made available as global Javascript objects in the web container 310.
[0085] GetNavConfiguration: This is called to retrieve the page metadata that populate the web container 310 and for the pages that the user has permission to access. The returned data from this method is used to create the navigation panel, e.g. navigation panel 2210 of Figure 22, of the web container.
[0086] GetPageConfiguration: This is called in the third step of web container layout to pull in all of the composite UI components that are contained in a page.
[0087] The Grid Service: Grid Service Module 654 provides methods for grids to load data, remove, add and update rows. The methods are:
[0088] Get: Accepts as parameters the starting and ending row number, the grid name, sort column, sort direction, filter string and the arguments used to retrieve data, returns a set of rows to populate the corresponding grid with data. Also accepts a refresh flag. If the flag is true, any cached data is purged and fresh data is loaded directly from the persistence system 190 or 192.
[0089] Add: Accepts as parameters the grid name and a list of key- value pairs. Each element of the list represents a row to be added. Each set of key-value pairs represent the column name and the value to set for that field.
[0090] Update: Accepts as parameters the grid name and a list of key-value pairs.
Each element of the list represents a row to be updated. Each set of key-value pairs represent the column name and the value to set for that field. Null values must be explicitly specified. Absence of a column name implies that field will not be modified.
[0091] Delete: Accepts as parameters the grid name and a list of key-value pairs.
Each element of the list represents a row to be deleted. Each set of key- value pairs represent the column name and the value to set for that field.
[0092] The methods above pass the call on to the appropriate TableDataProvider object 818 (see Providers and Executors module 130 and Fig. 8) configured for the grid. Prior to this, the provider's CheckAccess() method is called to confirm the user has permission to execute that operation for the Add Update and Delete methods. [0093] The Form Service: Provides methods for forms to load, remove, add and update data. The methods are:
[0094] Get: Accepts as parameters the form name, primary key of the record to be shown, and the arguments used to retrieve data, returns a set of fields to populate the corresponding form with data. Also accepts a refresh flag. If the flag is true, any cached data is purged and fresh data is loaded directly from the persistence system.
[0095] Add: Accepts as parameters the form name and a set of key-value pairs. Each key-value pair represent the field name and the value to set for that field.
[0096] Update: Accepts as parameters the form name and a set of key-value pairs. Each key-value pair represent the field name and the value to set for that field. Null values must be explicitly specified. Absence of a field name implies that field will not be modified.
[0097] Delete: Accepts as parameters the form name and a set of key-value pairs.
Each key-value pair represents the field name and the value to set for that field.
[0098] The methods above pass the call on to the appropriate FormDataProvider (see the Providers and Executors Module 130 and Fig. 8) configured for the form. Prior to this, the provider's CheckAccess() method is called to confirm the user has permission to execute that operation for the Add Update and Delete methods.
[0099] The Tree Service: Trees are read-only as of this version. So the Tree Service
Module 658 provides a single method to load data. Trees may be loaded one node at a time upon expansion of that node the first time. So this method accepts as parameters the tree name, the full path to return data for, the arguments to use for the search criteria and the refresh flag.
[00100] The Chart Service: Charts also are read-only components. Given the chart name, the arguments to be used for the search criteria and the refresh flag, the Chart Service Module 660 returns the data to be used to populate a chart.
[00101] Action Execution Service: The Action Execution Service Module. The
Action Execution Service provides a single method that accepts an action name, the executor name as defined in the configuration module and a set of arguments as a list of key-value pairs. The service looks up the specific executor and passes on the action name and arguments to the executor. The executor may return an arbitrary object that is passed on to the caller who may interpret is as it chooses. This service provides AJAX-enabled API's to execute actions that are not simple CRUD operations tied to the UI components. It provides a single method:
Execute: Accepts as parameters the name of an executor as specified in the Configuration Module, the action name to execute and a set of key- value pair arguments.
The call above looks up the Executor from the DataProviderManager (see discussion of Providers and Executors 130) and passes on the action and arguments to the appropriate Executor to process the request and return any data back to the browser.
[00102] Referring now to Figures 16, 17A, and 17B, the methods for dynamic generation of a user interface are described in more detail through sequence diagrams.
[00103] Figure 16 is a sequence diagram for dynamically generating a user interface, including set up of page navigation components, according to one embodiment of the disclosed technologies. The sequence may begin by the user, at 1610, requesting a web page of an application deployed on the development platform 108 of server 112. This request for a web page will be first received in browser 106 of client 104 and handled by the web container module 310 loaded onto the browser 106. At 1612, the web container module 310 will communicate a request to configuration management module 1500 of the configuration engine 180 for retrieval of banner and footer configuration parameters among the metadata 1510. At 1614, configuration management module 1500 may retrieve the banner and footer configuration and return the results to web container module 310. At 1616, the web container module 310 may render the banner, and footer, e.g. banner 2220 and footer 2240 of Figure 22, of the web page, and at 1618, return the web page.
[00104] The sequence, at 1620, may proceed to initialize the web container whereby web container module 310 makes a call to the configuration service module 652 of AJAX endpoints 320 on the server-side of the web module 120. At 1622, the configuration service module 652 looks up the container 310, and at 1624, the configuration service module 652 makes a request to retrieve the application and container configuration from the configuration management module 1500 based on the determined container, i.e. Home or One View. At 1626, the configuration management module 1500 returns the retrieved application and container configuration metadata to the configuration service module 652. At 1628, the configuration management module returns the view class, picklists, application toolbars, etc. to the web container module 310. [00105] The sequence, at 1630, may then proceed to retrieve page metadata for the navigation panel of whereby the web container 310 issues a request to the configuration service module 652. The configuration service module 652 may, at 1632, make a call to configuration management module 1500 to retrieve pages for the web container. At 1634, the configuration management module 1500 will retrieve and return the results of the request for pages of the container 310 and return those pages to the configuration service module 652. At, 1636, the configuration service module 652 will make a request to the security management service module 570 of the core engine 110 to check user page access permissions. At 1638, the security management service module 570 returns names of pages where access is permitted to configuration service module 652. At 1640, configuration service module may return navigation panel configuration and page event handlers based on the determined page access permission. Finally, the web container module 310 may render 1642 the navigational panel in the browser 106 of client device 104 based on the received navigational panel configuration.
[00106] Figures 17A-17B are sequence diagrams for generating a user interface, including rendering a page when a user accesses the page for the first time, according to one embodiment of the disclosed technologies. The sequence may begin by the web container module 310 loaded on browser 106 of client device 104 receiving a request 1710 from a user to navigate to a web page. If the page has not been rendered on the browser 106, web container module 310 may make request 1712 to configuration service module 652 to retrieve the page configuration. The configuration management module 1500 may receive a request 1714 from configuration service module 652 to retrieve the page definition metadata. At 1716, the configuration management module 1500 returns to the configuration service module 652 page toolbar configuration, tables, forms, trees and charts, in response to the request for the page definition.
[00107] The sequence, at 1718, may then proceed to make a call to the security management service module to determine access to toolbar fields, tables, forms, trees and charts. The security management service module makes the determinations pertaining to access and returns 1720 the results to configuration service module 652. The configuration service module 652 may, assemble 1722 the user interface components based on the determination and return 1724 the results to the web container 310.
[00108] The web container sends a request 1726 to layout function module 630 to invoke a layout function. In one embodiment the layout function may be a layout function in JavaScript. For each user interface component, the layout function module 630 may, at 1728, send a request to controller component 612 of the Web JS module 314 for creation of components of the user interface. At 1730, the controller component 612 returns the user interface components to the layout function module 630. In response, the layout function module 630 renders 1732 the layout of the user interface components for the page and returns 1734 the results to the web container module 310. In one embodiment, at 1738, the web container 310 may invoke an afterActivate()method handler, if the handler is defined. The afterActivateO method is an event handler that is part of the Event Handlers 634. If defined for a page, it is invoked every time a user navigates to a page. If this is the first time a user navigates to a page, it is invoked after the page has been rendered (after the LayoutFunction() call) and after the page has been loaded (after the LoadFunction() call). Applications may implement application-specific functionality in this method. The function name is configured as part of the Page Definitions ( 1530) metadata. Finally, at 1738, the web container module 310 renders the page to user 103 via the browser 106.
[00109] Referring now to Figures 7 and 8, the operation and structure of the provider and executor objects is described in more detail. Figure 7 is a block diagram of one embodiment of providers and executors module 130 for providing provider and executor objects 710, 720, 730, and 740 utilized in the development platform 108. Providers and executors module 130 contains four categories of objects 710, 720, 730, and 740. The first category are data providers 710. These are responsible for the co-ordination of application data management between the Web Module 120 and the Application Providers module 140. All providers implement the IDataProvider interface (or one of its derived interfaces) and extend the BaseDataProvider class. Figure 8 below shows a class diagram for this category of objects 710. IDataProvider 800, ITableDataProvider 804, ITreeDataProvider 806,
IFormDataProvider 808, and IChartDataProvider 810 are interfaces. BaseDataProvider<T> 814, TableDataProvider 804, FormDataProvider 820, and FormData 830 are abstract classes. TreeData 812, TableData 824, PagedTableData 832, Filter 828, LookupListProvider 822, PicklistDataProvider 826, and ChartData 816 are concrete classes. Line arrows represent inheritance, block arrows represent "uses".
[00110] Inherited from the IDataProvider 800, are four interfaces. Implementations of each of these interfaces manage data that is displayed in one of the four UI components. All concrete implementations of the providers inherit from the generic abstract class
BaseDataProvider 814 either directly or indirectly. The only exception is the special purpose provider, the AuthorizationProvider 802, which implements the IDataProvider 800 interface directly.
[00111] The Application Data Providers 710 that manage data made accessible to users via the grid or table UI component extend from the TableDataProvider 818 class. The GetDataO method of this class returns an instance of TableData or PagedTableData or an instance of a class derived from one of these classes. This method typically interacts with the ORM Module 170, running configured queries to return the data that fit the search criteria passed in to the method as a list of key- value pairs. The interpretation of these key value pairs is left to the derived Application Data Provider. These instances in turn, provide methods to add, update and delete the data they contain. The difference between the TableData 824 class and PagedTableData 832 class is that the former loads the entire set of rows that fit the search criteria used which the PagedTableData 832 retrieves a subset at a time, which allows it to be much more scalable for large data volumes. In some embodiments, the QueryContextModule aids the PagedTableData 832 for this purpose. The filter class is used by a TableData 824 instance for in-memory filtering of rows.
[00112] Data that is displayed in forms is managed by classes that extend the
FormDataProvider 808. The Get() method is implemented by an Application Data Provider class that returns an instance of a FormData 830 derived class. The derived class declares the actual fields shown on the form.
[00113] Trees and Charts are read-only and Application Data Providers that manage such data implement the corresponding interfaces directly. Implementations of the
ITreeDataProvider 806 interface are required to return an instance of TreeData 812 while implementations of the IChartDataProvider 810 are required to return an instance of ChartData 816.
[00114] The module in Figure 8 also provides three special purpose providers. All of the special -purpose providers are accessible through well-known names. To override any of these providers in the Application Provider Module 140, an inherited class must be defined and registered with the well-known name with the Configuration Module 180:
[00115] The PicklistDataProvider 826: This provider is registered under the name "PicklistDataProvider". Given the name of a picklist defined in the Configuration Module, it returns a list of key-value pairs to populate dropdowns in picklist type fields. The data for picklists can be retrieved in four different ways: [00116] When it maps to a picklist type field defined on one of the objects in the persistence system.
[00117] When it is mapped to a query defined in the data model configuration. This type of picklist contains a list of objects that match the query criteria specified.
[00118] When it is mapped to another provider that serves as a delegate that returns the picklist values. This is particularly useful when the rules to form the list of values is complex and can only be programmatically achieved.
[00119] When it is mapped to a list of values statically defined in the Configuration Module 180.
[00120] The LookupListProvider 822: The LookupDataProvider 822, registered under the name "LookupDataProvider" is a simplified, read-only derivation of
Table DataProvider 818. This is invoked to populate the popup grid for lookup fields.
[00121] The AuthorizationProvider 802: The AuthorizationProvider 802 is registered under the name "AuthorizationProvider". This is called just after a user logs in passing in the user's metadata. The default implementation does nothing, but it can be overridden to deny access and/or to modify the user's metadata that is stored as a Javascript global object in the web container.
[00122] The AttachmentProvider: The AttachmentProvider is used to download and upload files as attachments to various objects that allow such functionality in the underlying persistence system. It is front-ended by the Attachments. ashx web handler in the Web Module 120 and interacts directly with the ORM Module 170 and does not require any application specific implementation.
[00123] At the heart of the Providers and Executors module 130 module is the DataProviderManager. This component reads the configured data providers from the Configuration Module 180 and loads the implementations from the Application Providers Module 140 by reflection and maintains a map of the names and implementation instances. Other modules - in particular the Web Module 120 - request an instance of the
implementation by name which then proceed to invoke operations on the providers to fulfill business functionality.
[00124] The second category of objects are the Executors 740. These objects implement business functionality that are not necessarily CRUD operations - functionality that does not simply retrieve and store data between the web interface and the persistence system transforming and executing validations along the way. An example of an action could be to revise a quote or close an opportunity. Executors are accessed the same way as Providers - from the DataProviderManager.
[00125] The third category of value holder objects 720 contained in this module are compound types that are the server-side counterparts of the Web Module 120 widgets. These types implement the IFilterable interface that allows for in-memory filtering. These are:
[00126] Date: Represents a date time. Maps to the datetime widget.
[00127] Link: Represents a link. This is an over-ridable type that can be customized to add additional data to the value. Maps to the link widget.
[00128] Selection: Represents a key-value pair and maps to the selection widget.
[00129] Lookup: Represents a referential field and maps to the lookup widget. It has three attributes: the primary key of the referenced object, a display name and the type of the referenced object. It may be extended to add additional application-specific attributes.
[00130] Money: Represents an amount and currency pair and maps to the money widget.
[00131] Icon: This represents an image displayed in-line in grids. There is no corresponding widget in the Web Module. It uses a text field with a special renderer for display. An optional handler that is a javascript function invoked when the icon is clicked may be specified. A tooltip may also be optionally specified.
[00132] The fourth category of objects in this module are initializers 730. There are two extensible initializer interfaces provided. The implementation class is specified in the Configuration Module 180. The first is the IApplicationlnitializer, which provides a single no-argument method Initialize(). This is invoked from the Global. asax in the Web Module 120 upon the Application_Start event. The second is the ISessionlnitializer, which is invoked just after the user has logged in and during initialization of the web container.
[0001]
[0002] ORM Engine 170
[00133] Figure 4 is a block diagram of one embodiment of an object relational mapping (ORM) engine 170 for providing persistence services against one or more third- party application platforms. The ORM engine 170 exposes a consistent, coherent interface to other modules of the development platform 108 to interact with any online or on-premise persistence system 190 or 192, e.g. Microsoft Dynamics CRM version 4.0 through the latest 2016 release - online or on-premise, Salesforce and even a local RDBMS (currently only supports MS SQL Server). The ORM Module 170 abstracts out any schema and the query language in an online or on-premise persistence system 190 or 192 into generic forms with a well-defined mapping into actual persistence system types. ORM engine 170 interacts with the persistence system 190 or 192 using remote APIs defined by it. The ORM Engine 170 includes several module for abstracting out the schema and query language in a persistence system 190 or 192. In one embodiment, the ORM engine 170 includes Data Model
Management Module 410, Entity Management Module 420, Persistence Management Module 430, Save Context Module 440, Base Entity Module 450, and Query Context Module 460.
[00134] Data Model Management Module 410 is the primary module through which users interact with the ORM Engine. It is responsible for managing the relationships between different classes of BaseEntity instances, determination of the appropriate Persistence Manager for the configured Persistent System and provide and implement several functions to interact with the ORM Engine. These functions are defined below (for the
IDataModelManager interface). This module includes the IDataModelManager interface, the AbstractDataModelManager abstract class and any derived class from
AbstractDataModelManager that is specific to a particular data model.
[00135] Entity Management Module 420, also referred to herein as an Entity Manager, manages the lifecycle of a single entity. In most cases, the DataManagerModule delegates calls to an instance of the EntityManager, if the DataManagerModule knows which entity the call is about. The EntityManagerModule is also responsible for managing cached instances of BaseEntity and it's derivatives, ensuring the data integrity and relationships of each instance of BaseEntity. It also provides API methods for BaseEntity instances to interact with the PersistenceManagementModule .
[00136] Persistence Management Module 430 This module is responsible for retrieving and storing data from the configured Persistent System. It is abstracted by the IPersistenceManager interface. It comprises of the IPersistence Manager interface, the Querylnfo, Condition, Expression, Parameterlnfo, Sortlnfo objects. It also includes specific implementations of the IPersistenceManager interface, that map retrieve and store operations to the specific Persistent System. Queries in the format native to the Persistent System are generated just-in-time. This allows a certain amount of optimization at run-time where arguments not provided for a specific predicate clause are not included in the query at all, reducing the complexity of the query.
[00137] Save Context Module 440 is responsible for bulk saving a set of BaseEntity instances. BaseEntity instances (or their derivatives) are registered with a single instance of the SaveContext and changes made to these instances are tracked. When the Commit() method is called, the SaveContext object in this module re-arranges the list of candidates (to ensure data integrity - e.g. parents must be created before child objects) and stores them into the Peristent System via a bulk save method Persistence Management Module 430.
[00138] Base Entity Module 450 includes the BaseEntity abstract class , the
Descriptors - CrmDescriptor, PersistenceDescriptor, FieldDescriptor, RelationshipDescriptor and the ManagedTypes. The Base Entity Module 450 and its components are described in more detail below with reference to the hybrid implementation mode.
[00139] Query Context Module 460, in one embodiment, is provided as a reverse of the Save Context Module 440. It is responsible for retrieving multiple instances of a
BaseEntity (or a derivative) in a batched manner so as to not overwhelm the memory of the server the application is running on. It takes a Querylnfo object and breaks it up into two sub- queries (Though SQL terminology is used here, this applies to non-SQL based cloud storage services as well) - (a) a query with only the primary key column/field in the SELECT part of the clause, the complete predicate and any ORDER BY clauses and (b) a query with the full SELECT clause and the predicate replaced with an IN clause that comprises a list of Primary Key values. Query (a) is run first, one time only for a given set of arguments to the query. Then, query (b) is run with a sub-set of the primary keys to retrieve a "page" or sub-set of data. See Figure 10A-10B for the flow of a paged query.
[00140] In one embodiment, the ORM Module 170 provides a hybrid implementation model. According to the hybrid implementation model, each table (in an RDBMS persistence system 190 or 192) or object (in Salesforce) or entity (in Dynamics CRM) are mapped by the Base Entity Module 450 via descriptor objects to an entity class. Each row or instance of an object maps to an instance of the entity class. The Base Entity module 450 provides specific compound types that map to field types in the persistence system. In one embodiment, each entity must also be defined in the Configuration Engine 180, together with attributes that specify the cache-ability and, most importantly, any queries that may be called against that entity class. In one embodiment, queries may be defined declaratively in the Configuration Engine 180. In one embodiment, multiple data-model definitions may be allowed, so long as the names are unique. In one embodiment, each data-model is managed by Data Model Management Module 410, also referred to herein as an implementation of an IDataModelManager interface, that provides methods for interacting with the entity class instances. In one embodiment, references to the appropriate IDataModelManager instance are obtained from a singleton Registry class, given the name of the data model.
[00141] The following sections describe how entity classes are declared and defined, how queries are declared and how the entity classes and queries are managed.
[0003]
[0004] Data Model Definition
[00142] In one embodiment, the data model definition has two parts - one specified in the Configuration Engine 180, specifically in the config.xml, and the other implemented as part of the Application Providers module 140. Each entity class must have a declaration in the config.xml with a name that is unique within that data model definition. In the Application Providers module 140, a class (the Base Entity derivative) must be defined that directly or indirectly inherits from the BaseEntity class, which is defined in the ORM Engine 170, for each of the entity classes. In addition, an implementation of the IDataModelManager interface that also extends the AbstractDataModelManager abstract class must be defined, that maps the entity name to the implementation class. This IDataModelManager implementation class is specified in the configuration. The entity implementation class is annotated with descriptors declared at the class level (the CRMDescriptor) - to map the class to a corresponding persistence system object/entity/table - and at the field/property level (the FieldDescriptor) - to map to a field in the persistence system object/entity/table. In addition referential fields - references or foreign key fields to other objects/entities/tables have to be annotated by the RelationshipDescriptor. Each of the descriptors have a name that is used as an identifier for that field or related entity in query definitions. For a referential field, the name of the FieldDescriptor and the RelationshipDescriptor must be the same. In addition, if the relationship is navigable bi-directionally, the corresponding field on the other entity class must be annotated with a RelationshipDescriptor of the same name.
[00143] The table below shows the mapping between field types defined in the ORM Engine 170 and types in the supported persistence systems 190 and 192. It also lists out the native type enclosed by the field type of ORM Engine 170.
[0005]
[0006] Query Definition
[00144] To retrieve data from a persistence system 190 or 192, each entity class may be associated with one or more queries. No code needs to be written. All queries are declarative and adhere to a persistence system's agnostic schema and defined in the
Configuration Engine 180. Each query defined must have a unique name. A query definition has two parts - the SELECT part and the PREDICATE part.
[00145] The SELECT part defines the fields to be loaded into each instance of the entity class returned as a result of the query. It also specifies fields from related entity classes that are loaded together with the primary entity. The number of such related entities specified in a query and the depth of nesting is only limited by the underlying persistence system.
[00146] The PREDICATE part defines the search criteria for the query. The unit of the criteria is an Expression declaration consisting of a field - related entity field path may be specified by a dot notation (e.g. Company. Contact. FirstName) - an operator (Equal, NotEqual, Like, NotLike, LessThan, LessThanEqualTo, GreaterThan, GreaterThanEqualTo, In, Notin, Null, NotNull) and either a hardcoded value or a parameter name (in which case it must start with an @). Expressions are nested within Condition declarations together with a Conjunction (And, Or). Each Condition declaration may have one or more Expression declarations and/or one or more nested Condition declarations.
[0007] Data Model Activation
[00147] Each data model is activated by the Configuration Module 180 by instantiating a singleton instance of the IDataModelManager implementation class and registering it with the singleton Registry class. Upon instantiation, the singleton instance is passed in the entire data model configuration to a method defined in the parent class
AbstractDataModelManager. This method instantiates a singleton EntityManager instance for each entity class. The EntityManager is then passed in the configuration for each entity class for validation and further processing, including query processing. In addition to declared queries, the EntityManager also creates the implicit query FindByPrimaryKey, which returns a single instance of an entity class given the primary key, and related entity queries, which are used internally to load related entities, given the key value.
[0008] Working with the ORM Module
[00148] The IDataModelManager is the primary access point into the ORM Module. Users obtain a reference to an instance via the singleton Registry object. The
IDataModelManager provides the following methods:
[00149] Createlnstance(string, Euid): Creates an instance of an existing record, given the name of the entity and the primary key.
[00150] Create(string): Creates an anonymous or new instance of an entity.
[00151] FindByPrimaryKey( string, Euid): Given the entity name and primary key, loads and returns an instance of the entity class.
[00152] Fetch(string, string, Dictionary): Runs a named query declared in the configuration. It accepts as parameters the entity name, query name and the arguments for the query.
[00153] GetPicklist(string, string): Given an entity and field name, returns the list of key-value pairs for a Picklist type field.
[00154] CreateQueryContext(string, string): Returns a query context given an entity name and the query name. QueryContexts are used to run paged queries where results are retrieved from the persistence system in batches.
[00155] Create Save Context(): Creates an instance of I Save Context (in the Save Context module 440).
[00156] SystemCall(string, BaseEntity, Hashtable):This method is used to invoke business operations directly in the underlying persistence system.
[00157] bool HasField(string entityName, string fieldName): Metadata access method that returns whether a certain field is defined in a BaseEntity derivative.
[00158] Type GetFieldType (string entityName, string fieldname): Metadata access method that returns the Type of a field defined in a BaseEntity derivative. [00159] bool HasRelationship(string parentEntityName, string relationName):
Metadata access method that returns whether a certain relationship is defined fin a BaseEntity derivative.
[00160] string GetRelatedToByRelationName(string parentEntityName, string relationName): Metadata access method that returns the related BaseEntity derivative, given a relationship name.
[00161] Types. Connector. TYPE GetRelationshipCardinality(string parentEntityName, string relationName): Metadata access method that returns the cardinality (one-to-many, many-to-one) of a relationship defined in a BaseEntity derivative.
[00162] List<String> GetFieldNames(string entityName)
[00163] List<String> GetRelationNames(string entityName)
[00164] Figure 9 is a sequence diagram for execution of a non-paged query against a third-party application platform 190 or 192, according to one embodiment of the disclosed technologies. At 910, a fetch request is made to data model management module 410 for records related to an entity. At 912, the data model management module 410 determines the entity manager responsible for managing the lifecycle of the entity. In one embodiment, the determined entity manager, i.e. entity management module 420, receives 914 a fetch request for the records related to the entity it manages. At 916, the entity management module 420 looks up the query information related to the entity. In one embodiment, the query information is syntactically agnostic of the underlying persistence system 190 or 192. The entity management module 420 then determines 918 the Persistence Manager, also referred to herein as a persistence management module 430, for handling this fetch request for records related to the entity. In one embodiment, there may be multiple persistence managers, e.g. Persistent Management Modules 430, and each persistence manager may manage queries that may be performed on a specific persistence system 190 or 192. In one embodiment, the persistence system may be a cloud-based database 192. In another embodiment, the persistence system may be an on-premises third-party application platform.
[00165] Upon determining the appropriate persistence manager for handling the query,
Entity Management module 420 sends 920 a request to the determined Persistent
Management module 430 to run the query. Upon receiving the request, Persistence
Management module 430 will parse the query and generate a query native to the persistence system 190 or 192. Persistence Management module 430 will then send 924 request to the persistence system 190 or 192 to execute the generated native query. Persistence system 190 or 192 will process the request and return 926 the query results for the requested records. For each query result, Persistence Management module 430 will send a request 928 to the Entity Management Module 420 to create a base entity instance for the query result. The Entity Management Module 420 returns 930 the created base entity instance to the Persistence Management module 430 to populate the base entity instance. The Persistence Management module 430 populates 932 each base entity instance created from each query result and returns 934 the list of entities or records to the Entity Management module 420. Finally, the Entity Management module 420 returns 936 the list of entities or records to the Data
Management module 410 which returns 938 the list of entities to the caller. In one embodiment, the caller may be the Providers and Executors module 130 responsible for the co-ordination of application data management between the Web engine 120 and the
Application Providers module 140.
[00166] Figures 10A-10B are sequence diagrams for execution of a paged query against a third-party application platform, according to one embodiment of the disclosed technologies. Sequence 1000 may begin where a request 410 is sent from the Providers and Executors module 130 to Data Management module 410 to create a query context. A query context is a container and processor for a paged query. Upon creation, it is passed in an instance of a Querylnfo object whose results may be retrieved in batches so as to not overwhelm the memory of the server. It provides the following methods:
[00167] Integer Run(OrderBy, Dictionary<string, object> args): This method breaks up the Querylnfo into two queries - one to retrieve the list of primary keys for the BaseEntity instances that match the PREDICATE for the query (any configured sort order may be overridden by the OrderBy passed into this method) and two to retrieve the actual BaseEntity instances that match a list of primary keys. The first query is run and the results stored in the QueryContext instance as a list of integer-indexed Euid objects.
[00168] BaseEntity[] Fetch(Integer from, Integer to): Returns the list of BaseEntity instances that match the primary keys indexes in the query context stored as a result of the Run() call.
[00169] In response to the request, Data Model Management module 410 determines 1012 the appropriate Entity Manager for this request, retrieves 1014 the query information, and determines 1016 the Persistence Manager. Given the Entity Manager, query information, and Persistence Manager, the Data Management Module 410 then sends 1018 a request to the determined Persistence Management module 430 to create 1018 a query context. The Persistence Management Module 430 processes the request and returns 1020 the query context to the Data Management Module 410. The caller may then call 1022 a Run() request against the Query Context module 460 using arguments for the query. In response, Query Context module 460 sends a request 1024 to Persistence Management Module 430 to retrieve identification numbers or codes (IDs) of an entity or object in persistence system 192.
[00170] Upon receiving the request for IDs, Persistence Management Module 430 generates 1026 a query native to the persistence system 192 for which it manages persistence operations. When the native query is generated, Persistence Management Module 430 sends a request 1028 to the persistence system 192 or 190 to execute the native query. In one embodiment, cloud-based database 192 will process the request and return 1030 the query results to Persistence Management module 430. Persistence Management Module 430 then returns 1032 the IDs to Query Context Module 460. Query Context module 460 returns 1034 a row count based on the received IDs to the caller. After the Run() call, a list of primary keys, IDs or Euid objects is retrieved. The return value is simply the count of primary keys. The sequence 1000 may now proceed with the caller sending 1036 a fetch request for pages based on the row count to the Query Context module 460. In response, Query Context module 460 sends 1038 a request to Persistence Management Module 430 to fetch the pages using the retrieved IDs. Persistence Management Module 430 generates 1040 a query native to the appropriate persistence system 192 and sends 1042 the native query to the persistence system 192 to execute. In one embodiment, cloud-based database 192 processes the request and returns 1044 the query results to its Persistence Management module 430 to Query Context module 460.
[00171] For each query result that is returned, Persistence Management module 430 sends a request 1046 to the Entity Management Module 420 to create a base entity instance for each result. Entity Management module 420 then sends 1048 the base entity instance for each result record to Persistence Management module 430. Persistence Management module 430 populates 1050 each base entity instance received and returns 1052 a list for the entities to the Query Context Module 460. Query Context module 460 will re-order 1054 the list based on a sort information order procedure. Finally, Query Context module 460 returns 1056 the list of the entities back to the caller.
[00172] Figure 11 is a sequence diagram for execution of a basic, single-entity record create operation against a third-party application platform, according to one embodiment of the disclosed technologies. The sequence may start with a Save() call 1 110 on a base entity being sent to Base Entity module 450 to create an instance of an entity. In response, Base Entity module 450 sends a create() call 1 1 12 to Entity Management Module 420 to create a new instance of the entity. In one embodiment, the Base Entity Module interprets the Save() call as a request to create a new instance of an entity. In another embodiment, the Base Entity Management Module 420 interprets the Save() call as a request to update or modify an instance of an entity (see discussion of Fig. 12). In response, Entity Management decomposes 1114 the object, determines 1116 the Persistence Manager, and makes a call 1118 to the determined Persistence Management module 430 to create an instance of the entity. In a BaseEntity instance (or derivative), data fields are stored as instances of ManagedType type. In a decompose operation, the ManagedType field values are broken down to basic types (integer, decimal etc) or to the simplest type possible (a key-value pair of a name and value for a PicklistType for example), pushed into a Hashtable that maps the persistent field names (specified in the FieldDescriptor object set on the BaseEntity instance) and the value of the ManagedType and returned. This is only done for any fields that have been modified or newly set. Persistence Management module 430 generates 1120 a create request native to the persistence system 192 to which is manages persist operations and sends 1122 the native create request to the persistence system for execution. The persistence system, e.g. cloud-based database 192, processes the request and returns 1124 results of the entity to the persistence management module 430. Persistence Management module returns the entity's unique ID (EUID), including the entity's primary key to Entity Management module 420. Entity Management module 420 sends an AfterCreate() request 1128 to the Base Entity Module 450 for clean-up operations after the entity has been created and returns the entity results to Base Entity Module 450. The sequence concludes with Base Entity module 450 returning 1130 the results of the entity to the caller.
[00173] Figure 12 is a sequence diagram for execution of a basic, single-entity record update operation against a third-party application platform, according to one embodiment of the disclosed technologies. The sequence begins with a Save() call request 1210 on a base entity being sent to Base Entity module 450 to update an instance of an entity. In one embodiment, the Base Entity Module 450 keeps tracks of the entities and therefore knows that this Save() call 1210 is for an update operation, as the entity already exists. In response, Base Entity module 450 sends an Update() call 1212 to Entity Management Module 420 to update an instance of the base entity. In response to the request to update, Entity
Management Module 420 decomposes 1214 the object, determines 1216 the Persistence Manager, and makes a call 1218 to the determined Persistence Management module 430 to update the entity in the persistence system. Persistence Management Module generates 1220 an update request native to the persistence system 192 and sends 1222 the native update request to the persistence system 192 for execution. Persistence system 192 processes the update request and returns 1224 results to Persistence Management module 430. Persistence Management module 430 returns 1226 the results to Entity Management module 420. Entity Management module 420 sends an AfterUpdate() request 1228 to the Base Entity Module 450 for clean-up operations after the entity has been updated and returns the results to Base Entity Module 450. The sequence concludes with Base Entity module 450 returning 1230 the results of the update request to the caller.
[00174] Figure 13 is a sequence diagram for execution of a basic, single-entity record delete operation against a third-party application platform, according to one embodiment of the disclosed technologies. The sequence begins with a Delete() call request 1310 being sent to Base Entity module 450 to delete an instance of an entity. In response, Base Entity module 450 sends a Delete() call 1312 to Entity Management Module 420 to delete the instance of the entity. In response to the request to delete, Entity Management Module 420 determines 1314 the persistence manager, and makes a call 1316 to the determined Persistence
Management module 430 to delete the entity in the persistence system. Persistence
Management Module generates 1318 delete request native to the persistence system 192 and sends 1320 the native delete request to the persistence system 192 for execution. Persistence system 192 processes the update request and returns 1322 results to Persistence Management module 430. Persistence Management module 430 returns 1324 the results to Entity Management module 420. Entity Management module 420 sends an AfterDelete() request 1326 to the Base Entity Module 450 for clean-up operations after the entity has been deleted and returns the results to Base Entity Module 450. The sequence concludes with Base Entity module 450 returning 1328 the results of the delete request to the caller.
[00175] Figures 14A-14B are sequence diagrams for execution of a mixed mode
(create, update, delete combined in a single batch) bulk save operation, according to one embodiment of the disclosed technologies. The sequence begins with a request 1410 being sent to Data Model Management Module 410 to create a save context object. Data
Management module 410 returns 1412the save context to the caller. A request 1414 to register an instance of a base entity is then sent from the caller to Save Context Module 440. In response Save Context module 440 adds 1416 the entity to a collection of candidates. A request 1418 is then sent to the Base Entity Module 450 to mark the entity for a specific operation to be performed, e.g. create, update, or delete by calling Save() or Delete(). The steps of registering the entity and mark the entity for a specific operation may be repeated as needed. The caller then sends a request 1420 to Save Context Module 440 to commit the operation on the entity. At 1422, Save Context Module 440 re-orders 1422 the candidates of the collection and sends a Save() request 1424 to Data Model Management Module 410 to save the candidates. Data Model Management Module 410 then determines 1426 the persistence manager and sends a Save() request 1428 to the determined Persistence
Management Module 430 to save the candidates. Persistence Management module 430 sends a request 1430 to Entity Management Module 420 to decompose each object. For each base entity, Entity Management module 420 send a request 1432 to Persistence Management Module 430 to return modified values. For any batch size that is equal to a count, Persistence Management Module 430 generates 1434 native create, update, and delete batch requests and sends a request 1436 to persistence system 192 for execution of the generated requests. Persistence system, e.g. cloud-based database 192, returns 1438 results to the Persistence Management module 430. For each result returned, Persistence Management module 430 creates 1440 a bulk operation result and sends a request 1442 for either of an AfterCreate(), AfterUpdateO, or AfterDelete() call for clean-up operations and Persistence Management System returns to Base Entity module 450. Persistence Management Module 430 further returns 1444 the result of the bulk operation to Data Model Management module 410. Data Model Management module 410 returns 1446 the bulk operation results to Save Context Module 440. Finally, Save Context Module 440 returns 1448 the bulk operation results to the caller.
[00176] The Administration (Admin) Module 150 provides user administration and authentication functionality. User information is stored in the underlying third-party application platform, i.e. persistence system 190 or 192. The Admin Module 150 includes a hidden data model definition that is not accessible outside of this module. The Admin Module 150 provides implementations for the various different authentication schemes that the development platform 108 provides.
[00177] Figure 18 is a block diagram of one embodiment of a rules engine 160 for defining conditions that may be evaluated against objects. The Rules Engine Module 160 provides an API to define declarative conditions that are persistently stored via the ORM module 170. In one embodiment, these conditions may be evaluated against objects that implement a specific interface (IOperand)- also referred to herein as Operand Module 1860- and the Rules Engine Module 160 returns whether the object or set of objects pass or fail the condition. In one embodiment, conditions may be defined as a string combination of expression statements, held together by the conjunctions 'AND' and 'OR' together with braces '(' and ')' for grouping the expressions. Each expression in an expression-set associated with a condition is identified by a unique whole number. An example of a condition string with four (4) expressions would be "{ 1 } AND ({2} OR ({3 } AND {4}))". To evaluate a condition on an IOperand object, the Rules Engine 160 generates code for a class that extends a ConditionEvaluator class, also referred to herein as Condition Evaluator Module 1850, for overriding the abstract Evaluate() method. In the body of the method, the condition string is inserted, with the expression numbers replaced with calls to
EvaluateExpression using that specific expression. This class is then compiled dynamically into native binary for fast execution, using a programmatic API into the language-specific compiler the Rules Engine module 160 is implemented in. The condition evaluators are cached for re-use.
[00178] The Rules Engine 160 includes several modules or engines for carrying out its functions, including Rules Processor module 1810, Compiler module 1820, Rules
Administrator module 1830, Rule Set module 1840, Condition Evaluator module 1850, and Operand module 1860.
[00179] Rules Processor module 1810 module manages a set of conditions contained in a RuleSet. It is also the primary access point into the Rules Engine. It provides three methods:
[00180] Bool Evaluate (IOperand, Condition): returns true if the IOperand instance matches the Condition
[00181] IOperand[] Filter(IOperand[], Condition): Returns the sub-set of the IOperand instances that match the Condition.
[00182] IOperand[] ReverseFilter(IOperand[], Condition): Returns the sub-set of the IOperand instances that does not match the Condition.
[00183] Compiler module 1820 is responsible for compiling the generated code into machine-executable, binary code specific to the machine platform and runtime environment the application is running in.
[00184] Rules Administrator module 1830 is responsible for validating changes made to a RuleSetModule instance (together with the RuleSet, and its constituent Condition and Expression objects). It checks for syntactic and semantic correctness and the relational integrity of a Rule Set Module instance and its constituents.
[00185] Rule Set module 1840 is the persistent representation of a RuleSet and its constituents. It comprises of a single RuleSet instance and multiple Condition and Expression instances. [00186] Condition Evaluator module 1850 includes an abstract class ConditionEvaluator that forms the base class from which the generated Evaluator classes are generated. It provides an API to call to evaluate a Condition against an lOperand instance.
[00187] Operand module 1860 defines the API calls that must be defined by an object for the RulesEngine to be able to evaluate conditions against it.
[00188] Figure 19 is a sequence diagram for generation of condition evaluators and an evaluation of a condition, according to one embodiment of the disclosed technologies. The sequence 1900 may begin with Rules Processor module 1810 receiving a request 1910 to evaluate a condition against an object or set of objects that implement an interface (lOperand) to determine whether the object or set of objects pass or fail the condition. The request is passed in one (for the Evaluate() call) or more (For the Filter() and ReverseFilter() calls) lOperand instances. In response for the received request, the Rules Processor module 1810 will look-up 1912 or determine appropriate evaluator for the provided condition. If the Rules Processor module 1810 determines the evaluator is not in cache, the Rules Processor 1810 will proceed to generate 1914 an evaluator class for the condition. It parses the
ConditionString in a Condition instance, linking the tokens in the string to the Expressions in the Condition, generating the conditional expression to evaluate the Condition based on these two sets of input. In one embodiment, the generated evaluator class may implement one abstract method which allows for parsing a condition string. The Rules Processor 1810 will then send a request to Compiler module 1820 to compile the evaluator class. The Compiler module 1820 will then return 1918 the results back to the Rules Processor 1810. The sequence may proceed with the Rules Processor 1810 activating and instantiating 1920 an evaluator object of the evaluator class that has been generated and storing 1922 the evaluator object in cache.
[00189] The sequence 1900 may then proceed with the Rules Processor 1810 sending a request 1924 to Condition Evaluator 1850 to evaluate the condition against the object that implements the interface lOperand. In this step of the sequence, the generated class is invoked to evaluate the condition against the lOperand instance. The variables in each Expression that the Condition includes are extracted from the lOperand instance via the methods that this interface provides. In response to the request, and for each expression in a condition, Condition Evaluator 1850 will look-up 1926 the expressions in the condition. Condition Evaluator 1850 may then send a request 1928 to Operand module 1850 to retrieve values from the interface lOperand. Operand module 1860 will return 1930 the requested values. Next, the Condition evaluator 1850 will evaluate 1932 the expression for lOperand. Finally, the Condition Evaluator 1850 will return 1934 the results of the evaluation to the Rules Processor 1810, and the Rules Processor 1936 will return 1936 the evaluation results of the evaluation back to the caller. For an example, consider a simple use case of checking if the name of a company is either an empty string or null. The company may be represented by an Account object, an IOperand derivative, with the name of the company stored in a field variable called CompanyName. The Account object implementation of the
GetFieldValue(string fieldname) will return the company name (the value of the
CompanyName field), given the value "CompanyName" for the fieldname in the call above. It will also return the string "Account" for the IOperand method call GetName(). The Condition may have for the condition string the value "{ 1 } or {2}". The token "{ 1}" represents and Expression object that has the following attributes - (Entity = "Account", Field = "CompanyName", Operator = "Equal", Value = "") and the token "{2}" represents and Expression object that has the following attributes - (Entity = "Account", Field = "CompanyName", Operator = "IsNull"). Both Expression object are linked to the Condition object. When the RulesProcessorModule is sent the Account object and the Condition object in an Evaluate() call, it checks to see if a generated Evaluator object exists for that condition. If one is not found, an Evaluator class is generated and cached for future use (process described above). An instance of the Evaluator class is then created and the Account object passed to it. The Evaluator object then looks at the first expression represented by the token { 1 }, verifies that the object passed in matches the Entity value ("Account" here), retrieves the "CompanyName" value from the object via its GetFieldValue() method and executes the Operator on the field value thus obtained and the Value specified in the Expression object. If the expression evaluates to true, the second expression is skipped (because the conjunction in the ConditionString is "or") and a "True" result is returned. If the expression evaluates to false, the second expression is tested by the same process and the result of the test is returned.
[00190] Figure 20 is a sequence diagram for creation and retrieval of a rule set, validating a rule set and saving a rule set. The sequence 2000 may begin with the ORM engine 170 of development platform 108 receiving a request 2010 to perform an operation pertaining to a rule set. In one embodiment, the request 2010 may include creating a rule set. In another embodiment, the request 2010 may include retrieving a rule set. ORM engine 170 returns 2012 back to the caller the results of the request including the rule set. An example of a caller is the PositiveEdge CPQ application. The use case is validation of a Quote object - an IOperand derivative - for consistency before submission. A ruleset is defined with the DataModel set to the ORMModule name that represents the data model for the application. The RootClass is set to "Quote" and a set of Conditions are defined. If the Quote object passes the validation conditions, it is submitted otherwise not. Another example could be a work-flow implementation. Conditions are defined within a RuleSet and based on which condition(s) are met by an IOperand derivative, different actions may be taken by a calling application. The sequence may proceed to validate the created or retrieved rule set where the Rules Administration module 1810 receives a request 2014 to validate the rule set. In this step, checks for syntactic and semantic correctness and the relational integrity of a Rule Set Module instance and its constituents are performed. The following checks are made, shown here with the Error number and a description of what the error entails. The tokens {n} represent identifying information for the artifact - Condition or Expression - the error is for. No token for a RuleSet object is necessary because validations are performed one ruleset at a time:
[0009] Exceptions. E901 - "Name is required"
[0010] Exceptions.E902 - "Data Model is required"
[0011] Exceptions. E903 - "Expression {0} in condition is not defined"
[0012] Exceptions. E904 - "Expression {0} has illegal combination of
Aggregate and To-One relationship"
[0013] Exceptions. E905 - "Expression {0} is missing required Aggregate"
[0014] Exceptions. E906 - "Expression {0} has invalid relation name in field path"
[0015] Exceptions. E907 - "Expression {0} has invalid field name"
[0016] Exceptions. E908 - "Expression {0} field type does not match data model"
[0017] Exceptions.E909 - "Root Entity is required"
[0018] Exceptions. E910 - "Condition string does not have formatted
expression numbers"
[0019] Exceptions. E91 1 - "Invalid condition - unexpected conjunction"
[0020] Exceptions. E912 - "Invalid condition - incomplete phrase"
[0021] Exceptions.E913 - "Invalid condition - invalid conjunction or token"
[0022] Exceptions. E914 - "Invalid condition - missing conjunction" [0023] Exceptions. E915 - "Invalid condition - Illegal character at {0}"
[0024] Exceptions. E916 - "Invalid condition - Mismatched parenthesis"
[0025] Exceptions. E917 - "Invalid condition - Incomplete syntax"
[0026] Exceptions. E918 - "Data model not defined"
[0027] Exceptions. E919 - "Root class does not exist"
[0028] Exceptions. E921 - "Expression {0} has operator that does not match field type"
[0029] Exceptions. .E922 - "Expression {0} only Date types are allowed
functions"
[0030] Exceptions. .E923 - "Expression {0} has illegal aggregate function"
[0031] Exceptions. E924 - "No conditions in ruleset"
[0032] Exceptions. E926 - "Field value in expression {0} does not start at root object"
[00191] If no errors are found during the validation, Rules Administrator module 1830 sends a request to the Rule Set module 1840 to set the rule set as active. In one embodiment, the Rule Set module 1840 an active RuleSet object indicates to a caller that it is safe to use - i.e. there are no current edit actions being performed on the RuleSet and its constituents and that the RuleSet and its constituents have been validated by the RulesAdministratorModule. The results 2020 are then returned back to the caller. The sequence may then proceed to send a request 2022 to the ORM engine to save the rule set and its conditions and expressions to the persistent system 190 or 192. In one embodiment, the rule set and its conditions and expressions may be saved to a cloud-based database 192. In another embodiment, the rule set and its conditions and expressions may be saved to a traditional on-premises database 190. The ORM engine returns 2024 results of the request back to the caller.
[00192] The terms "embodiment" and "implementation" are used interchangeably throughout this application to refer to one example and of the system and method of the present invention. Reference in the specification to "some implementations," "an implementation" "some embodiment," or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the implementation is included in at least some instances of the description. The appearances of the phrase "in some implementations" in various places in the specification are not necessarily all referring to the same implementation.
[00193] Some portions of the detailed description are presented in terms of processes and symbolic representations of operations on data bits within a computer memory. These symbolic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. A process is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers or the like.
[00194] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
[00195] The specification also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may include a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a non-transitory computer readable storage media, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, flash memories including USB keys with non-volatile memory or any type of media suitable for storing electronic instructions, each coupled to a computer system bus.
[00196] The specification can take the form of an entirely hardware implementations, an entirely software implementation or implementations containing both hardware and software elements. In some implementations, the specification is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
[00197] Furthermore, the description can take the form of a computer program product accessible from a computer-usable or computer-readable media providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable media can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
[00198] A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
[00199] Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers.
[00200] Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or social network data stores through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
[00201] Finally, the processes and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the specification is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the specification as described herein.
[00202] The foregoing description of the implementations of the specification has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the specification to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the disclosure be limited not by this detailed description, but rather by the claims of this application. As will be understood by those familiar with the art, the specification may be implemented in other specific forms without departing from the spirit or essential characteristics thereof. Likewise, the particular naming and division of the modules, routines, features, attributes,
methodologies and other aspects are not mandatory or significant, and the mechanisms that implement the specification or its features may have different names, divisions and/or formats. Furthermore, as will be apparent to one of ordinary skill in the relevant art, the modules, routines, features, attributes, methodologies and other aspects of the disclosure can be implemented as software, hardware, firmware or any combination of the three. Also, wherever a component, an example of which is a module, of the specification is implemented as software, the component can be implemented as a standalone program, as part of a larger program, as a plurality of separate programs, as a statically or dynamically linked library, as a kernel loadable module, as a device driver, and/or in every and any other way known now or in the future to those of ordinary skill in the art of computer programming. Additionally, the disclosure is in no way limited to implementation in any specific programming language, or for any specific operating system or environment. Accordingly, the disclosure is intended to be illustrative, but not limiting, of the scope of the specification, which is set forth in the following claims.
APPENDIX A
APPENDIX A
APPENDIX A
Introduction
The PositiveEdge Keystone platform is a configurable development platform intended to facilitate rapid application development that integrates with Microsoft Dynamics CRM and Salesforce. The term "persistence system" will be used in this document, going forward to refer to either of the above two platforms. Given the same data model, there are virtually no code changes required to port a connected application developed for the Salesforce platform to Microsoft Dynamics CRM and vice-versa. The platform provides a well-defined API with predictable behavior for an application to interact with the platform, enabling application developers to focus on implementing business functionality instead of on system functionality essential to any robust, scalable, perforraant and secure enterprise web-enabled application. The piatform provides the following features:
Multiple user authentication options - standard, SAMLv2 SSO, WS-Federation, Active Directory
Built in XSS and XSRF protection
Simultaneously access and operate against multiple, heterogeneous persistence systems within the same application
Declarative query definition syntactically agnostic of underlying persistence system
Identical API for CRUD operations, including bulk operations, agnostic of underlying persistence system
Scalable, fast cache for optimized performance
Asynchronous execution of long-running tasks
Template-enabled email notification feature
Ui widgets that map directly to persistence system data types
Composite Ul components representing HTML forms, tables and trees
Declarative internalization support
Custom Ul "skinning"
UI Layout memory
APPENDIX A
The diagram above illustrates the modules of the Keystone platform and their dependencies. The modules are described in more detail below. The blue arrows indicate the direction of the dependency and points away from the user of the module. An application deployed on the platform has two modules, shown in dash-outlined boxes and are not a part of the Keystone (e.g. the Atlas CPQ application). The dependency between the Providers and Application Providers is bidirectional and calls into the Application Providers are executed via references obtained using reflection, a feature of all modern programming languages - hence the dotted arrow. This approach prevents a circular dependency from occurring between the two modules. The Application Web module the second piece of an application deployed on the platform lives within the Web module. Each of the Keystone platform modules are described in more detail below. Each of the modules and the services it provides transition from initialization, active and shutdown phases, in the initialization phase, services acquire the resources to operate; in the active phase the service is ready to receive messages and process requests; and in the shutdown phase, the sendees release resources before de-activation.
The Core Module provides system functionality and is one of two modules that is used by all other parts of the platform as well as deployed applications. The services provided by this module are- described below.
This service is used to encrypt and decrypt passwords and certain configuration values that may have embedded passwords, e.g. connection strings. It is a singleton with two static methods - Enerypti(), which takes a raw string and returns a base-64 encoded encrypted string and Decryptij, which takes an encrypted base-64 string and returns the raw string.
This service examines the validity of the license granted to the application deployed on the platform and raises an error if the check fails, it also ensures that the application is deployed to the same DNS name the license was assigned to, that the current date falls within the license data validity period for every web request received by the platform and when users are added, that the total user count does not exceed the maximum defined by the license.
A high-performance 0(1) cache for storing frequently used data, it uses a hash map to store keyed information backed by an LRU linked list of entries to pick candidates for eviction when a cache instance reaches capacity. Each instance of the cache also takes a TTL value for cache entries. However, the value is lazily checked - i.e. an entry is only checked for expiration upon access of that entry. Each instance of the cache also accepts a callback object that is notified whenever an entry is removed either because the entry expired or because the cache reached capacity (but not if the entry is intentionally removed), it automatically tracks cache hits and misses to aid performance tuning. The methods provided by this service are:
● Object Get(object k)
● Setfobject k, object v) APPENDIX A
● Remove(object k)
● integer Accesses(): The number of times the cache was accessed
● integer Hits(): The number of times an entry matching the key was found
● integer Size(): The current number of entries in the cache
The object used as the key must define consistent Equals() and Hashcode() methods.
Asynchronous logging API to minimize the impact of logging on performance. The service automatically rolls over log files upon reaching a size of 2MB. It consists of a singleton with static methods. The Logger maintains a FIFO queue of logging messages passed to one of the Log methods exposed by this service. A message is defined as a single string or a single string and an accompanying Exception or Error object with stack trace, A single background thread reads messages off of the queue and writes the messages to the log file asynchronously. Before each write, the number of bytes written to the log file is checked and if it exceeds the 2MB limit, renames the current log file with an appended timestamp and creates a new file. A single log message does not span multiple log files. The two Log messages provided by this service are:
● Initf(): Called during module initialization. At this time, the Logger acquires a handle to the log file and starts the background logging thread.
● Log(string m) : Adds the message to the logging queue
● Log(string m. Exception e): Adds the message to the logging queue together with an error
● Close(): Called during module shutdown. The Logger releases the handle to the current log file and terminates the background logging thread.
The Email Service provides bi-directional communication with a configured email server. Outbound emails (via SMTP) is initialized from configuration parameters provided via the Configuration Module, Such emails are tern plate- based with data filled in by a specific application-specific provider (please see the Providers Module section for more on providers). Handling inbound email requires an active mailbox on the email server that this service can monitor (only P0P3 supported at this time). Users of the service is allowed to register a single callback object with this service that gets notified each time a new email is received. The service leverages the Work Manager Service (please see below) to ping the mailbox at periodic intervals. This feature is only activated if a callback object is registered. The service provides the following methods:
● SendMail (string tpl, strmg[] to, MaiiContent data): Send an email using specified template and provided data for the template, to provided set of email addresses
● SendMail(string tpl, string[] to, MaiiContent data, bool async): Same as above, except the email is sent out asynchronously if async is true. This feature leverages the Work Manager Service to dispatch the email. Composition of the email is performed synchronously,
● RegisterCaliback(lCallback cbk): Register a callback object to be notified when an email is received. APPENDIX A
A service that allows applications to run long-running tasks asynchronously, it holds a pool of threads that wait in the suspended state until it is notified of pending work and a FIFO queue onto which users of the service push work. The number of threads in the pool is configurable and provided by the Configuration Module, Upon initialization, the Work Manager Service creates the configured number of threads and adds them to the pool. Upon creation, they immediately go into a wait state on a common monitor. Users of the service push implementations of the IVVork interface to the Work Manager. This interface declares a single Process() method. Upon receiving the work object, it is pushed to the FIFO queue and the threads are notified. The threads then compete and one of them gets to dequeuer the work object and invoke the Process() method. Once the Process() method returns, the thread returns back to a wait state. To shut down the service, the Work Manager Doneij method is invoked. This enqueues a special implementation of the IWork instance - one for each thread in the thread pool. Once each thread dequeues this special instance, it shuts down. This allows each thread to complete any pending work before terminating. Methods provided by this service are:
● Add(IWork w) : To add work to the Work Manager
● Wait(): Pauses all threads. In-flight work will be completed, but no new work will be dequeued
● Done-() : Shuts down the Work Manager. This method is intended for system use only.
The Security Manager Service is installed as an HttpModule (note that such a configuration setting is ilS-speeific, but all other web servers have an equivalent feature). It intercepts all requests and verifies it for authorized access. The service makes the following checks:
● Unauthenticated access: If detected the request is re-directed to the appropriate login handler
● Unauthorized access: If access to protected or internal access is requested (e.g. the configuration file), access is denied via a 401 HTTP response
● Unauthorized access method: Access to SOAP endpoints via HTTP Gets are disallowed.
● Unauthorized access role: Access to the Admin SOAP endpoints are disallowed for users that do not have the Administrator role.
The service also provides XSRF protection by generating a one-time random token generated when the user logs in that is supplied to the Web Module containers (please see the Web Module section). This token is required to be sent back for every HTTP request either as an HTTP header, a query parameter or as a form value. If the offered token value does not match the one generated for the user, access is denied via a 401 HTTP response.
Finally, this service calculates whether a user has the appropriate role to access or perform a particular operation on a particular field or column, a composite Ui component or a page (please see the Web Module section for definitions of these terms). The service however does not automatically detect attempts to access such artifacts - the service must be invoked pro-actively to calculate access. This invocation occurs from the Provider Module. By default the implementation is open - all user roles have read and write access to every thing. Each of the artifacts listed above can APPENDIX A be protected by defining a permission setting per role in configuration. Depending on the type of artifact, each role may have one of DENIED, UNRESTRICTED or READONLY access types. Artifacts that are not naturally vvriteable (composite UI components or toolbar controls e.g.) are not allowed to have a READONLY access type.
The methods this service provides are:
• Permission.ACCESS Adjudicate(Permission[] permissions) : Given a set of permissions attached to a particular artifact, return the type of access - UNRESTRICTED, READONLY, DENIED - granted for the current user's role.
User Service
The user service provides some pertinent information about the logged in user. These attributes are typically user information stored in the backend persistence system and retrieved and stored in the HTTP Session object after a successful login. The methods provided by this service are:
● G uid GetUserPk() : Returns the primary key for the current user's record
● String GetLoginid(): Returns the login id for the current user
● String GetiiserRolefJ : Returns the current user's role
● String GetUserName(): Returns the full name of the current user
● String GetUserEmail(): Returns the current user's email address
This module informs the Keystone platform with all of the metadata about the application deployed on the platform. This metadata allows the platform to interact with the application as and when necessary. The configuration is stored in an XSD schema based XML file that lives within the Apphcation Web part within the Web module. Most of the details given below are explained in other sections. The metadata consists of the following parts:
● Application Settings: The web page application header and footer style, the Work Manager thread pool size, the view class, application toolbar, supported languages (internationalization), apphcation and session initializers, supported authentication schemes, one or more named persistent systems used by the application and email server configuration.
● Page Definitison: Each application deployed on the platform consists of a set of pages. Each page consists of one more combinations of toolbars, forms, tables and trees, which in turn consist of widgets fields and columns - and controls buttons, dropdowns etc. This section defines the composition of each page in the apphcation. Each of the composite UI components - forms, tables and trees - is linked to a Data P-rovider.
● Data Providers: This section specifies the classes that implement interfaces defined in the Providers module and live in the Apphcation Providers module.
● Picklists: These are definitions of List of Value fields, also called Picklists, one of the field types that may be used in forms and tables. The configuration allows to link these fields directly with fields on the data model in the persistence system. The configuration also allows overriding/replacing or excluding certain values from a particular picklist field, APPENDIX A
● Lookups: Lookups are another type of fields that represent reference types - a pointer to a specific instance of an entity or a specific record in the data model. This section defines the various types of lookups used in the application.
● Data Models; This is where the data models that form the glue between the ORM module and the Application Providers module is defined. The section consists of the set of entities that comprise the data model and for each entity, the queries that may be run against it.
This is the face of the deployed application to the external world. The Web Module hosts the containers - the vehicle on which the pages that comprise the application is delivered to a user's browser, among other artifacts. This is the largest module in the platform. An application hosted on the platform is a single-page web application when viewed from a client perspective. Containers host a set of pages, derived from the page definitions defined in the Configuration Module. There are two containers provided by default -- a multi-page container and a single- page container. The multi-page container is intended for access via an independent URL. The single-page container is intended to be embedded in a third party web application, which may also be Microsoft Dynamics CRM or Sa!esforce.
The diagram above shows the parts of the Web module. The foundation of the user interface (UI) is the third-party javascript library ExtjS, The Web module includes wrappers around this library that exposes a uniform interface to create composite UI components, it also is a bridge between 111 events triggered from ExtjS to the Application Web jS event handlers. On the server-side, the Web module again provides application- agnostic AJAX/JSON endpoints whose methods represent standard operations that may be performed on a composite Ui component - e.g. load, save, update etc. The Web module interacts with the server-side application implementation (the Application APPENDIX A
Providers Module) via the Providers Module, The sub-sections below discuss various parts in more- detail.
All web requests that arrive at the Web Module go through the Security Manager Service. When a request arrives from an uiiauthenticated user, The Security Manager Sendee redirects the request to the Login.aspx web page. Login.aspx checks for the configured authentication scheme with the Configuration Module. Depending on the authentication scheme, Login.aspx invokes the appropriate method in the Admin Module or re-directs again to an authentication provider if an SSO scheme is configured. The authentication options are:
● Standard: This is the default authentication scheme. The user supplies a username and a password and the admin module matches them against stored credentials in the persistence- system.
● SAML v2.0: in this scheme, the- admin module send out a SAML authentication request to the configured idP. The response is received by an HTTP handler SSOLogin.ashx.
● WS -Federation: This option is handled entirely by Login.aspx using the open source OWin library from Microsoft.
● Auto-Login: This is the same as Active Directory authentication. Login.aspx invokes the admin module to handle this.
● Microsoft Live id: Also handled via the admin module.
The platform also allows for definition of an application specific authorization provider via the Providers Module. After successful authentication and if any defined authorization provider allows access, the user is redirected to the original l!RL to which access was attempted. This is typically one of the web containers - Home.aspx or OneView.aspx.
UI Markup Generation
Once a web container is loaded onto a browser, the next step is to retrieve the Ul configuration. This is served up by the ConfigurationService AJAX end point and occurs in three steps for the multi-page container (Home.aspx) and in two steps for the single-page container (OneView.aspx). Home.aspx first pulls in the page level and summary information for pages that are configured for that container and that the user has permission to view in the first two steps. This summary information is used to generate the page toolbar, navigation tab and certain master data - in particular the- list of values for all configured picklists. individual page configuration is retrieved lazily in the third step when the user navigates to the page the first time. Each page definition in the configuration specifies a javascript layout function which is invoked to generate the markup for the page. This function is defined in the Application Web fS. The platform provides functions for creating various Ul components: grids, forms, toolbars and trees. These are then stitched together by the layout function into a single view. Once the layout for the page is rendered, the load function is called. Similar to the layout function, the load function is optionally specified in each page configuration. This function is intended to load data into the page. The load function interacts with controller scripts in the Web fS part of the Web Module, which in turn interact with the AJAX end points. APPENDIX A
This section describes the javascript APIs and components provided by the Web jS part of the Web Module, These are categorized into Main- Views, Controllers and Widgets.
Main-Views
The main view is the overall page layout There are two parts to each main view -- the navigation menu and the page section. The navigation menu lists out the pages available to the user. On clicking a particular page name, the page is presented to the user in the page section. There are two available main views - GTP, which lays out the navigation menu on the left in a tree structure with collapsible nodes and the page section on the right; and TAB, which lays out the pages in a tab layout with the navigation menu as tab headers. The main view to be used is configurable in config.xml.
Controllers
Controllers are wrappers around composite Ui elements grids, forms, charts, toolbars and trees. They provide a uniform API to create and manipulate these elements as provided by the underlying Extjs library. These are invoked from the application specific layout functions to create these various elements and arrange them on the page. The controllers also provide functions to manipulate the elements and the data they contain including but not limited to, clearing, loading, adding rows to, removing rows from, updating rows of grids, saving, creating and deleting data in forms, loading trees etc. The controllers automatically interact with the providers associated with grids, forms and trees via the AJAX end points as necessary to manipulate the data it displays.
Widgets
Widgets are the fields within the composite UI elements. Most are wrappers around fields provided by Extjs, Some are custom. Each of them have a corresponding server-side representation that they are transformed to when controllers interact with the providers. The widgets available are:
● Datetime: Represents a date time object. Currently only supports setting the date. Dates are always displayed in the user's time zone.
● Link: Read-only field that reacts to the click event to invoke an application defined javascript function. Used only in grids,
● Lookup: Compound field with dual triggers. One trigger clears the value. The second pops up a grid that allows the user to select a particular record and set it as a value. Used in forms and grids to represent a reference to a particular record.
● Money: Represents a monetary value, it has two parts - the currency and the amount. The value is displayed formatted with the currency symbol.
● Selection: Represents a field whose value is picked from a list of discrete values.
The AJAX End Points are the mechanism by which the web containers and the application web part communicate with the server. They are grouped together by function. The wire format is JSON and leverages the native serialization/de-serialization features of the ASP.NET platform. The services provided are: APPENDIX A
The User Management Service; This service is primarily used by the standard username/password challenge scheme. In this scheme, Keystone maintains username/password credentials in the persistence system, properly hashed, in addition to a method to authenticate the user given a username/password pair, it also provides methods to reset and change a user's password. This service is also used to track usage statistics, the metrics for which are defined by the application deployed on the platform.
The Configuration Service: The configuration service delivers page configuration data to the web containers, it provides three methods:
o Initialize: This is called when the web container is first loaded after the user logs in.
This is the first step in generating the page layout. It is passed in the user's metadata. This metadata is passed to any configured session initializer. The session initializer is given the opportunity to modify or add to the user's metadata. This method then retrieves all picklists and any page-level toolbar targeted to that web container. All of this data is then returned back to the web container and is made- available as global javascript objects in the web container,
o GetNavConfiguration: This is called to retrieve the page metadata that populate the web container and for the pages that the user has permission to access. The returned data from this method is used to create the navigation panel of the web container.
o GetPageConfiguration : This is called in the third step of web container layout to pull in all of the composite UI components that are contained in a page.
The Grid Service; Provides methods for grids to load data, remove, add and update rows. The methods are:
o Get: Accepts as parameters the starting and ending row number, the grid name, sort column, sort direction, filter string and the arguments used to retrieve data, returns a set of rows to populate the corresponding grid with data. Also accepts a refresh flag. If the flag is true, any cached data is purged and fresh data is loaded directly from the persistence system,
o Add: Accepts as parameters the grid name and a list of key-value pairs. Each element of the list represents a row to be added. Each set of key-value pairs represent the column name and the value to set for that field.
o Update: Accepts as parameters the grid name and a list of key-value pairs. Each element of the list represents a row to be updated. Each set of key-value pairs represent the column name and the value to set for that field. Null values must be explicitly specified. Absence of a column name implies that field will not be modified,
o Delete: Accepts as parameters the grid name and a list of key-value pairs. Each element of the list represents a row to be deleted. Each set of key-value pairs represent the column name and the value to set for that field.
All of the methods above pass the call on to the appropriate TableDataProvider (see the Providers Module) configured for the grid. Prior to this, the provider's CheekAccess() method is called to confirm the user has permission to execute that operation for the Add Update and Delete methods.
The Form Service: Provides methods for forms to load, remove, add and update data. The methods are: APPENDIX A o Get: Accepts as parameters the form name, primary key of the record to be shown, and the arguments used to retrieve data, returns a set of fields to populate the corresponding form with data. Also accepts a refresh flag. If the flag is true, any cached data is purged and fresh data is loaded directly from the persistence system. o Add: Accepts as parameters the form name and a set of key-value pairs. Each key- value pair represent the field name and the value to set for that field.
o Update: Accepts as parameters the form name and a set of key-value pairs. Each key-value pair represent the field name and the value to set for that field. Null values must be explicitly specified. Absence of a field name implies that field will not be modified.
o Delete: Accepts as parameters the form name and a set of key- value pairs. Each key- value pair represents the field name and the value to set for that field.
All of the methods above pass the call on to the appropriate FormDataProvider (see the Providers Module] configured for the form. Prior to this, the provider's CheekAecessfJ method is called to confirm the user has permission to execute that operation for the Add Update and Delete methods.
● The Tree Service: Trees are read-only as of this version. So this service provides a single- method to load data. Trees may be loaded one node at a time upon expansion of that node the first time. So this method accepts are parameters the tree name, the full path to return data for, the arguments to use for the search criteria and the refresh Hag.
● The Chart Service: Charts again are read-only components. Given the chart name, the arguments to be used for the search criteria and the refresh flag, returns the data to be used to populate a chart.
This module contains three categories of objects. The first category are data providers. These are- responsible for the co-ordination of application data management between the Web Module and the Application Providers module. All providers implement the IDataProvider interface (or one of its derived interfaces) and extend the BaseDataProvider class. The figure below shows the class diagram for this category of objects. Interfaces are in blue, abstract classes are in green, concrete- classes are in yellow. Line arrows represent inheritance, block arrows represent "uses".
APPENDIX A
Inherited from the iDataProvider, are four interfaces. Implementations of each of these interfaces manage data that is displayed in one of the four UI components. Al! concrete implementations of the providers inherit from the generic abstract class BaseDataProvider either directly or indirectly. The only exception is the special purpose provider, the AuthorizationProvider, which implements the IDataProvider interface directly.
All Application Data Providers that manage data made accessible to users via the grid or table UI component extend from the TableDataProvider class. The Get() method of this class returns an instance of TableData or PagedTableData or an instance of a class derived from one of these classes. This method typically interacts with the ORM Module, running configured queries to return the data that fit the search criteria passed in to the method as a list of key-value pairs. The interpretation of these key value pairs is left to the derived Application Data Provider. These instances in turn, provide methods to add, update and delete the data they contain. The difference between the TableData class and PagedTableData class is that the former loads the entire set of rows that fit the search criteria used which the PagedTableData retrieves a subset at a time, which aliows it to be much more scalable for iarge data volumes. The filter class is used by a TableData instance for ίη-memory filtering of rows.
Data that is displayed in forms is managed by classes that extend the FormDataProvider. The Get() method is implemented by an Application Data Provider class that returns an instance of a FormData derived class. The derived class declares the actual fields shown on the form.
Trees and Charts are read-only and Application Data Providers that manage such data implement the corresponding interfaces directly, implementations of the ITreeDataProvider interface are required to return an instance of TreeData whiie implementations of the IChartDataProvider are required to return an instance of ChartData.
The module also provides three special purpose providers. All of the special-purpose providers are accessible through well-known names. To override any of these providers in the Application Provider Module, an inherited class must be defined and registered with the well-known name with the Configuration Module:
● The PicklistDataProvider: This provider is registered under the name "PicklistDataProvider". Given the name of a picklist defined in the Configuration Module, it returns a list of key-value pairs to populate dropdowns in picklist type fields. The data for picklists can be retrieved in four different ways APPENDIX A o When it maps to a picklist type field defined on one of the objects in the persistence- system
o When it is mapped to a query defined in the data model configuration. This type of picklist contains a list of objects that match the query criteria specified, o When it is mapped to another provider that serves as a delegate that returns the picklist values. This is particularly useful when the rules to form the list of values is complex and can only be program matically achieved,
o When it is mapped to a list of values statically defined in the Configuration Module.
● The LookupListProvider: The LookupDataProvider, registered under the name "LookupDataProvider" is a simplified, read-only derivation of TabieDataProvider. This is invoked to populate the popup grid for lookup fields.
● The AuthorizationProvider: The AuthorizationProvider is registered under the name "AuthorizationProvider". This is called just after a user logs in passing in the user's metadata. The default implementation does nothing, but it can be overridden to deny access and/or to modify the user's metadata that is stored as a javascript global object in the web container.
● The AttachmentProvider: The AttachmentProvider is used to download and upload files as attachments to various objects that allow such functionality in the underlying persistence system, it is front-ended by the Attachments.ashx web handler in the Web Module and interacts directly with the ORM Module and does not require any application specific implementation.
At the heart of the Providers module is the DataProviderManager. This component reads the configured data providers from the Configuration Module and loads the implementations from the Application Providers Module by reflection and maintains a map of the names and implementation instances. Other modules - in particular the Web Module - request an instance of the implementation by name which then proceed to invoke operations on the providers to fulfill business functionality.
The second category of objects contained in this module are compound types that are the server- side counterparts of the Web Moduie widgets. These types implement the IFiiterable interface that allows for in-memory filtering. These are:
● Date: Represents a date time. Maps to the datetime widget.
● Link: Represents a link. This is an over-ridable type that can be customized to add additional data to the value. Maps to the link widget.
● Selection: Represents a key-value pair and maps to the selection widget.
● Lookup: Represents a referential field and maps to the lookup widget, it has three attributes: the primary key of the referenced object, a display name and the type of the referenced object, it may be extended to add additional application-specific attributes.
● Money: Represents an amount and currency pair and maps to the money widget
● Icon: This represents an image displayed in-line in grids. There is no corresponding widget in the Web Module, it uses a text field with a special renderer for display. An optional handler that is a javascript function invoked when the icon is clicked may be specified. A tooltip may also be optionally specified. APPENDIX A
The third category of objects in this module are initializers. There are two extensible initializer interfaces provided. The implementation class is specified in the Configuration Module. The first is the f Applicationinitializer, which provides a single no-arg method Initia!ize(). This is invoked from the Global. asax in the Web Module upon the Appiication_Start event. The second is the ISessionInitializer, which is invoked just after the user has logged in and during initialization of the web container.
The ORM Module provides persistence services, it exposes a consistent, coherent interface to other modules to interact with any persistence system - Microsoft Dynamics CRM version 4.0 through the latest 2015 release - online or on-premise, Salesforce and even a local RDBMS (currently only supports MS SQL Server). The ORM Module abstracts out any schema and the query language in a persistence system into generic forms with a well-defined mapping into actual persistence system types, it interacts with the persistence system using remote APIs defined by it
The ORM Module provides a hybrid implementation model. The basic premise is each table (in an RDBMS persistence system) or object (in Saiesforce) or entity (in Dynamics CRM) are mapped to an entity class. Each row or instance of an object maps to an instance of the entity class. The module provides specific compound types that map to field types in the persistence system. Each entity must also be defined in the Configuration Module, together with attributes that specify the cache- ability and most importantly queries against that entity class. Queries are defined deciaratively in the Configuration Module. Multiple data-model definitions are allowed, so long as the names are- unique. Each data-model is managed by an IDataModelManager interface implementation that provides methods for interacting with the entity class instances. References to the appropriate IDataModelManager instance are obtained from the singleton Registry class, given the name of the data model.
The following sections describe how entity classes are declared and defined, queries are declared and how the entity classes and queries are managed.
The data model definition has two parts - one specified in the Configuration Module, specifically in the config.xml and the other implemented as part of the Application Providers Module. Each entity class has to have a declaration in the config.xml with a name that is unique within that data model definition, in the Application Providers module, a class must be defined that directly or indirectly inherits from the BaseEntity class (defined in this module) for each of the entity classes, in addition, an implementation of the IDataModelManager interface that also extends the AbstractDataModelManager abstract class (also defined in this module) must be defined, that maps the entity name to the implementation class. This IDataModelManager implementation class is specified in the configuration. The entity implementation class is annotated with descriptors declared at the class level (the CRMDeseriptor) - to map the class to a corresponding persistence- system object/entity/table - and at the field/property level (the FieldDescriptor) - to map to a field in the persistence system object/entity/table, in addition referential fields - references or foreign key fields to other objects/entities/tables have to be annotated by the RelationshipDescriptor, Each of the descriptors have a name that is used as an identifier for that field or related entity in query definitions. For a referential field, the name of the FieldDescriptor and the RelationshipDescriptor must be the same, in addition, if the relationship is navigable bi-directionally, the corresponding APPENDIX A field on the other entity class must be annotated with a RelationshipDescriptor of the same name. The table below shows the mapping between field types defined in the ORM Module and types in the supported persistence systems, it also lists out the native type enclosed by the ORM Module field type.
To retrieve data from the persistence system, each entity class may be associated with one or more queries. No code needs to be written. Ail queries are declarative and adhere to a persistence system agnostic schema and defined in the Configuration Module. Each query defined must have a unique name, A query definition has two parts - the SELECT part and the PREDICATE part
The SELECT part defines the fields to be loaded into each instance of the entity class returned as a result of the query, ft also specifies fields from related entity classes that are loaded together with the primary entity. The number of such related entities specified in a query and the depth of nesting is only limited by the underlying persistence system.
The PREDICATE part defines the search criteria for the query. The unit of the criteria is an Expression declaration consisting of a field - related entity field path may be specified by a dot notation (e.g. CompanyContactFirstName) - an operator (Equal, NotEqual, Like, NotLike, LessThan, LessThanEqualTo, GreaterThan, GreaterThanEqualTo, In, NotIn, Null, NotNull) and either a hardcoded value or a parameter name (in which case it must start with an @). Expressions are nested within Condition declarations together with a Conjunction (And, Or), Each Condition declaration may have one or more Expression declarations and/or one or more nested Condition declarations.
Each data model is activated by the Configuration Module by instantiating a singleton instance of the IDataModelManager implementation class and registering it with the singleton Registry class. Upon instantiation, the singleton instance is passed in the entire data model configuration to a method defined in the parent class AbstractDataModelManager. This method instantiates a singleton EntityManager instance for each entity class. The EntityManager is then passed in the configuration for each entity class for validation and further processing, including query processing. APPENDIX A in addition to declared queries, the EntityManager also creates the implicit query FindByPriroaryKey, which returns a single instance of an entity class given the primary key, and related entity queries, which are used internally to load related entities, given the key value.
Working with the ORM M odule
The IDataModelManager is the primary access point into the ORM Module. Users obtain a reference- to an instance via the singleton Registry object. The IDataModelManager provides the following methods:
● Createfnstanee(string, Guid) : Creates an instance of an existing record, given the name of the entity and the primary' key.
● Create (string) : Creates an anonymous or new instance of an entity.
● FindByPrimaryKey(string. Guid) : Given the entity name and primary key, loads and returns an instance of the entity class.
● Fetch(string, string, Dictionary) : Runs a named query declared in the configuration, it accepts as parameters the entity name, query name and the arguments for the query,
● GetPicklistfstring, string) : Given an entity and field name, returns the list of key- value pairs for a Picklist type field.
● CreateQueryContext(string, string) : Returns a query context given an entity name and the query name. QueryContexts are used to run paged queries where results are retrieved from the persistence system in batches.
● Save(BaseEntity []) : Allows for bulk saving a set of entity instances,
● Save(BaseEntity[], bool, boo!) : Also for bulk saving a set of entity instances. Additionally takes two flags - one for whether the save should continue when errors are encountered and second for whether results should be returned.
● Delete(BaseEntity []) : For bulk deleting a set of entity instances
● Delete(BaseEntity[], bool, bool) : For bulk deleting a set of entity instances. In addition, the first flag indicates whether the operation should continue if errors are encountered and the second flag whether results should be returned.
● SystemCall(string, BaseEntity, Hashtable) :This method is used to invoke business operations directly in the underlying persistence system.
The Admin Module
The Admin Module provides user administration and authentication functionality. User information is stored in the underlying persistence system, it includes a hidden data model definition that is not accessible outside of this module, it provides implementations for the various different authentication schemes that the platform provides. APPENDIX A
APPENDIX A
Copyright ® 2015, PositiveEdge Solutions, LLC. All rights reserved.
The PositiveEdge software accompanied by this notice is provided with certain third party software licensed under separate terms (Open Source Software").
TO THE FULLEST EXTENT PERMITTED UNDER APPLICABLE LAW, THE OPEN SOURCE SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS, CONTRIBUTORS, LICENSORS, AND POSITIVEEDGE "AS IS" AND
ANY REPRESENTATIONS OR WARRANTIES OF ANY KIND, WHETHER ORAL OR WRITTEN, WHETHER
EXPRESS, IMPLIED, OR ARISING BY STATUTE. CUSTOM, COURSE OF DEALING, OR TRADE USAGE, INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR
A PARTICULAR PURPOSE, AND NON-INFRINGEMENT, ARE DISCLAIMED. IN NO EVENT WILL THE COPYRIGHT OWNER, CONTRIBUTORS, LICENSORS, OR POSITIVEEDGE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS INTERRUPTION), HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THE OPEN SOURCE SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files APPENDIX A
(the "Software"), to deal in ihe Software w!ihout restriction, including without limitation the righis to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of ihe Software, and io permit persons to whom Ihe Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in ail copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY' OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES Or MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
APPENDIX A
The Alias CPQ application is a Configure Price and Quote application that enhances the basic built-in quoting capabilities in Microsoft Dynamics CRM. it integrates seamlessly with Microsoft Dynamics CRM, leveraging several built-in capabilities of the Microsoft Dynamics CRM platform. As a result, it provides a smooth user experience when switching between CRM and CPQ.
The application may be accessed independently of CRM, by its own URL or embedded in CRM, replacing the standard Quote entity view. It may be integrated with both an on-premise and on-line- deployments of Dynamics CRM. The application itself may also be deployed both on-premise or online - in the Microsoft Azure cloud - independently of whether your CRM deployment is on-premise or on-line.
Because the quoting process varies from one company to another, the application is highly configurable and customizable, along the lines of the base Dynamics CRM platform. Features and functionality customized to your business needs can be easily introduced. As a consequence, what this document describes is specific to the base CPQ application and the behavior of your implementation may be different. APPENDIX A
The main features and functions of the CPQ application are
● Generate multiple quotes from opportunities with automatic cany-over of key fields and line items from the opportunity into the quote
● Ability to revise quotes and maintain traceability of quote revisions
● Ability to copy from an existing quote that speeds up the quoting process
● Multiple price-lists with multi-currency support.
● Highly granular product configuration with availability of write-in products and sub- products.
● Automatic verification of the quote for consistency that makes the process very reliable.
● Multi-tiered pricing based on quantity
● Discount limits settable either at the product level or by user role or a combination of both,
● Promotional discounts that can be applied for a specific time period,
● Sub- product configuration with different bundled and stand-alone pricing.
● Configurability of complex approval process based on attributes of the quote and line items.
● Set-up of approvers by specific user or user role
● Sequential and parallel approval process routing
● Approve or reject quotes from your mobile device
● Multiple authentication schemes including Single Sign-On
● Configurable email notifications for important changes in state of a quote
● Layout recall
There are two different ways to access the CPQ application - stand-alone and embedded, both of which are accessible simultaneously. In the stand-alone approach, a separate URL is used to access the application, in embedded mode, the application is accessed directly within the Microsoft APPENDIX A
Dynamics CRM application, it is more of a user's preference which way is used. Each of the sections be!ow will deal with both modes.
The quoting process begins with the generation of an opportunity that has been qualified and after one or more interactions with the customer. The steps below describe the steps the user needs to perform to generate a quote. Each of the two different ways of accessing the application provides two ways to generate a quote.
APPENDIX A
A. Go to the Create Quote page, enter the search criteria for the opportunity you want to generate a quote for and click on Fetch
B. The list of opportunities that match the criteria will show up in the Results - Opportunities table
C. Select the opportunity you want to generate a quote for and click on Create Quote
For embedded access, a newly created opportunity will only be quotable after it is saved the very first time, in both cases, the following fields will be carried over to the newly created quote:
● Customer
● Price List
● Currency, from the Price List
● Primary Contact for the Customer and associated contact information
● Shipping and Billing Address for the Customer
● All opportunity product line items that are set up in the Price List of the opportunity
At this point, the status of the quote is Draft. The quote is not saved permanently into the system until Save is clicked the first time. Depending on how access rules are set up in CRM, only the current user may be abie to view and/or edit the quote. The user then proceeds to build out the APPENDIX A quote, applying discounts, adding, removing line items and configuring line items. These steps are described in the next section2 2.1.2 Quote Generation from Scratch
A new quote may be generated by clicking on the "New" button, A blank quote page is displayed. The user can then proceed to fill out the necessary details. The quote is not saved permanently until the Save button is clicked the first time.
Building a Quote
Build Quote menu activates when any of the created quote from 'My Quote' is chosen. Build Quote- places an existing quote in edit mode for viewing the details or for making any changes to an existing quote.
Before we proceed with this section, it would be helpful to review the various fields available on the quote and the line items. Remember that the fields that are available are not limited to the list below. Your specific implementation may remove optional fields from the list below or add fields necessary for your business needs. For obvious reasons descriptions of such fields is not in scope for this document.
2.2.1 Field Descriptions
The fields described below may be removed or new ones added during configuration and customization of the application to conform to the way the quoting process works in your organization. However, appropriate defaults have to be set for required fields below, if removed.
Also, field labels are configurable. The field names you see in your specific implementation may be different than those from the lists below.
A) Quote Fields
These fields are found at the top of a page view laid out in a form with 4 sections: "General information", "Contact Information", "Address Information" and "Terms". Each of the sections are collapsible so the user can adjust the view to show the sections he or she may be interested in at a given point in time. I. Genera! Information section APPENDIX A
APPENDIX A
APPENDIX A
B) Line Item Fields
These fields are available in a table below the form containing the quote fields. Each of the rows may be edited by double-clicking on the row [except for the Configure column, double-clicking on which will open up the sub-product configuration window for the Product on that line item]. Some of the columns do not have headers, primarily because they contain icons and a header will take up more than necessary screen real-estate. Tooltips will appear upon hover over each of the column headers, however.
APPENDIX A
Changes may be made to any of the editable fields while the quote is in the Draft status. After that point, the quote is read-only. It is important to note that changes are not saved permanently until the Save button is clicked. Any changes made since the last save are logged in the Edit Trail, which can be accessed by clicking the "Edit Log" button at the right of the screen. A quote may be reversed to the last saved version by clicking on the "Rollback" button or the "Refresh" icon (located to the right of the "Edit Log" button). APPENDIX A
Addition and removal of Line items is done using the "Add" and "Remove" buttons on the toolbar above the Line Items table. Double-clicking on a line item enables edit mode on a row.
Based on thresholds configured for your implementation, changes to large quotes - quotes with a large number of line items - may be processed asynchronously, allowing the user to perform other tasks while the quote is being processed. At this time, the "Save" button will not be available and the quote together with the line items will become read-only. The button and editing is restored automatically once processing is complete.
Upon each Save, the quote is validated for compliance with the selected price list and for consistency within itself. This vastly increases the reliability of the data represented by the quote and reduces the risk of bugs introduced by customizing the system. If any errors are found; a list of which mav be found in Appendix A - the Exceptions button will show an "!" icon iand a tick mark
Clicking on the Exceptions button will show the list of exceptions that have
occurred.
if the Price List is changed when line items are present on the quote, all line items with products that are not available on the new Price List will be removed.
if the configuration of a Price List is modified or pricing changes before a quote is submitted or activated, any line items with effected products will have to be removed and added back. APPENDIX A
2.3 Activating or Submitting a Quote
A quote is submitted or activated once the user is done with any changes and the quote is in its f ' inai form. Once a quote is submitted, it is read-only and no further changes are possible, if an approval process is configured and the quote meets the criteria established the Status of the quote is set to "in Approval". Depending on your configuration, email notifications are sent out to the users from which the first round of approvals are required. If no approval process is set up or if the quote does not meet established criteria, the quote Status is set to "Approved" and it is made order ready, at which point a Sales Order may be generated from the quote.
2.4 The Approval Process: Approving or Rejecting a Quote if an approval process is set up, approval steps are set up for a quote based on criteria set up for each required approval. The approval process is organized as a list of multiple sequential set of steps, with potentially more than one required approval within each step. This sequence as well as the progress of the quote through the approval process is shown in the Approvals section of the quote form, below the Line items table, in both the stand-alone and embedded views. Depending on conditions set by the approval process, the quote progress from one step to another until it is adjudicated Rejected or Approved, Email notifications may be configured so that users are notified when it is their turn to provide an approval, in such a case, based on your configuration, approvals by email may also be enabled. The Approver will be given two buttons- "Approve" and "Reject" - if the user viewing the quote is an approver in the current step of the approval process, if it is not yet the user's turn, these buttons will not appear. The Approver user may provide optional comments, regardless of whether the user chooses to Approve or Reject the quote. Also governed by your configuration, the user will receive notification once the quote is Approved or Rejected. If a quote is Rejected, the quote is closed and status set to "Rejected".
2.5 Revising a Quote
Although a quote is typically revised after it has been rejected in the approval process, the application allows a revision even for quotes that are in the "in Approval" status or even the "Approved" status, if a quote is revised mid-flight through the approval process, by configuration, email notifications may be sent out to the approvers in the current step of the approval process who have not yet made a decision. Revision of a quote is achieved by clicking on the "Revise" APPENDIX A button. This action will cancel and close the current version of the quote, make an exact replica of it with the same Quote Number and a Revision Number incremented by 1. The status of the new quote will be Draft so the user can make any necessary changes.
2.6 CanceiU ag a Quote
A quote may be cancelled at any time before sales order generation. This is done by clicking on the "Cancel" button. The quote status is changed to "Cancelled" for such a quote and it is closed and read-only. The only operation that may be performed on a cancelled quote is to copy it.
2.7 Copying a Quote
Like cancellation, a quote may be copied at any time, even after sales order generation. The Copy button creates an exact replica of the quote, updating the Created Date (and consequently the Quote Expiration Date), A new quote Number is generated, the Revision Number is reset to 0 and the Opportunity field is unset. The new quote is created in Draft status and the user will be required to set an Opportunity to save the quote since it is a required field. APPENDIX A
3.1 Order Generation
This is the iast step in the quoting process. Clicking on the "Create Order" button will create a Sales Order in CRM, carrying over all of the line items. The opportunity associated with the quote and the quote itself are both closed with a status of Won, Any other quotes associated with the opportunity are closed with a status of Cancelled, it is important to note that changes made in a quote are not automatically carried back to the opportunity. However, this feature may be available for your specific implementation.
Appendix A: Exceptions or Error Messages
Considering further enhancements to the existing CPQ application, the range of exceptions mentioned is larger than the actual count of exceptions/ error messages listed below.
APPENDIX A
APPENDIX A
APPENDIX A
APPENDIX A
The PosiliveEdge Configure, Price and Quote (CPQ) appiication is the only full-featured enterprise application that provides end-to-end quoting functionality from opportunity to order and integrates with both Salesforce and Microsoft Dynamics CRM, It is built on the proprietary PositiveEdge Keystone platform. The application may be deployed on the cloud or on-premise. The functionality provided by the application includes*:
● Generate multiple quotes from opportunities with automatic carry-over of key fields and line items from the opportunity into the quote
● Ability to revise quotes and maintain traceability of quote revisions
● Ability to copy from an existing quote that speeds up the quoting process
● Multiple price-lists with multi-currency support,
● Highly granular product configuration with availability of write-in products and sub- products.
● Automatic verification of the quote for consistency that makes the process very reliable,
● Multi-tiered pricing based on quantity
● Discount limits sellable either at the product level or by user role or a combination of both,
● Promotional discounts that can be applied for a specific time period,
● Sub-product configuration with different bundled and stand-alone pricing,
● Configurability of complex approval process based on attributes of the quote and line items.
● Set-up of approvers by specific user or user role
● Sequential and parallel approval process routing
● Approve or reject quotes from mobile devices
in addition to the above, features available in the PositiveEdge Keystone platform are also available in this application. Some of the Keystone features are leveraged to provide some of the application features above.
In the real world, there really isn't a one-size-fits-ail CPQ solution. Therefore, the PositiveEdge CPQ appiication is designed to be highly configurable and extensible.
* Note that, availability of some of these features depends on the appropriate dependent functionality being available in Salesforce and Microsoft Dynamics CRM
The diagram below illustrates the data model for the application. The boxes in blue represent standard entities or objects that are already present in the underlying persistence system - Salesforce or Micrisoft Dynamics CRM - which are enhances by adding additional custom fields to support quoting functionality. The boxes in white are custom entities or objects. The boxes in green are standard objects already present in Salesforce, but are custom entities in Microsoft Dynamics CRM.
There are two disjoint structures that comprise the data model for the CPQ . appiication. The first, shown in the diagram Fig, 1 below, represents the persistent objects required to fulfill quoting and pricelist management functionality. APPENDIX A
Fig, 1 - Quote and Pricelist Management Data Model
Fig. 2 below shows the persistent objects required for configuration and application of approval rules for quotes.
Fig. 2 - Approval Configuration Data Model APPENDIX A
The Quot Life-cycle
Quotes start out in the draft status. A quote may be created from scratch based on an opportunity or copied over from an existing quote, in the draft status, the quote is completely editable. A Draft quote may either be submitted for approval or canceled, A quote once submitted, may be approved or rejected by approvers, it may also be canceled or revised, if revised, the quote is ciosed as canceled and a new quote record is created, exactly identical to the original except for the revision number, which is incremented by 1, Before a quote can be successfully submitted for approval, it must pass a set of validation ruies designed to maintain the integrity of the quote. These validations ensure not only that there are no calculation errors in the various amounts, but also that the quote line items are configured in accordance with the pricelist. Once a quote is successfully submitted, the quote becomes read-only and can only be revised, canceled, approved, rejected or copied.
The Application Providers
On the server-side, any application built for the Keystone platform consists of a set of Application Providers. Each quote is managed by a set of co-operating Application Providers. These providers are optimized for performance -- not only leveraging the built-in caching capabilities of the Keystone platform, but also executing most operations on the quote in-memory and only persisting the quote to the backend persistent system only when explicitly requested to do so by the user or when submitting a quote for approval. The application maintains and displays a log of changes and edits made to the quote and the line items between such save operations.
The Pricing Engine
All cost and amount calculations are handled by the Pricing Engine. Again, because there is no single, universal procedure to calculate pricing, the pricing engine is designed for extensibility, to allow for overriding the pricing algorithm.
The Approval Engine
The Approval Engine allows users with the appropriate role to configure criteria and routing rules for the quote approval workflow. At any time, only one approval process can be active, A quote is processed for each criteria using dynamically generated code. This allows for setting up any evaluation expression that is supported by the underlying implementation language. Each condition has associated with it a set of users that the quote is routed through to for approval or rejection. Each approver may be set up such that a rejection by that user rejects the entire quote or such that all approvers have to reject the quote for the quote to be rejected. APPENDIX A
88 APPENDIX A