The present disclosure relates to methods, products and systems for distributing changes to an application.
A structured approach to developing web applications includes a model-driven tool such as SAP's Visual Composer, which allows a developer to compose applications in a flexible way by using patterns. A pattern graphically depicts functional components as drag-and-drop services, and defines a data flow between the components. User interface patterns can be defined at various levels, and can be nested within each other, thus creating hierarchies of patterns. At the top level of the hierarchy, a pattern can act as a model or “floor plan” for a user interface that is designed to help end-users complete a specific business process. The floor plan defines the user interface of the application by specifying an overall screen layout for the user interface and managing and orchestrating any nested patterns.
In current implementations of pattern-based configurations, there is a strict separation of components that are related to data handling (i.e., services) and other component that are focused on user interactions (i.e., scenarios). If a service element is changed, e.g. a new attribute is created, this change is not propagated through the whole model because only a service class is associated with the backend meta data, e.g. business object node meta data.
There is currently no generic code distribution mechanism in pattern-based application development environments. Kit developers thus require code distribution, logic for every kit. This increased need for resources to write a kit makes implementation of distribution by different people too different and not always fitting together. Further, the conventional mechanisms for distribution of code created dependency between different kits. Implementing the logic in the pattern components is also not a viable solution, because such implementation violates the modularization of every component. The distribution logic has to be implemented in a more generic layer.
The pattern idea means that it is possible to create new composition unit and plug in these new components without any changes to already existing components. The consequence is that existing components are not allowed to be edited for a new component. An abstraction layer is needed to define that one component wants to host some other components, but does not make any assumptions about the used components, because the used component is added in a dynamic way.
This document discloses a application code distribution mechanism that provides strict separation of components that are related to data handling from other components that are focused on user interactions. In an aspect, the distribution mechanism is generic across all layers, to provide a common distribution mechanism for any development platforms, without the need for specialized coding by kit developers. Further, the distribution mechanism is implemented in an abstract layer, which does not create dependencies between different kits. The distribution mechanism minimizes required user interactions to propagate changes in business diagrams. As a result, changes to business diagrams and their underlying models are propagated dynamically and generically, independent of concrete business case.
In another aspect, a method and a computer program product are provided to implement a process of distributing changes in a network-based application. The process includes the steps of providing a graphical application modeling tool displaying a model of a pattern of the application. The model has a plurality of elements, where each element is linked to another element via a port. Each port representing a class that contains information about the pattern qualities of that port as related to the element. The process further includes the step of propagating a change applied to a first element of the plurality of elements of the model to a second element of the plurality of elements via linked ports associated with the first and second elements.
The details of one or more embodiments are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the description and drawings, and from the claims.
These and other aspects will now be described in detail with reference to the following drawings.
Like reference symbols in the various drawings indicate like elements.
This document describes a distribution mechanism for a visual modeling tool for web-based applications. An architecture for the distribution mechanism introduces a strict separation of components that are related to data handling (service) from component that are focused on user interactions (scenario) in the pattern configuration. To make the pattern configuration as generic as possible, a distribution mechanism is implemented as part of the pattern infrastructure kit.
Elements in the model are linked to each other by links and ports. Ports hold infoshapes that contain the data (fields). When the content of the infoshape of a port is changed, the changes need to be distributed to all the elements that are connected to that port. Ports are configured to receive the new infoshape, update their own infoshape, notify elements about the change, and forward the distributed infoshape to all relevant elements.
When a basic behavior is not needed, it can be overridden with another behavior in accordance with one of two methods. A method distributeInfoshape is used where the basic port classes contain the distribution logic. A callback method onDistributeInfoshape can be implemented by every class in pattern kits that listens to notifications about the infoshape updates.
As shown in
A pattern can have multiple usages in the model, and need not be updated more than once. A flag is generated and kept for each pattern instance to indicate whether it was updated or not. When the distribution process gets to a pattern, it is flagged as updated. When the distribution iteration finishes, the flags are cleared. The distribution will take place for scenarios only, and not services, since services create their own data.
The design time supports different layers of business data. An enterprise services framework (ESF) need not be the only data provider with which a Pattern configuration can work. An alternative data provider can be a remote function call (RCF), for example. As an abstraction layer for data providers, a pattern base kit (“PatternBase”) can be used, as depicted in
Only Pattern Base kit defines the classes PatternService, Patter unport and PatternOutport. Concrete service kits (ESI, RFC kits, etc.) do not inherit from any Service and Port class. They must inherit the following abstract classes defined by pattern base kit:
The distribution mechanism discussed above allows for dynamic creation of a configuration infoshape for a component without using metadata property. An ESI Kit registers to global event “onCreateQuery” from an ESI Discovery Kit. If an “esi query” is dragged over a PatternService, the ESI Kit creates an EsiServiceConfiguration instance and adds it to the PatternService element and configures the PatternService element. The ESI Kit can access and modify PatternService class because it is dependent on PatternBase kit. All Ports in PatternScenario units are of type PatternInport or PatternOutport. If these ports are undefined their infoshape property is null.
If a link is created from PatternServiceOutplug to PatternOutport, the distribution mechanism copies the infoshape properties dynamically. Distribution copy of fields works if the two ports, which are linked together, have the same infoshape type (or the target infoshape is undefined). If the source and target port have a different type of infoshape, the distribution stops and manual interaction from a user is required for how mappings are defined and how the fields of the source port can be mapped to the target port.
Distribution mechanism detects the type of infoshape of the source port and checks if the target port infoshape has the same type (if infoshape of target port is null, the distribution mechanism creates an instance for it). Then, all properties and fields are copied dynamically (in a generic way) to the outport infoshape. The distribution mechanism has no dependency with the ESI kit, and therefore it does not access the infoshape in a particularly structured way. Rather, access is done generically.
The SODP now configures the pattern service as follows: configuration of pattern service is done via the class ServiceHelperRegistry. This class contains a list of ServiceConfigurator instances (each service kit registers after loading the model of its subclass of ServiceConfigurator) and can ask which of those instances can configure the pattern service for a given infoshape of an inport, and calls the configureService method of the correct instance. The implementation of configureService creates the correct configuration instance for the pattern service and creates all in-an outports including fields.
The following pseudo code tries to explain the SODP scenario. The method configureSODP is called in on-Create method of SODP and can be called for reconfiguration of SODP.
Embodiments of the invention and all of the functional operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of them. Embodiments of the invention can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer readable medium, e.g., a machine readable storage device, a machine readable storage medium, a memory device, or a machine-readable propagated signal, for execution by, or to control the operation of, data processing apparatus.
The term “data processing apparatus” encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of them. A propagated signal is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus.
A computer program (also referred to as a program, software, an application, a software application, a script, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.
The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).
Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to, a communication interface to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks.
Moreover, a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio player, a Global Positioning System (GPS) receiver, to name just a few. Information carriers suitable for embodying computer program instructions and data include all forms of non volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.
To provide for interaction with a user, embodiments of the invention can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.
Embodiments of the invention can be implemented in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the invention, or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet.
The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
Certain features which, for clarity, are described in this specification in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features which, for brevity, are described in the context of a single embodiment, may also be provided in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.
Particular embodiments of the invention have been described. Other embodiments are within the scope of the following claims. For example, the steps recited in the claims can be performed in a different order and still achieve desirable results. In addition, embodiments of the invention are not limited to database architectures that are relational; for example, the invention can be implemented to provide indexing and archiving methods and systems for databases built on models other than the relational model, e.g., navigational databases or object oriented databases, and for databases having records with complex attribute structures, e.g., object oriented programming objects or markup language documents. The processes described may be implemented by applications specifically performing archiving and retrieval functions or embedded within other applications.
Number | Name | Date | Kind |
---|---|---|---|
5603034 | Swanson | Feb 1997 | A |
5604516 | Herrod et al. | Feb 1997 | A |
5627979 | Chang et al. | May 1997 | A |
5764973 | Lunceford et al. | Jun 1998 | A |
5826257 | Snelling, Jr. | Oct 1998 | A |
5844554 | Geller et al. | Dec 1998 | A |
5956736 | Hanson et al. | Sep 1999 | A |
5988862 | Kacyra et al. | Nov 1999 | A |
5999940 | Ranger | Dec 1999 | A |
6035300 | Cason et al. | Mar 2000 | A |
6044217 | Brealey et al. | Mar 2000 | A |
6173246 | Billups, III | Jan 2001 | B1 |
6212672 | Keller et al. | Apr 2001 | B1 |
6249905 | Yoshida et al. | Jun 2001 | B1 |
6279109 | Brundridge | Aug 2001 | B1 |
6330007 | Isreal et al. | Dec 2001 | B1 |
6434568 | Bowman-Amuah | Aug 2002 | B1 |
6437805 | Sojoodi et al. | Aug 2002 | B1 |
6539396 | Bowman-Amuah | Mar 2003 | B1 |
6577323 | Jamieson et al. | Jun 2003 | B1 |
6609127 | Lee et al. | Aug 2003 | B1 |
6609128 | Underwood | Aug 2003 | B1 |
6631497 | Jamshidi et al. | Oct 2003 | B1 |
6778863 | Lienhard et al. | Aug 2004 | B1 |
6915301 | Hirsch | Jul 2005 | B2 |
6983421 | Lahti et al. | Jan 2006 | B1 |
6985898 | Ripley et al. | Jan 2006 | B1 |
7120865 | Horvitz et al. | Oct 2006 | B1 |
7120876 | Washington et al. | Oct 2006 | B2 |
7171647 | Smith et al. | Jan 2007 | B1 |
7257597 | Pryce et al. | Aug 2007 | B1 |
7316000 | Poole et al. | Jan 2008 | B2 |
7320005 | Li et al. | Jan 2008 | B2 |
7366723 | Shaburov | Apr 2008 | B2 |
20020026441 | Kutay et al. | Feb 2002 | A1 |
20020026461 | Kutay et al. | Feb 2002 | A1 |
20020111945 | Young et al. | Aug 2002 | A1 |
20020199025 | Kutay et al. | Dec 2002 | A1 |
20030028451 | Ananian | Feb 2003 | A1 |
20030041311 | Poole et al. | Feb 2003 | A1 |
20030101025 | Shah et al. | May 2003 | A1 |
20030120599 | Agboatwalla et al. | Jun 2003 | A1 |
20030126152 | Rajak | Jul 2003 | A1 |
20030154191 | Fish et al. | Aug 2003 | A1 |
20040001092 | Rothwein et al. | Jan 2004 | A1 |
20040017392 | Welch | Jan 2004 | A1 |
20040036719 | Van Treeck | Feb 2004 | A1 |
20040107414 | Bronicki et al. | Jun 2004 | A1 |
20040193579 | Dettinger et al. | Sep 2004 | A1 |
20040205691 | Poole et al. | Oct 2004 | A1 |
20040268228 | Croney et al. | Dec 2004 | A1 |
20050015364 | Payton et al. | Jan 2005 | A1 |
20050055666 | Kornerup et al. | Mar 2005 | A1 |
20050055667 | Beringer et al. | Mar 2005 | A1 |
20050120347 | Asare et al. | Jun 2005 | A1 |
20050257157 | Gilboa et al. | Nov 2005 | A1 |
20050257190 | Shaburov et al. | Nov 2005 | A1 |
20060036745 | Stienhans et al. | Feb 2006 | A1 |
20060074967 | Shaburov | Apr 2006 | A1 |
20060075382 | Shaburov | Apr 2006 | A1 |
20060085681 | Feldstein et al. | Apr 2006 | A1 |
20060085764 | Klementiev | Apr 2006 | A1 |
20070089087 | Connor et al. | Apr 2007 | A1 |
20070277114 | Mudge et al. | Nov 2007 | A1 |
Number | Date | Country | |
---|---|---|---|
20070157161 A1 | Jul 2007 | US |