Patent Description:
Application lifecycle management (ALM) includes processes that manage the life cycle of applications from conception to end of life, providing a framework for software development through managing the software over time (e.g., deployment, updates, rollback, and uninstallation). The ease of development of applications using LCAPs has historically excluded user-created LCAP components from benefitting from many of the ALM processes.

The document <CIT> related to a computer-implemented method for automatically generating a client-side application based on available components. A source code and related build information of a component is stored in a component repository. The component is developed in a developer mode of a developer tool. An existing single-page application is changed using a non-expert editing tool by selecting a component from the component repository, retrieving the selected component from the repository, extracting build information from the retrieved component, adding dependencies regarding the retrieved component to a single-page packaging of the existing single-page application, and compiling the single-page application together with the retrieved component.

Some examples extend application lifecycle management processes to user-created application platform components, such as in a low-code application platform (LCAP). Within an application platform, a first component and a second component are generated. The first component is customized at least by defining a layering of the first component, and indicating whether the first component is protected from downstream modification. The second component is customized in accordance with customizing the first component, and is further customized to define a dependency of the second component on the first component. First metadata for the first component representing the customizations made to the first component is stored. Second metadata for the second component representing the customizations made to the second component is stored. The first component and the second component are deployed with the first metadata and the second metadata.

The present invention is set out in the attached independent claims, with the dependent claims representing embodiments of the invention.

The various examples are described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers are used throughout the drawings to refer to the same or like parts. References made throughout this disclosure relating to specific examples and implementations are provided solely for illustrative purposes but, unless indicated to the contrary, are not meant to limit all examples.

Some examples extend application lifecycle management processes to user-created application platform components, such as in a low-code application platform (LCAP). Within an application platform, a first component and a second component are generated. Example components include entities (e.g., tables), processes (e.g., general automation), forms (e.g., a user interface (UI) for an entity), bots (e.g., artificial intelligence), and others. Components can be combined to build solutions (e.g., data flows). The first component and the second component are customized based on input from a user or code, and the second component is made dependent on the first component. Dependencies prohibit uninstalling components when dependent components remain installed. The customizations are stored as part of metadata associated with the components. The metadata enables application lifecycle management (ALM) processes to be associated with these user-created components. The first component and the second component are then deployed in a target environment. In some examples, the LCAP comprises a solution component framework (SCF).

Aspects of the disclosure improve the operations of computing resources by permitting user-created LCAP solution components to benefit from the wide range of common ALM processes, such as deploying, updating, and uninstalling. Aspects of the disclosure operate in an unconventional manner by storing certain metadata for user-created components that opens up advantageous customizations, such as localization for any component field and protection from downstream modification. Some examples further improve low-code operation to no-code operation, leveraging graphical user interfaces (UIs) to accept customization configuration selections, thereby expanding the user base to even users who do not possess coding skills.

Because the customizations are driven by UIs, rather than written in code, computing resources usage is reduced, thereby improving the functioning of the underlying device. Further, development time for new solution-aware components is reduced, and operational reliability is improved even as testing requirements are lessened thus improving the device. The underlying LCAP framework orchestrates operations, for example by enforcing user-defined dependencies. That is, users are able to define dependences among components, and the framework then either permits or prevents certain changes based on whether attempted changes would break a dependency. Other user-defined customization aspects are similarly managed to provide reliable operation of solutions and components.

<FIG> illustrates an arrangement <NUM> for advantageously extending ALM processes to user-created LCAP components used in a solution. In some examples, a solution is a package in which customized components of a particular project are stored. Customizers and developers (e.g., users <NUM>) distribute solutions so that business functionalities may be transported to customers <NUM>. In <FIG>, user <NUM> is tasked with building a solution <NUM>, such as a deployable application ("app") that uses a set of customized solution components <NUM>, for example a component <NUM>, a component <NUM>, and a component <NUM>. To accomplish this, user <NUM> uses an LCAP <NUM> (which comprises an SCF, in some examples) and interfaces with LCAP <NUM> using a UI <NUM>. LCAP <NUM> is able to implement ALM processes <NUM>, which are described in further detail below. Some of these processes include an export process <NUM>, illustrated in <FIG>, an import process <NUM>, illustrated in <FIG>, and an uninstall process <NUM>, illustrated in <FIG>. In some examples, uninstall process <NUM> is also used for updating.

Metadata for component <NUM>, component <NUM>, and component <NUM> are stored in metadata <NUM>, shown as containing at least metadata 300a and metadata 300b. Further detail is shown in <FIG>. The solution created by user <NUM> is deployed, as deployed components <NUM>, to a target environment <NUM> for use by a customer <NUM>. For example, user <NUM> may be writing an app for customer <NUM> to use. Target environment <NUM> has metadata <NUM>, which may be copied or derived from metadata <NUM>, and data <NUM> for use by, and in support of, deployed components <NUM>.

Each of component <NUM>, component <NUM>, and component <NUM> supports ALM, and may be stacked to provide layering, as indicated in <FIG>. This permits retaining records of prior customization and enabling reverting changes (e.g., updates) via uninstall operations (e.g., uninstall process <NUM>, see <FIG>) Publishers hold ownership of components shipped as part of a managed solution, and a particular publisher is able to protect components from other users' modification and deletion attempts. In some examples, users are able to identify which solutions installed particular components, so that the users may work with those component's owners to build on top of those components (e.g., layer).

When a new component is created (e.g., generated), such as component <NUM>, a table is created with full layering support. Extensibility points are added for create, retrieve, update, delete (together CRUD), and also import, export, uninstall, and publish. This information is saved within metadata <NUM> (e.g., as metadata 300a). Forms are created to permit user <NUM> to customize the component using UI <NUM>. An example of UI <NUM> is shown in <FIG>. Relationships are created for supporting auditing and process automation, and views are created for runtime consumption of the top layer.

Solution components (e.g., components <NUM>-<NUM>) represent different aspects of a platform, such as: entities (e.g., tables), processes (e.g., general automation), forms (e.g., a UI for an entity), bots (e.g., artificial intelligence), and others. Developers (e.g., user <NUM>) use various solution components, in LCAP <NUM>, to rapidly build reliable solutions that fulfill business needs. Entities define the shape of an object that represents an artifact of a business, and, in some examples, have full ALM support without the need of custom code (e.g., from a user) to facilitate transport (e.g., deployment). By enabling an entity to experience full ALM support (e.g., data import, export, and uninstall), it is rendered into a "solution-aware" solution component.

Component registration for ALM occurs when an entity is generated (e.g., created) in LCAP <NUM> by setting a property or field (such as setting IsSolutionAware to True), or when the same property is enabled in an existing entity. User <NUM> is able to change the value of this property via UI <NUM> or, in some examples, programmatically via a software development kit (SDK). A screenshot <NUM> of UI <NUM> is shown in <FIG> for a component having a name <NUM> and a display name <NUM>. A Solution Component checkbox <NUM> is checked, so the component will be a solution aware solution component. When an entity is created or updated with the IsSolutionAware property set to true, LCAP <NUM> will create the necessary artifacts for ALM support.

In some examples, these artifacts include table columns to allow solution layering (e.g., SolutionId, ComponentState, and OverwriteTime) and a table column for publisher customization control (e.g., IsCustomizable). These example artifacts are illustrated in <FIG>. Solution layering (depicted graphically in <FIG>) is used to stack customizations together where the topmost layer defines runtime behavior for a solution. This permits changing runtime behavior of a component easily, by importing a solution on top of an identified component whose runtime behavior is to be changed. A publisher (e.g., user <NUM>) is an owner of a group of solutions, and some examples of LCAP <NUM> may be used for development of multiple different solutions simultaneously, by multiple different publishers. A publisher holds ownership of a solution, and therefore, holds ownership over components within that solution. Thus, when a solution component is declared as not customizable, only the publisher owner of that component is permitted to create (e.g., generate, make) customizations on top of it. Once a component is defined, it is visible for consumption.

<FIG> shows another example screenshot <NUM> of example UI <NUM> (e.g., of a field customization panel) with multiple options identified as enabled. For example, an Auditing radiobox group has Enabled checked, rendering the subject component auditable, a Localization checkbox <NUM> is checked, so the component is localizable, and an Exportable checkbox <NUM> is checked, so the component is exportable (e.g., may be deployed).

Some users may need a solution or component to support multiple languages, for example, when customers <NUM> span multiple countries and/or language groups. The ability to reuse a single component, and selectively replace textual items with corresponding text in a selected language, is referred to as localization. Components generated by LCAP <NUM> support localization. User <NUM> may declare a field as localizable and LCAP <NUM> supports the creation of labels for that field. One way this may be accomplished is by Localization checkbox <NUM>, precluding the necessity of custom code to achieve the same result.

In some examples, user <NUM> also determines which components will be exposed. In some examples, all properties of a solution component are represented in a solution, with the exclusion of properties with empty or null values. However, in some scenarios, user <NUM> may choose to exclude other properties. To accomplish this, user <NUM> unchecks Exportable checkbox <NUM>.

<FIG> illustrate exemplary metadata as may be used by arrangement <NUM>. An example of metadata 300a, shown in <FIG>, is created when Solution Component checkbox <NUM> is checked (see <FIG>). SolutionId is an Identifier of the solution owner of that layer, and is used for dependency determinations or set to a base value. ComponentState represents the runtime behavior of the specific layer, with values: <NUM> - Published (instance is visible for runtime consumption); <NUM> - Unpublished (instance is in draft state, only visible for designers); <NUM> - Deleted (instance is not visible for runtime and design consumption, e.g., an undo candidate); and <NUM> - Unpublished Deleted (instance is not visible for runtime, but can still be visible for designers as "to be removed").

There are scenarios in which a solution component instance is not ready for consumption, and is in draft state (e.g., ComponentState is set to <NUM>). There are also scenarios in which a solution component instance is no longer useful for consumption, and is in a deleted or unpublished deleted state (e.g., ComponentState is set to <NUM> or <NUM>). In some examples, a publisher is able to declare a particular component as eligible for soft delete. A soft deleted component is a component instance not available for runtime consumption, but yet is still present in the environment, allowing user <NUM> to undo the deletion when necessary.

OverwriteTime is a timestamp of when the layer was overwritten. If a layer has not been overwritten by any other solution, it is considered the top layer and defines the runtime behavior. IsCustomizable indicates whether a record is available for customization or whether only the owning publisher is permitted to modify the record. IsManaged indicates whether a record belongs to a manager solution. ComponentIdUnique is a unique layer identifier used for solution uninstallation. In some examples, system views are automatically created views for easy access to top layers, so that it is not necessary to determine the top layer upon data retrieval.

<FIG> shows an example of metadata 300b, in which PK means primary key and FK means foreign key. A foreign key ensures data consistency across layers in the absence of dependencies. An identifier (ID) table tracks all keys corresponding to a particular solution component in a parent table. This permits other tables to create FKs to the component's table, given that a PK is consistent same across different solution layers. A dependency table stores information regarding how the dependent nodes are connected, which is used to determine and enforce dependencies.

SolutionComponentDefinitionBase represents different, example solution aspects of a component and dictates the ALM behavior of a solution-aware entity. Name is the platform name of the entity. ObjectTypeCode is an integer representation of an entity. SolutionComponentType is an integer representation of a component. LabelTypeCode is an integer representation of a localizable component. GroupParentComponentType is a SolutionComponentType of the parent component (when applicable). GroupParentComponentAttributeName is a PK column of the parent component (when applicable). ComponentXPath is an extensible markup language (XML) root node representation in a solution file.

<FIG> shows an example of metadata 300c which, along with metadata 300d and 300e, is also within metadata <NUM> (but not shown in <FIG>, in order to avoid cluttering <FIG>). In SolutionComponentDefinitionBase, LabelTypeCode is an integer representation of a localizable component. In Attribute, HasMultipleLabels identifes labels in different languages for localization.

LocalizedLabel stores translations for a particular string represented in a Label column. ObjectId column corresponds to the PK of the record owner of that translation, and LabelTypeCode indicates in which table a record is stored. ObjectColumnName represents a column corresponding to a label that is replaced at runtime with the corresponding translation, when a different language context is used. ObjectColumnName matches with name of the Attribute having the HasMultipleLabels set to true. HasMultipleLabels is set to true when creating or updating a field if Localization checkbox <NUM> is checked.

<FIG> shows an example of metadata 300d. SolutionComponentConfigurationBase is a configuration entity representing different aspects of the source control representation of a solution component, in addition to dictating how the component is visible. FileFormat is an integer representing the file format of a record in source control, with: <NUM> - XML; and <NUM> - JSON (Javascript object notation). FileScope is an integer representing the folder structure of components in source control, with: <NUM> - No source control support; <NUM> - Individual folder structure (components may be grouped in sub-folders partitioned based on their relationships); and <NUM> - Global file or Single file under a folder that represents all instances of that component. In some examples, different folder structures may be used: global (all the data will be present in a single file under a system generated folder); and individual (each component will have its own separate folder, and each instance of that component will have its own file). In some examples, a component instance may be represented in either XML or JSON formats. IsSoftDeleteEnabled identifies whether a solution component is eligible for having instances in soft delete mode (ComponentState = <NUM>). IsDisplayable is used for selecting component visibility options.

SolutionComponentAttributeConfigurationBase is a configuration entity representing different aspects of the source control representation of an Attribute. EncodingFormat identifies an encoding algorithm used for storing the content of a field, with: <NUM> - No encoding is applied; <NUM> - Base64; and <NUM> - UTF8 (unicode transformation format - <NUM>-bit). FileExtension are extension to be appended to a file (e.g.,. IsExportDisabled indicates whether a field should be excluded from an exported component file. IsExportAsFile indicates whether the content of a field should be exported as a file, respecting the extension expressed on the FileExtension property. IsEnabledForDependencyExtraction indicates whether the content of a field should be considered for additional dependency declaration. An Export Key is an alternate key that represents an identifier of a component in a solution file. IsExportKey indicates whether the EntityKey record representing an alternate key should be considered as an Export Key.

<FIG> shows an example of metadata 300e. SolutionComponentRelationshipConfigurationBase is a configuration entity responsible for dictating the solution development behavior of related components (e.g., solution-aware entities sharing a relationship). AddRelatedComponents indicates whether referencing records should be automatically added to a solution when a referenced record is added. In some examples, components sharing an N-to-<NUM> of type Parent-Child or an N-to-N relationship behave as if this property is set to true. CascadeRemoveComponents indicates whether referencing records should be automatically removed from a solution whenever a referenced record is removed. ForceAddingManagedRelatedComponents indicates whether LCAP <NUM> should add referencing records to a solution even when the referencing records are managed.

LCAP <NUM> permits user <NUM> to declare dependencies via relationships to other entities declared as solution components (e.g., component <NUM> may depend on component <NUM>). <FIG> shows an exemplary screenshot <NUM> that may be displayed by UI <NUM> to enable user <NUM> to assign a dependency relationship between two components. If a solution component has a reference to another solution component via a relationship, that reference is treated as a dependency. Dependencies help to ensure data consistency by rejecting delete requests of a particular solution component if there is another solution component that references the object that is the subject of the deletion attempt. When the referenced component is being removed, a determination is made whether the referenced component is required. If so, the deletion attempt is rejected, due to potential data corruption risks, and UI <NUM> will present user <NUM> with an error message.

In some examples, dependency determination occurs in multiple phases. Components are identified, along with relation declarations. The nodes are formed into a tree, with nodes linked according to the relation declarations. Duplicate links are removed. For example, if a node is linked to both a parent and a grandparent, and the node's parent is also linked to the grandparent, then the node's link to the grandparent is a duplicate link and may be removed (e.g., because the parent's link to the grandparent protects the node).

Multiple dependency types are supported, including: positional, relational, referential, and custom. Positional dependencies are declared based on the component positioning relative to other components. Relational dependencies are declared based on the relationships a component has with other solution aware entities. Referential dependencies are declared based on the references a component has with other solution aware entities. In some examples, custom dependencies may be collected from custom functionality. Dependencies may be persisted after calculation.

In <FIG>, a selection window <NUM> in UI <NUM> (displayed in screenshot <NUM>) permits user <NUM> to select a relationship behavior from a menu <NUM> of supported relationship behavior. Multiple cascade options are available, including: Parental (when the referenced entity record is deleted, all referencing records are also deleted); Parent-Child (same as Parental, but including that the child inherits the parent's behavior); Referential (when the referenced entity record is deleted, the reference field becomes empty); Restrict Delete (the system blocks the delete of an entity record if a reference exists); and Custom (user <NUM> defines what happens when a referenced entity record is deleted).

<FIG> illustrates a graphical view <NUM> of a layering, as may occur in arrangement <NUM>. A base layer is at the bottom of a layer stack, for example, a system solution layer <NUM> forms a base layer. As illustrated, a basic entity <NUM> and a sitemap <NUM> (e.g., a sitemap for a website) are initially present in system solution layer <NUM>. Sitemap <NUM> and a template component <NUM> are each customized by user <NUM> in LCAP <NUM> to become customized solution components, similar to components <NUM> and <NUM>, in a set of managed solutions <NUM>. In this example, sitemap <NUM> is part of a managed solution <NUM>, and template component <NUM> is part of a managed solution <NUM>.

Another user (e.g., a downstream user such as customer <NUM>) further customizes entity <NUM> and sitemap <NUM> in a set of unmanaged customizations <NUM>. In this scenario, sitemap <NUM> had not been protected from downstream changes. Entity <NUM> (now customized) and sitemap <NUM> (now customized in one layer by user <NUM> and a second layer by the downstream user) are part of an unmanaged solution <NUM>. The runtime behavior <NUM> of entity <NUM> and sitemap <NUM> is defined by the top-most customizations at the unmanaged customizations <NUM> layer. Sitemap <NUM> and template component <NUM> are part of an unmanaged solution <NUM>. The runtime behavior <NUM> of template component <NUM> is defined by the top-most customizations at the managed solutions <NUM> layer. A web resource <NUM>, introduced is also introduced at the unmanaged solution <NUM> layer.

In some examples, LCAP <NUM> may be extended, if some business needs cannot be achieved via the no-code experience. Additional extensions points may be available for user <NUM> developers to achieve additional ALM functionality. For example, user <NUM> may create and register plugins for extra data validation, communication with services external to LCAP <NUM>, initiation of automated processes based on a specific criteria, and other functionality.

In addition to CRUD (create, update, delete, and retrieve), LCAP <NUM> provides additional extensibility points for consumption during solution events, such as export, import, and uninstall (together referred to as transport). Processes for export, import, and uninstall (and update) are illustrated in <FIG>, <FIG>, and <FIG>, respectively.

<FIG> illustrates a graphical depiction of an export process <NUM> for exporting a solution, which includes exporting solution components (e.g., components <NUM>-<NUM>). An export handler loads records related to a solution from a table in metadata <NUM>, populates a customization file (e.g., an XML file) for each component based on attributes marked as exportable (see <FIG>), adds localized labels for exportable attributes having HasMultipleLabels is marked as true (see <FIG>), determines missing components based on dependencies, and instantiates another pipeline for the missing components.

This operation is illustrated as having three tiers, a solution export tier <NUM>, a component tier <NUM>, and a third tier <NUM>. The general scheme is a request triggering a pre-operation phase, then a main operation phase, and finally a post-operation phase. In a pre-operation phase, an input parameter is the instance of the component being processed. In a main operation phase, the operation to be performed is determined and either executed, or anther pipeline is invoked (or both, in some examples). For example, solution export tier <NUM> has an export solution request <NUM>, a pre-operation <NUM>, a main operation <NUM>, and a post-operation <NUM>. Main operation <NUM> loads all components registered to a solution, and post-operation <NUM> converts retrieved data based on source control configurations.

Component tier <NUM> has an export component request <NUM>, a pre-operation <NUM>, a main operation <NUM>, and a post-operation <NUM>. Main operation <NUM> filters properties of components. Third tier <NUM> has a retrieval request <NUM>, a pre-operation <NUM>, a main operation <NUM>, and a post-operation <NUM>. Main operation <NUM> retrieves the published top layers of components.

<FIG> illustrates a graphical depiction of an import process <NUM> for importing a solution, which includes importing solution components (e.g., components <NUM>-<NUM>). An import handler determines needed operations and instantiates a new pipeline for each needed operations. This operation is also illustrated as having three tiers, a solution import tier <NUM>, a component tier <NUM>, and a third tier <NUM>. The general scheme is a request triggering a pre-operation phase, then a main operation phase, and a post-operation phase, similar to exporting. For example, solution import tier <NUM> has an import solution request <NUM>, a pre-operation <NUM>, a main operation <NUM>, and a post-operation <NUM>. Main operation <NUM> converts solution files based on metadata <NUM> in target environment <NUM>. For solution import tier <NUM>, an additional phase, dependency determination <NUM>, follows post-operation <NUM>. Dependency determination <NUM> calculates (e.g., determines) and persists dependencies.

Component tier <NUM> has an import component request <NUM>, a pre-operation <NUM>, a main operation <NUM>, and a post-operation <NUM>. Main operation <NUM> calculates write operations based on data <NUM> present in target environment <NUM>. In post-operation <NUM>, user <NUM> may install additional custom logic. Third tier <NUM> has a create/update request <NUM>, a pre-operation <NUM>, a main operation <NUM>, and a post-operation <NUM>. Main operation <NUM> executes a write operation to write the files. In some examples, another dependency determination phase follows post-operation <NUM>. In some examples, delete requests are not permitted during import/export operations.

<FIG> illustrates a graphical depiction of an uninstall process <NUM> for uninstalling a solution, which includes uninstalling solution components (e.g., components <NUM>-<NUM>). An uninstall handler determines affected operations and instantiates a new pipeline for each needed operations. This operation is also illustrated as having three tiers, a solution uninstall tier <NUM>, a component tier <NUM>, and a third tier <NUM>. The general scheme is a request triggering a pre-operation phase, then a main operation phase, and finally a post-operation phase, similar to exporting and importing. For example, solution import tier <NUM> has an uninstall solution request <NUM>, a pre-operation <NUM>, a main operation <NUM>, and a post-operation <NUM>. Main operation <NUM> loads all components registered to the solution being uninstalled. For solution uninstall tier <NUM>, an additional phase, dependency determination <NUM>, follows post-operation <NUM>. Dependency determination <NUM> calculates (e.g., determines) dependencies in order to prevent deletion of a component having surviving dependencies (e.g., dependencies surviving the uninstallation).

Component tier <NUM> has an uninstall component request <NUM>, a pre-operation <NUM>, a main operation <NUM>, and a post-operation <NUM>. Main operation <NUM> calculates write operations based on current layering. Third tier <NUM> has a delete/update request <NUM>, a pre-operation <NUM>, a main operation <NUM>, and a post-operation <NUM>. Main operation <NUM> removes a layer (e.g., deletes a component) subject to dependency constraints. An update operation uses a combination of uninstallation and importing (e.g., both process depicted in <FIG> and <FIG>) to uninstall the obsolete solution and replace it with the updated solution (e.g., the updated components).

<FIG> is a flowchart <NUM> illustrating exemplary operations (e.g., ALM processes) associated with arrangement <NUM>. In some examples, operations described for flowchart <NUM> are performed by computing device <NUM> of <FIG>. Flowchart <NUM> commences with operation <NUM>, which generates a solution <NUM> (comprising components <NUM>-<NUM>) using LCAP <NUM>, and is performed with operations <NUM>-<NUM>. In some examples, LCAP <NUM>, comprises a Solution Component Framework. Operation <NUM> includes, within LCAP <NUM>, generating component <NUM> (e.g., a first component). In some examples, user <NUM> is able to generate component <NUM> without the user having to write code.

Operation <NUM>, customizing component <NUM>, is performed using one or more operations <NUM>-<NUM>, and involves creating extensibility points for ALM operations. In some examples, the ALM operations comprising create, update, delete, retrieve, import, export, uninstall, and publish. Operation <NUM> includes indicating whether component <NUM> is subject to localization. For example, indicating includes updating metadata <NUM> based on a selection made by user <NUM> via a UI. Operation <NUM> includes indicating whether component <NUM> is protected from downstream modification (e.g., changes by another user). Operation <NUM> includes indicating whether component <NUM> is exportable. Operation <NUM> includes defining dependency for component <NUM> (e.g., based on a UI selection by user <NUM>). Operation <NUM> includes defining a layering of component <NUM>, for example by determining the most current change or modification. Operation <NUM> includes marking component <NUM> for soft deletion. LCAP <NUM> receives selections and markings provided by user <NUM> in operations <NUM>-<NUM>, and internally indicates or otherwise records those selections (e.g., updates metadata <NUM>).

Operation <NUM> stores metadata <NUM> for component <NUM>, and decision operation <NUM> determines whether user <NUM> will generate or modify another component (e.g., component <NUM>). If so, flowchart <NUM> returns to operation <NUM>. Operation <NUM> is performed for the next component, such as component <NUM> and later, for component <NUM>. For example, operation <NUM> generates component <NUM> (e.g., a second component), in some examples without writing code (e.g., by the user), and customizes component <NUM> in accordance with customizing component <NUM>. This includes creating extensibility points for ALM operations.

When applied to component <NUM>, operations <NUM>-<NUM> respectively: indicate whether component <NUM> is subject to localization; indicate whether component <NUM> is protected from downstream modification; indicate whether component <NUM> is exportable; define a dependency of component <NUM> (e.g., on component <NUM>); define a layering of component <NUM>; and mark component <NUM> for soft deletion.

Operation <NUM> performs ALM processes on component <NUM> and component <NUM> using operations <NUM>-<NUM>. Operation <NUM> deploys component <NUM> and component <NUM> using operation <NUM>. Operation <NUM> includes exporting component <NUM> and component <NUM> (see <FIG>), and importing component <NUM> and component <NUM> (see <FIG>). Operation <NUM> upgrades component <NUM> and component <NUM>, and operation <NUM> rolls back an upgrade of component <NUM> and/or component <NUM>.

Operation <NUM> includes attempting an uninstallation of component <NUM>, and is performed with operations <NUM>-<NUM>. Decision operations <NUM> and <NUM> determine dependencies involving component <NUM>. Decision operation <NUM> determines whether another component is dependent on component <NUM>, and if so, decision operation <NUM> determines whether that other component remains installed (or is also scheduled for uninstallation or has already been uninstalled). If both conditions are true (another component is dependent on component <NUM>, and that other component remains installed), flowchart proceeds to operation <NUM>. Otherwise, if one condition is not met, flowchart proceeds to operation <NUM>.

Operation <NUM> includes, based on at least component <NUM> remaining installed and the dependency of component <NUM> on component <NUM> remaining, preventing uninstalling component <NUM>. Operation <NUM> includes, based on at least component <NUM> being uninstalled or the dependency of component <NUM> on component <NUM> not remaining, permitting uninstalling component <NUM>. Other ALM process are accomplished in operation <NUM>.

<FIG> is a flowchart <NUM> illustrating exemplary operations associated with arrangement <NUM>.

In some examples, operations described for flowchart <NUM> are performed by computing device <NUM> of <FIG>. Flowchart <NUM> commences with operation <NUM>, which includes generating a first component within an LCAP. Operation <NUM> includes customizing the first component, which is performed using operations <NUM>-<NUM>. Operation <NUM> includes defining a layering of the first component. Operation <NUM> includes indicating whether the first component is protected from downstream modification.

Operation <NUM> includes generating a second component. Operation <NUM> includes customizing the second component in accordance with customizing the first component (e.g., performing equivalents of operation <NUM>-<NUM> for the second component). Operation <NUM> further includes operation <NUM>, which defines a dependency of the second component on the first component. Operation <NUM> includes storing metadata for the first component and metadata for the second component. Operation <NUM> includes deploying the first component and the second component.

An example method of ALM comprises: within an LCAP, generating a first component; customizing the first component, wherein customizing the first component comprises: defining a layering of the first component; and indicating whether the first component is protected from downstream modification; generating a second component; customizing the second component in accordance with customizing the first component, wherein customizing the second component further comprises: defining a dependency of the second component on the first component; storing first metadata for the first component representing the customizations of the first component, storing second metadata for the second component representing the customizations of the second component; and deploying the first component and the second component with the first metadata and the second metadata.

An example system for ALM comprises: a processor; and a computer-readable medium storing instructions that are operative upon execution by the processor to: within an LCAP, generate a first component; customize the first component, wherein customizing the first component comprises: defining a layering of the first component; and indicating whether the first component is protected from downstream modification; generate a second component; customize the second component in accordance with customizing the first component, wherein customizing the second component further comprises: defining a dependency of the second component on the first component; store first metadata for the first component representing the customizations of the first component; store second metadata for the second component representing customizations of the second component; and deploy the first component and the second component with the first metadata and the second metadata.

One or more example computer storage devices has computer-executable instructions stored thereon, which, on execution by a computer, cause the computer to perform operations comprising: within an LCAP, generating a first component; customizing the first component, wherein customizing the first component comprises: defining a layering of the first component; and indicating whether the first component is protected from downstream modification; generating a second component; customizing the second component in accordance with customizing the first component, wherein customizing the second component further comprises: defining a dependency of the second component on the first component; storing first metadata for the first component representing the customizations of the first component; storing second metadata for the second component representing the customizations of the second component; and deploying the first component and the second component with the first metadata and the second metadata.

<FIG> is a block diagram of an example computing device <NUM> for implementing aspects disclosed herein, and is designated generally as computing device <NUM>. In some examples, one or more computing devices <NUM> are provided for an on-premises computing solution. In some examples, one or more computing devices <NUM> are provided as a cloud computing solution. In some examples, a combination of on-premises and cloud computing solutions are used. Computing device <NUM> is but one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the examples disclosed herein, whether used singly or as part of a larger set. Neither should computing device <NUM> be interpreted as having any dependency or requirement relating to any one or combination of components/modules illustrated.

The examples disclosed herein may be described in the general context of computer code or machine-useable instructions, including computer-executable instructions such as program components, being executed by a computer or other machine, such as a personal data assistant or other handheld device. Generally, program components including routines, programs, objects, components, data structures, and the like, refer to code that performs particular tasks, or implement particular abstract data types. The disclosed examples may be practiced in a variety of system configurations, including personal computers, laptops, smart phones, mobile tablets, hand-held devices, consumer electronics, specialty computing devices, etc. The disclosed examples may also be practiced in distributed computing environments when tasks are performed by remote-processing devices that are linked through a communications network.

Computing device <NUM> includes a bus <NUM> that directly or indirectly couples the following devices: computer-storage memory <NUM>, one or more processors <NUM>, one or more presentation components <NUM>, input/output (I/O) ports <NUM>, I/O components <NUM>, a power supply <NUM>, and a network component <NUM>. While computing device <NUM> is depicted as a seemingly single device, multiple computing devices <NUM> may work together and share the depicted device resources. For example, memory <NUM> may be distributed across multiple devices, and processor(s) <NUM> may be housed with different devices.

Bus <NUM> represents what may be one or more busses (such as an address bus, data bus, or a combination thereof). Although the various blocks of <FIG> are shown with lines for the sake of clarity, delineating various components may be accomplished with alternative representations. For example, a presentation component such as a display device is an I/O component in some examples, and some examples of processors have their own memory. Distinction is not made between such categories as "workstation," "server," "laptop," "hand-held device," etc., as all are contemplated within the scope of <FIG> and the references herein to a "computing device. " Memory <NUM> may take the form of the computer storage media and operatively provide storage of computer-readable instructions, data structures, program modules and other data for the computing device <NUM>. In some examples, memory <NUM> stores one or more of an operating system, a universal application platform, or other program modules and program data. Memory <NUM> is thus able to store and access data 1112a and instructions 1112b that are executable by processor <NUM> and configured to carry out the various operations disclosed herein.

Memory <NUM> may include any quantity of memory associated with or accessible by the computing device <NUM>. Memory <NUM> may be internal to the computing device <NUM> (as shown in <FIG>), external to the computing device <NUM> (not shown), or both (not shown). Examples of memory <NUM> include any computer storage media for encoding desired information and for access by the computing device <NUM>. Additionally, or alternatively, the memory <NUM> may be distributed across multiple computing devices <NUM>, for example, in a virtualized environment in which instruction processing is carried out on multiple computing devices <NUM>. For the purposes of this disclosure, "computer storage media," "computer storage memory," "memory," and "memory devices" are synonymous terms for the memory <NUM>, and none of these terms include carrier waves or propagating signaling.

Processor(s) <NUM> may include any quantity of processing units that read data from various entities, such as memory <NUM> or I/O components <NUM>. Specifically, processor(s) <NUM> are programmed to execute computer-executable instructions for implementing aspects of the disclosure. The instructions may be performed by the processor, by multiple processors within the computing device <NUM>, or by a processor external to the client computing device <NUM>. In some examples, the processor(s) <NUM> are programmed to execute instructions such as those illustrated in the flow charts discussed below and depicted in the accompanying drawings. Moreover, in some examples, the processor(s) <NUM> represent an implementation of analog techniques to perform the operations described herein. For example, the operations may be performed by an analog client computing device <NUM> and/or a digital client computing device <NUM>. Presentation component(s) <NUM> present data indications to a user or other device. Exemplary presentation components include a display device, speaker, printing component, vibrating component, etc. One skilled in the art will understand and appreciate that computer data may be presented in a number of ways, such as visually in a graphical user interface (GUI), audibly through speakers, wirelessly between computing devices <NUM>, across a wired connection, or in other ways. I/O ports <NUM> allow computing device <NUM> to be logically coupled to other devices including I/O components <NUM>, some of which may be built in. Example I/O components <NUM> include, for example but without limitation, a microphone, joystick, game pad, satellite dish, scanner, printer, wireless device, etc..

The computing device <NUM> may operate in a networked environment via the network component <NUM> using logical connections to one or more remote computers. In some examples, the network component <NUM> includes a network interface card and/or computer-executable instructions (e.g., a driver) for operating the network interface card. Communication between the computing device <NUM> and other devices may occur using any protocol or mechanism over any wired or wireless connection. In some examples, network component <NUM> is operable to communicate data over public, private, or hybrid (public and private) using a transfer protocol, between devices wirelessly using short range communication technologies (e.g., near-field communication (NFC), Bluetooth™ branded communications, or the like), or a combination thereof. Network component <NUM> communicates over wireless communication link <NUM> and/or a wired communication link 1126a to a cloud resource <NUM> across network <NUM>. Various different examples of communication links <NUM> and 1126a include a wireless connection, a wired connection, and/or a dedicated link, and in some examples, at least a portion is routed through the internet.

Although described in connection with an example computing device <NUM>, examples of the disclosure are capable of implementation with numerous other general-purpose or special-purpose computing system environments, configurations, or devices. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with aspects of the disclosure include, but are not limited to, smart phones, mobile tablets, mobile computing devices, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, gaming consoles, microprocessor-based systems, set top boxes, programmable consumer electronics, mobile telephones, mobile computing and/or communication devices in wearable or accessory form factors (e.g., watches, glasses, headsets, or earphones), network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, virtual reality (VR) devices, augmented reality (AR) devices, mixed reality devices, holographic device, and the like. Such systems or devices may accept input from the user in any way, including from input devices such as a keyboard or pointing device, via gesture input, proximity input (such as by hovering), and/or via voice input.

By way of example and not limitation, computer readable media comprise computer storage media and communication media. Computer storage media include volatile and nonvolatile, removable and non-removable memory implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or the like. Computer storage media are tangible and mutually exclusive to communication media. Computer storage media are implemented in hardware and exclude carrier waves and propagated signals. Computer storage media for purposes of this disclosure are not signals per se. Exemplary computer storage media include hard disks, flash drives, solid-state memory, phase change random-access memory (PRAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that may be used to store information for access by a computing device. In contrast, communication media typically embody computer readable instructions, data structures, program modules, or the like in a modulated data signal such as a carrier wave or other transport mechanism and include any information delivery media.

The order of execution or performance of the operations in examples of the disclosure illustrated and described herein is not essential, and may be performed in different sequential manners in various examples.

Claim 1:
A system for application lifecycle management, the system comprising:
a processor (<NUM>); and
a computer-readable medium storing instructions that are operative upon execution by the processor (<NUM>) to:
generate a first component within a low-code application platform, LCAP, (<NUM>);
customize the first component, wherein customizing the first component comprises:
defining a layering of the first component to stack customizations;
indicating whether the first component is protected from downstream modification, wherein a downstream modification corresponds to changes by another user; and
creating extensibility points for application lifecycle management, ALM, operations, the ALM operations comprising create, update, delete, retrieve, import, export, uninstall, and publish;
generate a second component within the LCAP (<NUM>);
customize the second component in accordance with customizing the first component, wherein customizing the second component further comprises:
defining a dependency of the second component on the first component;
store first metadata (300a) for the first component representing the customizing of the first component;
store second metadata (300b) for the second component representing the customizing of the second component; and
deploy, in a target environment, the first component and the second component with the first metadata and the second metadata, when performing said ALM operations comprising
exporting the first component;
importing the first component;
upgrading the first component; and
either
based on at least the second component remaining installed and the dependency of the second component on the first component stored in the second metadata remaining, prevent uninstalling the first component; or
based on at least the second component being uninstalled or the dependency of the second component on the first component stored in the second metadata not remaining, permit uninstalling the first component.