Deploying a package for a software application

A computer implemented method, apparatus, and computer usable program code for deploying packages. In response to a request to deploy a package for a software application containing metadata, a first portion of the metadata describing the package is processed. A second portion of the metadata relating to modification of a database is processed for the software application after processing the first portion of the metadata. A third portion of the metadata describing all other content for the software application is processed after processing the second portion of the metadata.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to an improved data processing system and more specifically to a method and apparatus for processing data. Still more particularly, the present disclosure relates to a computer implemented method, apparatus, and computer usable program code for deploying a business application.

2. Description of the Related Art

With the Internet and other networks, the use of application servers has become common place. An application server is a software process that delivers applications to client computers or devices. An application server may be a process in a client and server environment that performs business logic or other logic processing. Typically, the application server performs the logic processing with the client performing the role of a user interface through the use of a browser or other client application.

Application management in this type of environment includes configuring and customizing an application to meet the requirements of end users. This type of configuration and customization may be performed in a development environment. From the development environment, the application may be promoted to a test environment to perform user acceptance testing. From this test environment, an application may be promoted to a production environment in which the application is put into use by end users.

Application management in the context of a rollout into a production environment is a complex process. Many different information technology teams may be involved including, for example, database administrators, server administrators, business application managers, and developers. The deployment of the application into the production environment includes minimizing disruptions to the environment itself. Further, the process may involve optimizing the use of tool and information technology resources. Another goal in this type of process is to reduce the amount of time needed to deliver a complete business application to the end users.

In promoting an application into a user acceptance test environment and/or production environment, a process to perform this promotion may be manual or automated. With a manual process, an application may be promoted using various scripts, exporting and importing data using flat files or extensible markup language formatted files, and checking in and checking out of code from source control systems. An automated rollout of an application into different environments may be used when dedicated application management and change management tools are available. In an automated process, various software application promotion tools may be used in which these tools provide dedicated deployment packages.

Automated tools currently exist from various vendors to deploy an application into a production environment. These types of tools, however, are complex and require larger information technology teams with specialized training and skills to run the tools as compared to a manual process. A number of different tools may be launched and operate in conjunction to promote or move the business application into a production environment further increasing the complexity of the rollout. These tools provide extensive support for the deployment of code-based application artifacts but only limited support for content-based application artifacts.

Therefore, it would be advantageous to have a computer implemented method, apparatus, and computer usable program code to reduce the complexity in deploying a business application into an environment.

BRIEF SUMMARY OF THE INVENTION

The illustrative embodiments provide a computer implemented method, apparatus, and computer usable program code for deploying packages. In response to a request to deploy a package for a software application where the application characteristics are expressed as metadata, a first portion of the metadata describing the package is processed. A second portion of the metadata relating to modification of a database is processed for the software application after processing the first portion of the metadata. A third portion of the metadata describing all other application characteristics is processed after processing the second portion of the metadata.

DETAILED DESCRIPTION OF THE INVENTION

In the depicted example, server computer104and server computer106connect to network102along with storage unit108. In addition, clients110,112, and114connect to network102. Client computers110,112, and114may be, for example, personal computers or network computers. In the depicted example, server computer104provides data, such as boot files, operating system images, and applications to client computers110,112, and114. Client computers110,112, and114are clients to server computer104in this example. In this illustrative example, server computer104and server computer106may host application servers, which may provide applications to clients, such as client computers110,112, and114. Further, server computer104and server computer106also may have different environments such as development environments, test environments, and production environments. Network data processing system100may include additional servers, clients, and other devices not shown.

The different embodiments can also take the form of a computer program product which has been downloaded over a network from one device to another for use in the other device. For instance, the program code stored in a computer readable storage medium in a server data processing system may be downloaded over a network from the server data processing system to a remote data processing system, such as a client or another server. Likewise, the program code stored in a computer readable storage medium in a client data processing system may be downloaded over a network from the client to a remote data processing system, such as a server computer or another client computer.

With reference now toFIG. 2, a block diagram of a data processing system is shown in which illustrative embodiments may be implemented. Data processing system200is an example of a computer, such as server computer104or client computer110inFIG. 1, in which computer usable program code or instructions implementing the processes may be located for the illustrative embodiments. In this illustrative example, data processing system200includes communications fabric202, which provides communications between processor unit204, memory206, persistent storage208, communications unit210, input/output (I/O) unit212, and display214.

As one example, a storage device in data processing system200is any hardware apparatus that may store data. Memory206, persistent storage208, and computer readable media218are examples of storage devices in a tangible form.

The different illustrative embodiments recognize that currently used processes for moving applications from one environment to another environment may be complex, time consuming, and/or costly. Thus, the different illustrative embodiments provide a computer implemented method, apparatus, and computer usable program code for distributing packages for use in deploying an application. A package contains metadata of various types each of which characterize an application. A first portion of metadata in a package is processed in response to a request to deploy the package for the software application. This first portion of the metadata describes the package. A second portion of the metadata relating to a modification of a database for the software application is processed after processing the first portion of the metadata. A third portion of the metadata describing all other characteristics of the application is processed after processing the second portion of the metadata.

In this manner, all of the metadata is contained in a single package and may be deployed in the correct order. Further, the different illustrative embodiments provide an ability to validate this content during the deployment. This ability to process content may be performed with content created by clients as well as those created by developers. This process does not require additional software tools or utilities as with currently used methods.

In summary, the process for deploying a package may be executed when a package is deployed for a software solution. An end user may trigger the deployment of the package through a single request without requiring further user interaction.

With reference now toFIG. 3, a diagram of different application environments is depicted in accordance with an illustrative embodiment. In this example, development environment300, test environment302, and production environment304are examples of environments in which packages may be implemented to deploy applications. In this example, application306may be developed or created in development environment300. Development environment300, test environment302, and production304may be implemented on data processing systems, such as data processing system200inFIG. 2. Various programmers and developers may create applications, such as application306, within development environment300.

Application306may be described using metadata308. This metadata may be placed into package310and moved or sent to test environment302. Package310may be deployed to install application312in test environment302. In test environment302, various types of testing may be performed on application312to ensure that application312is capable of meeting various requirements. These requirements may include, for example, running scripts, performing stress tests, and other suitable processes to determine whether application312is acceptable for use in production environment304. If application312is suitable for use in production environment304, package314may be sent to production environment304and deployed as application316for use by end users. Package314in these examples contains the same metadata as package310with audit updates. Examples of audit data include, for example, on what system the package was originally created and where it is currently installed for testing; who created/deployed the package; and where the package was regenerated for further downstream deployment in production environment. Metadata303is available in test environment302and metadata305is available in production environment304as a result of applications312and316being deployed into those respective environments. This metadata is used to run applications312and316and make them available to the end user.

With reference now toFIG. 4, a diagram illustrating an application platform is depicted in accordance with an illustrative embodiment. In this example, application platform400is an example of an application platform that may be found in various environments. These environments include, for example, development environment300, test environment302, and production environment304. Tivoli Maximo and Tivoli Change and Configuration Management Database (CCMDB) are examples of application platform product. These application platform products are available from International Business Machines Corporation. In these examples, an application platform is a software ecosystem in which a number of cooperating software components executes to deliver software applications to end users.

In this illustrative example, application platform400includes runtime402and package deployment engine404. Runtime402includes user interface creation and event handling406and object creation and database event handling408. Package deployment engine404includes package deployment processing410. Package deployment engine404may execute package deployment processing410to deploy package412. Deployment of package412in this example creates new tables, columns, views as well as data in database414.

In these examples, application platform400may execute on one data processing system, while applications416and418may execute on other data processing systems. In other advantageous embodiments, application platform400, application416, and application418may be located on the same data processing system. Application416and application418in these examples may be web based applications that execute through a browser. In this type of implementation, application416and application418are user interfaces in which the logic is executed through user interface creation and event handling406and object creation and database handling408.

User interface creation and event handling406may create user interfaces for applications416and418using information from database414. This component may handle events detected through user input into applications416and418as well as returning response events for presentation by those applications. Database414may be used by runtime402to present applications416and418to end users. Database414may take various forms. For example, database414may be a relational database or an extensible markup language database.

Object creation and database event handling408may query database414to create various objects in presenting application416and418. Workflow, notification, actions are some of the examples of objects that may be created for the application. In addition, application user interface tabs, windows, menus, buttons are examples of other objects that may be created for the application. Also, fields in the application user interface windows may provide lookups to quickly locate data that can be placed in the field. Security restrictions which determine if a field is editable or read-only in a particular window are also retrieved from the database and configured as objects for the application.

In this illustrative example, package412contains all of the content for an application, such as application416and application418. Also, the content in package412is arranged or identified with an order for processing or deployment by package deployment processing410. The deployment of package412by package deployment processing410may execute without requiring user intervention within application platform400. Package deployment processing410processes all the content in package412in the order specified without the need for other software tools or utilities to create runtime402.

As mentioned above, content in package412is metadata in these examples. This metadata may be stored in various data structures. For example, the metadata may be stored within extensible markup language documents placed within package412.

In this depicted example, application416and application418may be different instances of the same application. In other illustrative examples, application416and application418may be different applications that have been deployed on application platform400.

With reference now toFIG. 5, an illustration of a package is depicted in accordance with an illustrative embodiment. Package500is an example of one implementation of package412inFIG. 4. In this example, package500includes package metadata502, structural metadata504, and nonstructural configuration metadata506. Package metadata502describes package500. In other words, package metadata502may summarize or describe the content within package500. Package metadata502is used to prepare a context for a complete deployment of package500.

Structural metadata504describes the data that may modify the structure of the underlying database of the application. In this example, structural metadata504includes object definitions508, object relationships510, and domains512. Object definitions508include, for example, definitions used to construct or modify database entities such as, for example, tables, views, columns, queues, indexes, sequences, and other suitable entities. Object relationships510may describe the relationships between the different objects. Domains512are valid data used in the object definitions. Domains512contain data that are validated when entered into certain fields.

Nonstructural configuration metadata506describes data that may take the form of rows in various tables within the database. Nonstructural configuration metadata506may include information such as workflow definitions514, communications templates516, and actions518. Workflow definitions514may define various workflows that can automate application actions or enforce business rules. Communications templates516may define communications such as, for example, email notifications. Actions518are some of the business logic applied during workflow executions, such as changing of a status of a record from its current status to the next valid status. Other examples of nonstructural configuration metadata506include, for example, data for user interface definitions, data to validate values entered into fields, data for automation capabilities, data for determining user authorization and authentication, data for the construction of key performance indicators, reports, and data to integrate the application with other systems.

With reference now toFIG. 6, an illustration of a package is depicted in accordance with an illustrative embodiment. Package600is an example of another implementation of package412inFIG. 4. In this example, package600includes package metadata602and structural metadata604. In this example, structural metadata604may include object definition606, object relationships608, tables612, view614, and indexes616. In these examples, tables612contain various entries and/or objects. An example of a table within table612includes, for example, a work flow table. A view within view614is a database view that may be defined on one or more tables within table612. Indexes616are database objects defined in a table to aid in retrieving records rather than searching an entire table. In this example, package600does not include nonstructural configuration metadata. The different packages in the different illustrative embodiments are not required to include all three types of metadata. Each package in these examples always includes package metadata.

With reference toFIG. 7, another illustration of a package is depicted in accordance with an illustrative embodiment. Package700is an example of one implementation of package412inFIG. 4. In this example, package700includes package metadata702and nonstructural configuration metadata704. Nonstructural configuration metadata704in this example includes application presentation706, menus708, start centers710, workflow definitions712, communications templates714, actions716, and roles718. Application presentation706contains data used to generate presentations to a user through a user interface. Menus708include data for various menus that may be presented through application presentation706. A start center in start centers710is a configurable user interface that displays the different application components to a user. Various users can configure their start center to look differently as well as display different data. A start center is akin to a dashboard. When a user logs in to a software application, the start center presents information and controls such as short cuts, charts, and summary data that aid in user's decision making. Roles718define the roles of a person. The roles include, for example, purchasing agent, supervisor, system administrator, and other suitable roles. These roles are linked to various people in these examples.

Turning next toFIG. 8, another diagram of a package is depicted in accordance with an illustrative embodiment. Package800is another example of an implementation for package412inFIG. 4. In this example, package800only includes package metadata802. The illustration of packages500,600,700, and800are provided as illustrations of some configurations for a package according to an illustrative embodiment. The illustration of these different examples is not meant to limit the manner in which packages may be constructed and the content in the packages. Other packages may include other content than that illustrated in these examples. Further, other packages in other implementations may include more content or less content than those illustrated for the different types of metadata.

Thus, in the different illustrative examples of packages inFIGS. 5-8, a package may only include the content needed for a particular application. In some cases, packages may be used to modify or change features provided by an application. With these types of changes, a complete package with all three types of metadata may not be needed.

With reference now toFIG. 9, a flowchart of a process for deploying an application is depicted in accordance with an illustrative embodiment. The process illustrated inFIG. 9may be implemented in a software component, such as package deployment processing410inFIG. 4.

The process begins by deploying package metadata (step900). In these illustrative examples, the deployment of metadata may include unpacking or removing the metadata from the package. Further, the deployment of the metadata also includes processing the metadata to create database entities. These entities include database tables, views, columns, indexes, keys, and sequences. These are referred to as structural metadata.

Thereafter, a determination is made as to whether structural metadata is present in the package (step902). If structural metadata is present in the package, the structural metadata is deployed (step904). The structure metadata deployed in step904describes changes to be made to various structures. A structure is a component or item that can hold data. A structure includes, for example, tables, views, columns, keys, indexes, and other suitable items in a database. These changes may be loaded into a set of configurations of metadata tables.

The different illustrative examples launch a database configuration process to perform the required database changes using this structural metadata and execute appropriate database commands to make the changes. The process then configures the database (step905). In configuring the database in step905, the process operates on “database objects” or “structural entities”. These objects include, for example, tables, views, index, sequences, triggers, and other suitable database objects.

When configuring the database based on metadata in the package, multiple tables, views, and other objects may be created or changed or deleted. Step905may comprise of performing database operations which operate on database objects. The database operations comprises at least one of create a table, alter the table, drop the table, create a view, alter the view, drop the view, create indexes, drop the indexes, create a sequence, alter the sequence, drop the sequence, create a trigger, and drop the trigger.

A determination is then made as to whether nonstructural metadata is present in the package (step906). If nonstructural metadata is present in the package, the nonstructural metadata is deployed (step908).

A determination is then made as to whether all of the deployed metadata has been validated (step910). If all of the deployed metadata has been validated, a notification is generated that the package deployment for the application has been completed (step912) with the process terminating thereafter.

With reference again to step910, if all of the deployed metadata has not been validated, an error is generated (step914) with the process terminating thereafter. With reference again to step906, if nonstructural metadata is not present in the package the process proceeds to step910directly. With reference back to step902, if structural metadata is not present in the package, the process proceeds to step906directly.

With reference now toFIG. 10, a flowchart of a process for deploying metadata is depicted in accordance with an illustrative embodiment. The process inFIG. 10is a more detailed illustration of a deployment step, such as those found in steps906,910, and912inFIG. 9.

The process begins by identifying all extensible markup language documents having the selected type of metadata to form a set of identified extensible markup language documents (step1000). These documents are identified as being of a particular type of metadata. For example, the process may identify all of the extensible markup language documents that relate to package metadata, structural metadata, or nonstructural configuration metadata.

The process then orders the extensible markup language formatted documents based on a specific order of processing (step1002). In these examples, the order in which extensible markup language documents are processed may follow in order of the logical workflow process that may be found in the application being deployed. Some metadata may have dependencies on other metadata in other extensible markup language documents, requiring the meta data to be processed before other meta data. Processing content out of order may result in the application not functioning properly. The process loads each extensible markup language document and constructs the corresponding array of object structures (step1004).

An array of object structures is created based on the content of the extensible markup language document. This array of object structures may be, for example, a set of tables, views, indexes, or any other suitable object structures. By using an object form, more information may be stored in an object than using a record in a table record.

The process then iterates the array of object structures and then each object structure traverses through the object (step1006). Next, the process identifies the action to be performed for each object (step1008). The action may be specified along with the metadata in the extensible markup language document or may have to be determined dynamically.

The action specified may include, for example, inserting, updating, or deleting an entity. If the specified action is to insert, a row may be added to the object; if the specified action is to update the object, a desired row may be retrieved based on primary keys of the object and the necessary values may be placed into the object based on identifying the appropriate metadata in the extensible markup language document. In inserting the row, values may be set in the row based on metadata from the extensible markup language document. If the specified action is to delete, a row may be deleted from the object based on primary keys of the object.

A determination is made as to whether an action has been specified (step1010). If an action has been specified, a determination is made as to whether the action is an insert action step1012. If the action is an insert action, a row is added to the object (step1012). Then, the process sets the necessary values into the object based on corresponding tags in the extensible markup language documents (step1014). These corresponding tags are one that correspond to the object and identify the values needed for the object.

The process then saves the row and executes a validation process on the row to determine the validity of the data within the row (step1016). Validation is performed on an object to determine whether the object has been correctly constructed or is valid. The validation may include, for example, verifying whether values and/or dependencies are correct. For example, if the object is a record or row for an email notification, a recipient value must be specified to whom the email notification can be sent to. If no recipient value is present, then the email notification object is considered to be invalid. In another example, a workflow process record or row may require an email notification to be sent as part of the process. A node in the workflow process specifies the particular email notification. When the workflow process record is created or updated based on the metadata in the extensible language markup document, validation is performed to determine if the email notification is already present. If the required email notification is not present, then the workflow process is considered to be invalid. In other embodiments, other types of validations may be performed that are suitable for the particular object being validated.

With reference again to step1012, if the action is not an insert action, a determination is made as to whether the action is an update action (step1018). If the action is an update action, the desired row is retrieved based on the primary keys of the object (step1020). In these examples, the primary keys act as an index to the row. The action includes the primary keys so that the appropriate object may be identified. The process then sets the necessary values into the object based on the corresponding tags and the extensible markup language document (step1022). The process then saves the row and executes row validation to determine the validity of the data (step1024), with the processing terminating thereafter.

With reference again to step1018, if the action is not an update action, the action is a delete action. The process retrieves the desired row based on the primary keys of the object (step1028). The process then deletes the row from the object (step1030) with the process terminating thereafter.

With reference again to step1010, if no action is specified, a determination is made as to whether a row needs to be added or updated by looking up the object with the primary key information (step1032). Next, the process determines if a row is to be added (step1034). If a row is to be added, the process proceeds to step1013as described above. Otherwise, a row is to be updated and the process proceeds to step1020as described above. The case where row does not need to be updated or added does not arise. If the package contains metadata for a particular row, then one of the three actions must be performed—insert, update or delete. If there is no metadata for a row in a package, then that row is unaffected by package deployment.

Thus, the different advantageous embodiments provide a computer implemented method, apparatus, and computer usable program code for distributing packages to deploy software applications. In the different illustrative embodiments, a first portion of metadata describing a package is processed in response to a request to deploy a package. A second portion of the metadata relating to modifications of the database is processed after processing the first portion of the metadata. A third portion of the metadata describing content for the database may be processed after the second portion has been processed in these examples. Of course, depending on the particular implementation, a package may not include all three types of metadata described in the different illustrative examples. In these examples, all the packages may include the first portion of metadata while the second and third portions may be optional depending on the particular deployment.

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 storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.