Preparing for IBM PureApplication System, Part 4: Onboarding applications to the cloud using the Advanced Middleware Configuration tool V1.1

Part 4 of this article series identifies the applications that you can migrate to IBM PureApplication System and explains how to use Advanced Middleware Configuration to deploy new instances of applications into the cloud.

Note: This article has been updated to support Version 1.1 of the Advanced Middleware Configuration tool.

Share:

Barton Akeley, Software Developer, IBM

Photo of Barton AkeleyBarton Akeley was a Software Developer for Rational Enterprise Modernization and Compilers at the IBM Austin, Texas lab. He worked on Rational Automation Framework, Advanced Middleware Configuration, and Rational Build Forge.



John Gough, Information Developer, IBM

Photo of John GoughJohn Gough is an Information Developer at the IBM Austin, Texas lab. He works on Rational Automation Framework, Advanced Middleware Configuration, and Rational Build Forge.



Lewis Shiner, Technical Writer, IBM

Photo of Lewis ShinerLewis Shiner is a contract technical writer in Raleigh, North Carolina. He works on Rational Automation Framework and Advanced Middleware Configuration.



August 2013 (First published 11 April 2012)

Also available in Chinese Russian Japanese Vietnamese Spanish

Introduction

Using IBM PureApplication System, you can create and deploy virtual servers in the cloud that represent middleware topologies and application configurations. However, you still face the challenge of moving existing applications onto the cloud and automating them.

This article describes how to capture and automate the deployment of a middleware topology and application by using Advanced Middleware Configuration. This process is known as "onboarding." Before you begin, read through the instructions and make sure you have the necessary permissions for all the steps you need to complete.


Virtual applications vs. virtual system patterns

For more information about choosing between virtual application patterns and virtual system patterns, see the first two parts of this series, Onboarding migrations overview and Is your application ready to become virtual?.


When to use Advanced Middleware Configuration

PureApplication System includes Advanced Middleware Configuration as a workload. Advanced Middleware Configuration stores configuration data on a framework server and uses the AMC Import Script Package to update that data. The AMC Integration Script Package incorporates that configuration data, including applications, in new virtual system patterns. An AMC Cleanup Script Package is also available to delete configuration data.

Use Advanced Middleware Configuration when more than one of the following conditions applies to you:

  • You want to deploy JEE applications as virtual system patterns.
  • You do not have reliable end to end automation for the installation and configuration of applications.
  • Your existing automation is specific to a single topology.
  • You want to reduce your investment in low-level automation.
  • You want to migrate WebSphere products into the cloud.

For more information about which applications can and cannot run as virtual applications, see Part 2 of this series, Is your application ready to become virtual?.


Overview of the onboarding process

The onboarding process:

  • Creates a configuration definition based on an existing WebSphere Application Server cell.
  • Inserts the resources and applications from the existing cell.
  • Creates a template that is the model for the virtual servers you will create.
  • Generates a virtual system pattern (VSP) from the template.
  • Deploys multiple instances of the pattern in the cloud.

Detailed instructions for this process are broken down into the following sections:


Creating the framework server

In the Workload Console, click Patterns > Virtual Systems. From the Virtual System Patterns list on the left, click the supplied pattern named Advanced Middleware Configuration 1.1. The pattern name includes a platform designation, either x86 or Power, as shown in Figure 1.

Figure 1. Deploying the framework server into the cloud
Deploying the framework server into the cloud

To deploy this pattern, click Deploy, or click the accompanying icon, showing a green arrow above a cloud. Assign a name to the new instance, such as AMCFrameworkServer. After the pattern has been deployed, the console automatically loads the new instance.

The next step is to set up a unique user ID and password for the virtual system pattern (VSP) you created. This ID is used for communication between the script packages and the framework server.

  1. Wait until you see a "ready" icon (white arrow in a green box) next to the instance name, or the Current status field shows "Virtual system is ready".
  2. Expand Virtual machines.
  3. Expand the displayed virtual machine. Scroll to the bottom of the display for the machine, find the Consoles section, and click AMC. A new browser window opens with the console for Advanced Middleware Configuration.

Creating a user for the framework server

The default user and password for the console is root/root. Make a note of the host name of the framework server as well as the user credentials you are about to create because you will need them for the VSP generator later.

  1. Log in to the console as root.
  2. Click Administration > Users.
  3. Click the green plus sign above the user list to create a user.
  4. Enter the data for the new user, including an email address and password, as shown in Figure 2.
    Figure 2. Entering new user data
    Entering new user data
  5. Click Create to save the user. The new user is displayed in the edit pane.
  6. In the edit pane, expand the Access groups heading and click the Add button at the bottom of the Access group display.
  7. In the list of available groups, select Build Engineer and click the Add button as shown in Figure 3.
    Figure 3. Adding the Build Engineer group
    Adding the Build Engineer group
  8. Click Save.
  9. Click Logout and then log in again with the credentials you just created. In the examples, this is the tutorial user.

Creating a configuration definition from the existing cell

On the Advanced Middleware Configuration framework server, the configuration information is organized by environments, which are containers for one or more configuration definitions. A configuration definition typically represents a WebSphere cell. The Advanced Middleware Configuration console contains an editor that you can use to create a configuration definition.

Your next step is to import the topology of the external cell that supports the application that you want to bring onboard. This article uses the HitCount application, part of the DefaultApplication package that is available for WebSphere Application Server, to provide a simple example.

To import the topology of the HitCount server:

  1. In the Advanced Middleware Configuration console, click Configuration.
  2. Click the icon for Read existing configuration as shown in Figure 4.
    Figure 4. The configuration definition editor
    The configuration definition editor
  3. Use the values shown in Table 1 to respond to the prompts in the editor. Not all the prompts are included here. The example values are intended to be representative rather than definitive.
Table 1. Example values for the configuration definition editor
PromptValue
Product WebSphere Application Server
Environment name ExistingHitCountEnv
Existing server host name external.host.example.com.
This name refers to the host of the dmgr or standalone server that contains the master configuration data for the cell.
OS username
OS password
These credentials are used to connect to the host in the previous field.
Test connection Click to verify your connection to the existing server.
Profile Root Directory /opt/IBM/WebSphere/Profiles/DefaultDmgr01
Use soap.client.props file for authentication no
For increased security, you can pass credentials to the wsadmin scripting client through the soap.client.props file. See the documentation for the WebSphere Application Server workload for more information on whether this feature is enabled by default.
Read configuration topology Click when you have completed the preceding fields. This process must complete before you generate the new definition.
Configuration template WAS85_TEMPLATE
After you see a "Passed" message for reading the topology, select the name of either a product template or a user template (if available). The process of reading the existing configuration determines the version number of the middleware that the existing server is running, and only matching templates are displayed. For this initial discovery of the existing topology, use a template with no built-in applications or configuration data. Later you will see how to construct a custom template that uses the data from the existing cell.
  1. When all fields are complete, click Generate configuration.
    If you see an error message that includes the sentence "Ensure the integrateToBF script has been run", you might need to log in to the framework server and run the integrateToBF createAll command from the command line.

    You might see an error message that says, "Error: Could not load resource. The resource might have been deleted, or you do not have access to view the resource." Make sure the current user is a member of the Build Engineer group.

    If you see a result of "Passed", close the Results window by clicking the X in the upper right corner. The Read existing configuration window is displayed again. Click OK to close.

  2. If you need to customize the configuration definition, click Edit and make changes in the edit pane. You can add clusters or servers or make any other changes to the configuration topology that you might need.

Importing configuration data

You have captured the topology of the system you want to bring into the cloud. Now you need to import the configuration information from the existing cell, including the application you are onboarding.

To import the data from the HitCount server:

  1. In the Advanced Middleware Configuration console, click Configuration and locate the configuration definition that you just created.
  2. Expand Plans.
  3. Expand the RAFW_env_config_import plan.
  4. The Run plan window is displayed, showing the context variables for this configuration definition. You can change these variables here, but you should not need to. Click Run, as shown in Figure 5.
    Figure 5. Running the import plan
    Running the import plan
  5. A job is created in the automation engine to run the plan. The job results are displayed in the console and periodically refreshed until the job completes, as shown in Figure 6.
    Figure 6. Import plan passed
    Import plan passed

You have now created a configuration definition for the server that you want to bring into the cloud. This is sometimes called the "Golden" configuration.

Setting up the Eclipse client

The next steps are creating a template from your configuration definition and generating a VSP from the template. Both these steps require the Advanced Middleware Configuration Eclipse client.

If you have already set up your Eclipse client, skip ahead to Creating a template from a configuration definition.

  1. In the Advanced Middleware Configuration console, on the Welcome page, click Download the rich client. Select either the Windows or the Linux client.
  2. Save the archive file, extract it to a directory of your choice, and then launch the Eclipse client by double-clicking the amcui.exe icon.
  3. In the Eclipse client, right-click the blank space in the Configuration Explorer window and then click Create > Framework Server Connection. The Framework Connection window is displayed.
  4. In the Framework Connection window, complete the fields shown in Table 2.
Table 2. Example values for the framework server connection
FieldDescription
Label Enter a free-form label, such as "Framework Server", to identify this connection.
Hostname Enter the name of the framework server you created earlier in this process. One way to obtain this name is to select your framework server from the Virtual Systems Instances page of the Workload Console and expand Virtual machines. Expand the AMC Part. Scroll down to the Network interface 1 field and copy either the host name or the IP address from this field.
Username Enter the name of the user you created earlier in the Workload Console. For example, this article uses "tutorial".
Password Enter the password for the user in the previous field.
Remember Password Leave this field selected if you do not want to reenter your password every time you connect.
  1. Click Test Connection to verify the information you just entered. You see a "Server validated" message near the top of the window if the test is successful.
  2. Click Finish. The label you assigned your framework server now appears in the Configuration Explorer view.
  3. In the Configuration Explorer view, right-click your framework server and then click Connect. You can now expand your framework server and see the configuration definition you created earlier, as shown in Figure 7.
    Figure 7. The Configuration Explorer view
    Import plan passed

Creating a template from a configuration definition

By using templates, you can standardize the process of creating configuration definitions and VSPs and ensure that they are pre-filled with data, including application EAR or JAR files. Templates can also contain custom questions, which are added to a script package when you generate a VSP from the template. The custom questions correspond to the tokens that replace configuration-specific data. For more information, see Configuration template overview in the PureApplication System Information Center. This topic also explains how to use the promote.properties file to identify configuration-specific values that you want to be tokenized.

  1. In the Eclipse client, drag your configuration definition from the Configuration Explorer view to the Configuration Workspace view, as shown in Figure 8. Be sure to drag the cell name, not the environment name.
    Figure 8. Dragging the configuration definition to the Configuration Workspace view
    Dragging the configuration definition to the Configuration Workspace view
  2. Create a promote.properties file to enable custom tokenization. In the Configuration Workspace view, right-click the configuration (cell) name and click Add New > Promote Properties File.
    The promote.properties file defines tokens that replace configuration-specific values. The Eclipse client creates a new promote.properties file at the cell scope (meaning it affects all nodes except those with their own promote.properties files that override it). The file is opened for editing.
  3. List a set of token names and the configuration-specific values they replace. Do not include at-signs in the token names. Using the example in Figure 9, when the template is created, any occurrences of "DEV.db.domain.com" in the configuration data are replaced by "@dbHostName@". When you deploy the VSP, you are asked to provide the appropriate value for the new configuration.
    Figure 9. Creating the promote.properties file
    Creating the promote.properties file

    For more information, see Tokens and tokenization in the PureApplication System Information Center.

  4. In the Configuration Workspace, right-click the configuration (cell) name and click New > Configuration Template.
  5. In the Configuration Template window, enter the information shown in Table 3.
Table 3. Example values for the configuration template window
Field Description
Configuration Template Name Template names are typically in uppercase letters and include a product acronym and version. User-created templates typically include a few characters to distinguish them from the system-supplied templates, such as WAS85_HITCOUNT_TEMPLATE.
Use Template Meta-Data from Template Select an existing template as a basis for any additional questions or topology data you need during the configuration edit process, such as WAS85_TEMPLATE. The product version of the template you choose must match the version of WebSphere Application Server that you specify in the VSP. It does not need to match the version of the existing cell.
  1. Click OK. A list of the files in the template is displayed in the editor pane.
  2. Expand any of the objects in the Scope Type column. Clear the check box for any objects that you want to remove from the template, as shown in Figure 10. You cannot clear the check box for a required file. You must make these changes before saving the template.
    Figure 10. Removing objects from the template
    Removing objects from the template
  3. Save the template by clicking File > Save or pressing Ctrl-S. The Save Template window is displayed, as shown in Figure 11.
    Figure 11. The Save Template window
    The Save Template window
  4. If you use any promote.properties files, default questions are created to solicit new values for those properties in the configuration editor. Click Modify Questions and provide more user-friendly prompts in the Display Name fields, as shown in Figure 12.
    Figure 12. The User Defined Questions window
    The User Defined Questions window

    Click OK when finished and then click OK to save the template.

  5. In the Template Workspace view, right-click the new template name and click Team > Save Changes to Server.

Creating a VSP from a template

The first step is to verify that you have the required script packages available in the IBM PureApplication System catalog. If all three packages are available, the VSP generation is virtually automatic.

Verifying required script packages

In the Workload Console, click Catalog > Script Packages. Make sure you see the packages shown in Figure 13.

Figure 13. Catalog of script packages
Catalog of script packages

If any packages are missing, complete the following steps for each package:

  1. Click the green plus sign to create a new script package.
  2. Assign the name of the missing package. The name must exactly match one of the following:
    • AMC Cleanup Script Package
    • AMC Import Script Package
    • AMC Integration Script Package
  3. Upload the appropriate archive file for the package from your local system. The files are available on the Welcome page of the Advanced Middleware Configuration console. Click Download script packages and select the file you want. The following files are available:
    • CleanupScriptPackage.zip
    • ImportScriptPackage.zip
    • rafwScriptPackage.zip (contains AMC Integration Script Package)

Generating the VSP

  1. In the Advanced Middleware Configuration Eclipse client, Configuration Explorer view, right-click the name of your framework server and click Refresh to show the latest templates.
  2. Expand Configuration Templates. Right-click the template you just created and click Generate VSP, as shown in Figure 14.
    Figure 14. Generating the VSP
    Generating the VSP

    The Generate Virtual System Pattern window is displayed.

  3. Provide the information shown in Table 4.
Table 4. Example values for VSP generation
Field Description
Pattern Name The name that the VSP will have in the Workload Console catalog. This example uses HitCountVSP.
Cloud Hostname The host name or IP address of the IBM PureApplication System Workload Console.
Cloud Username The name of the user on the Workload Console who owns the pattern.
Cloud Password The password for the user in the previous field.
  1. Click Verify to test the connection to the PureApplication System host. When the connection is verified, click Generate. A VSP is created in PureApplication System and a custom script package is created with the name RAF_template_name_Integration. This script package is a copy of the standard Integration script package, with parameters added for any custom tokens that you created earlier.

Deploying the new VSP

The Integration script package, mentioned earlier, runs when you deploy a new instance of a VSP. The VSP generation process adds some values to the package, but you must provide others at deployment time. In Figure 15, green check marks indicate the parts that are complete. The Virtual system name field is originally not checked, but the check mark is displayed once a name is entered. Note that the Configure virtual parts section requires user input.

Figure 15. Deploying an instance of the HitCount VSP
15. Deploying an instance of the HitCount VSP

When you deploy the new VSP, you want to create a new configuration environment on the framework server at the same time. A field is provided for the environment name in the Integration script package.

  1. In the Workload Console, click Patterns > Virtual Systems and then click the name of the VSP that the VSP generator just created (HitCountVSP in this example).
  2. Click Deploy.
  3. Provide a name for the instance you are creating. For the purposes of this article, it is named HitCountInstance.
  4. Click Configure virtual parts > Standalone server. You must fill any required parameters that are blank. You can also change any completed parameters that are unlocked. For example, you might be required to provide passwords for the root user and virtuser on the instance being created.
  5. Enter a value for the RAFW_ENVIRONMENT parameter. You previously created a configuration environment to represent the external server. Now you want a second environment to represent the virtual server you are creating. In this example, the new environment is named VirtualHitCountEnv.
  6. If you used the promote.properties file to create custom tokens, enter values for them here. Figure 16 shows the dbHostName parameter created earlier.
    Figure 16. Setting the environment parameter
    Setting the environment parameter
  7. Click OK. The new instance and the new environment are created.

The RAFW_ENVIRONMENT field is concatenated with the cell name to determine the name of the configuration definition that models this new instance. If the configuration definition already exists, the script package updates the topology and host names based on the new instance. If not, a new configuration definition is created.

After creating the new configuration definition, Advanced Middleware Configuration runs the Execute automation plan to push the application and configuration data into the new running instance.

The new HitCountInstance includes the HitCount application because it is part of the template that is applied to each new instance of the HitCountVSP.

The HitCount instance is ready to use. For more information regarding this process, see Integration script package flow later in this article.


Deploying new instances of the application

You can now create as many exact copies of your finished instance (HitCountInstance in this example) as you want. For each instance, complete the following steps:

  1. From the Virtual Systems display, click the name of your VSP (HitCountVSP in this example).
  2. Click Deploy.
  3. In the deployment window, provide the following information:
    1. A unique name for the new server instance
    2. A unique environment name (RAFW_ENVIRONMENT) for the configuration definition to be created for this instance
    3. Values for any custom tokens from the promote.properties file
  4. Click OK.

Updating the template

You will typically make changes to the instance that is now running in the cloud. These changes might include updating the application, reconfiguring the topology, or installing new middleware. If you want to save these changes to the template, complete the following steps:

  1. Import the changes from the live configuration to the configuration definition. In the PureApplication System Workload Console, click Instances > Virtual Systems and then click the name of your instance (HitCountInstance in this example). Expand Virtual Machines. Expand the Deployment Manager part (or Server part if it is a standalone server) and scroll down to Script Packages. Locate the AMC Import Script Package and click Execute now, as shown in Figure 17. A product administrator User name and Password are requested, but you can leave these fields blank.
    Figure 17. The Import script package
    The Import script package

    When the import is complete, a green check mark and the current date and time are displayed next to the script package name.

  2. In the Advanced Middleware Configuration Eclipse client, Configuration Explorer view, locate the configuration definition for your instance.
    Figure 18. Configuration definition for the instance
    Configuration definition for the instance

    Drag the configuration name to the Configuration Workspace view.

  3. In the Configuration Workspace view, right-click the configuration name, and then click Add New > Update Configuration Template.
  4. In the Configuration Template window, select the template to update and click OK.
  5. The template is displayed. Save the template.

Optimizations

The following sections describe best practices for using the onboarding process.

Avoid configuring application servers directly

Each application server contains a large amount of configuration data. By default, Advanced Middleware Configuration pulls in the entire application server configuration by making a connection to the node hosting the application server. Often only a small portion of the application server needs to be configured, such as enabling the Service Integration Bus (SIB) service or adding a JVM argument. In this case, you can store the settings at the cluster scope and apply them uniformly to each application server in the cluster by making a single connection to the deployment manager (per cluster). This single connection to the deployment manager and managing only the portions of the application servers requiring configuration changes decreases the time required to manage the configuration.

Avoid scopes without configuration

If the resource configuration data is all maintained at the cell or cluster scope, there is no need to waste time running actions at the node and server scopes. Disable the appropriate steps in the the automation plan as shown in Figure 19.

Figure 19. Clearing steps for scopes with no configuration
Clearing steps for scopes with no configuration

Restrictions

  • Do not change your passwords.
  • Specify RAFW_HOME_PATH as /tmp/RAFW.
  • The WebSphere Application Server major version that you use to seed the template at creation time must match the WebSphere Application Server major version of the virtual system parts in the VSP.

Additional information on deploying an application to a VSP

This section provides details on what happens during deployment. Normally, a deployment requires no input or interaction from you.

Process Flow

When you deploy the VSP, the Integration script package completes the following steps. The separate servers in the diagram represent virtual servers, that is, instances of virtual system patterns in PureApplication System.

  1. The user deploys an instance of the virtual server (see Figure 20).
    Figure 20. Process flow step 1
    Process flow step 1
  2. The Workload Console installs and initializes WebSphere Application Server (see Figure 21).
    Figure 21. Process flow step 2
    Process flow step 2
  3. The script package passes the minimum information needed to discover the topology of the new instance and create a configuration definition for it (see Figure 22).
    Figure 22. Process flow step 3
    Process flow step 3
  4. The framework server then looks up the specified template and uses it to create or update a configuration definition that contains all of the application and configuration data from the template. Then the framework server pushes any applications and configuration information from the configuration definition to the new instance (see Figure 23).
    Figure 23. Process flow step 4
    Process flow step 4

See the Troubleshooting section for more information about the Integration script package flow.

Artifacts

The Integration script package creates the artifacts shown in Figure 24 in the Advanced Middleware Configuration console:

  • RAFW_env_config, which creates or recreates a live cell that corresponds to the configuration definition.
  • RAFW_env_config_compare, which records differences between a configuration definition and a live cell.
  • RAFW_env_config_execute, which makes changes to a running virtual system.
  • RAFW_env_config_import, which captures changes from a running virtual system.
Figure 24. Artifacts created by the Integration script package
Artifacts created by the Integration script package

Troubleshooting the script packages

This section describes how the Integration script package works and how to approach any problems you encounter when you run it.

Integration script package flow

The Integration script package completes the following steps:

  1. Extracts the packaged files in the directory /tmp/rafw.
  2. Runs the Advanced Middleware Configuration client. It establishes a connection to the framework server.
  3. Passes information to the framework server so that the framework server can discover the topology of the new instance.

The framework server then completes the following steps:

  1. Copies any needed scripts into the directory specified by the RAFW_platform_HOME_PATH parameter.
  2. Discovers the topology of the new instance.
  3. Creates or updates a configuration definition to represent the new instance, based on the specified custom template.
  4. Pushes any configuration information or applications in the template to the new instance.

Viewing the logs

You can use the script package logs and automation plan logs to help you with troubleshooting.

Script package logs

You can view the logs for the script packages by expanding the dmgr part (or the standalone part) in the Instances > Virtual Systems view for your newly deployed VSP. Near the bottom of the expanded section is a listing of all the script packages run, similar to the one in Figure 17.

The remote_std_err.log file contains the log information for each script package.

Automation plan logs

To view the results of the automation plan that was used to configure resources and applications in the VSPs, log on to the framework server using the web client:

  1. In the Consoles section of the framework server Virtual System Pattern instance, click AMC to open the Advanced Middleware Configuration web interface.
  2. Within the web interface, click the Jobs menu item. Locate the job within the list. The job is named "RAFW_env_cell_*", where the asterisk represents the word execute, import, or compare.

Troubleshooting tips

The following errors are common:

  • There is an incorrect hostname for the framework server, or incorrect credentials for the framework server user.
  • The RAFW_HOME_PATH script package parameter fails to correspond to the value specified for OS_RAFW_HOME on the framework server. The default for AIX or Linux is /tmp/RAFW. If the value on the framework server differs from the value of the RAFW_HOME_PATH entry, a problem might occur in creating the required directories on the VSPs.
  • A non-unique RAFW_ENVIRONMENT parameter value is specified in the Integration script package, which can result in the incorrect configuration being pushed to the deployed cell.

Capturing an application from a VSP into Advanced Middleware Configuration

This section describes the workings of the Import script package.

Understanding the Import script package flow

The Import script package completes the following steps:

  1. Contacts the framework server and attempts to locate the cell definition associated with the virtual system to which it is attached.
  2. Creates a new job in the Advanced Middleware Configuration automation engine using the RAFW_env_cell_import project.
  3. Continues to contact the framework server to check the status of that job until it completes.

If a user accidentally interrupts the network connection by logging into the Advanced Middleware Configuration web interface directly, the script continues to wait and then reconnects.

The script package invokes the import automation plan to capture all of the resources configured and applications installed in the cell into the cell definition on the framework server.

Note: As mentioned earlier, each user can only have a single logon session. Log on to the web user interface as a different user than the one that was identified in the virtual system script package.


Conclusion

In the course of this article, you have seen how to start with a WebSphere application and use IBM PureApplication System and Advanced Middleware Configuration to create a virtual system pattern that includes the application, and that you can repeatedly deploy in the cloud.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational, Cloud computing, WebSphere
ArticleID=808966
ArticleTitle=Preparing for IBM PureApplication System, Part 4: Onboarding applications to the cloud using the Advanced Middleware Configuration tool V1.1
publish-date=08112013