Deploying a simple ADF App to a remote WLS server

No Gravatar

This article is a follow-up to 2 previous postings:
Understanding available WebLogic Server downloads for ADF Applications
and
Extending WebLogic Server for ADF Applications
and assumes you have followed the steps in both.
This means that you have JDeveloper installed on your local machine, that you have a WebLogic Server installed on a remote machine, and you’ve extended the WLS server with the required JRF template for ADF applications, and that you’ve started the WLS server with -Djps.app.credential.overwrite.allowed=true so that database credentials will be uploaded to the server when an application is deployed. If you haven’t done these steps, go back through the previous two posts and follow those instructions.

If you’re still with me, now you’re ready to deploy a simple ADF application to the server to validate that it’s ready for real ADF applications.

The easiest way to develop a simple ADF application (if you don’t already have one on hand) is to follow the cue cards.

  1. From your development machine, open JDeveloper and choose Help > Cue Cards and select the Build a Fusion Web Application cue card:
  2. cuecard

  3. The first step of the cue card is to install the schema. The example uses a hostname of localhost, meaning that the sample schema is installed on a local database. If you’re going to be deploying to a remote machine with WLS installed, then the schema will need to be installed somewhere where the remote machine can connect to, such as your team’s shared database. Keep that in mind through the first step and then follow through all the steps in Part 1 and Part 2 of the cue card to create the example. You’ll end up with an application with ADF business components, an ADF task flow, and two ADF Faces views:

    Task Flow for sample application

    If you want to cheat a bit, you can download the application completed through parts 1 and 2 of the cue card here.

  4. The last step of Part 2 of the cue card is to run the application locally. This is a step that you should always perform on any application before you deploy it, to ensure that it runs properly and does what you expect. This is the primary reason that WLS is embedded in JDeveloper; you can test incremental changes in an application without having to redeploy the application. Make sure that you perform this step. For the example application, you should see the following when running locally:

    runtime view of example ADF app

  5. Once the application runs successfully locally, create a connection in JDeveloper to your shared WLS server. Open the Resource Palette, right click Application Server, and choose New Application Server connection:

    resource palette

  6. Specify a name for the connection, such as SharedDevServer, and leave the default WebLogic 10.3 specified as the connection type:

    name the connection
    Click Next

  7. Specify the username and password you created when installing WebLogic Server, such as weblogic and welcome1:

    enter WLS username and password

    The security people will be after me if I don’t mention here that you should not actually use the default password, but this is the password that the JDeveloper-embedded version of WebLogic Server uses, so there you go. Click Next.

  8. Enter the hostname where you have installed WebLogic Server, and the port you installed to (7001 by default). Additionally, enter the domain that you extended with JRF. If you did not create a new domain, this might be “AdminServer”, but that’s actually not recommended because the AdminServer domain has enough tasks to do without hosting your applications. If that’s the case for you, you might want to go back to step 11 of the appendix in Steve Muench’s article and create a new domain and then extend that domain with the JRF files. In my previous post, I extended the my_domain domain and so that’s the domain I specify here:

    enter configuration details

  9. Finally, test the connection. A crucial step. Ensure that all tests complete successfully:

    test connection

  10. At this point, there’s a few things to do to make life easier for this test deployment. The first thing to ensure is that when deployed to a remote machine, that machine has access to the data source connection that the application uses. You could do this by creating a global data source in WLS and then configuring your domain to use that connection. However, we’re just testing here, so in the case that your application was built using a data source based on your local machine’s database (and presuming that the machine that you’re deploying to doesn’t also have a database running at localhost), change the database connection that the application uses to a remotely-accessible database where you have installed the FOD schema (see step two above). To do this, expand Application Resources beneath your Projects listing in the Application Navigator. Expand Connections, Database, and then right click FOD and choose Properties:

    database properties

  11. Change the connection details to point to your remotely-accessible database:

    database details

  12. The next thing that makes life easier for this test deployment is to limit the amount of typing that you have to do to access the application remotely. Some history: JDeveloper uses the name of your application, the name of your project, and then “context-root” for the root url of your web application (BrowseEditApp-ViewController-context-root, for example). It does this because it can then ensure that the url to any application that you run in the embedded server in JDeveloper is unique. However, when you run a web application in JDeveloper, the browser is automatically launched for you and you don’t have to type a url. This is fine for testing locally, but you can make things easier for deployment by changing the default url to something more manageable. To do this, double click on your web application project (ViewController) to bring up the project properties. Click the Deployment node and select the Deployment Profile:

    project properties

    You might have noticed that you didn’t have to explicitly create deployment profiles for your application (.EAR), data model (.JAR) or web applications (.WAR) – JDeveloper creates them for you and you only need to modify them if you have specific deployment configurations to consider. Click Edit to edit the automatically generated WAR deployment profile.

  13. On the General page of the WAR deployment profile dialog, select Specify Java EE web context root and enter a more user-friendly name, such as BrowseEditApp:

    specify context root

  14. You’re now ready to deploy. You will be deploying the default EAR file profile, which is stored at the application level, and includes the WAR profile that you just modified as well as the JAR file that was automatically defined for the ADF Business Components Model project. Click the dropdown next to your application name, and choose Deploy. A series of context menus will appear as you select the name of your application’s EAR deployment profile (BrowseEditApp_application1 by default), to, and then the name of your shared server that you defined in step 5 above:

    deploy to shared server
    The deployment log will appear in JDeveloper, and you should see a successful deployment like the following:

    deployment success

    If you see errors instead, check that you’ve followed the post for extending your domain.

  15. Now you can access your application from a browser. The url will be the hostname of your server, the port (default 7001), followed by the context root of your web application, followed by the servlet url “faces” because this is a JSF application, followed by the name of your starting .jspx page. In this example application, you don’t have a starting .jspx page because your starting point is actually an ADF task flow and a slew of parameters are required to load the task flow properly (in most applications, you’d have a starting index.jspx that redirects to your initial task flow’s url for convenience). So in this test, copy the Target URL from the log that was created when you test-ran the application locally in step 3 above. The tab for this log is called Running: DefaultServer. Click that tab and then select the entire contents of the Target URL:

    target url

    Right click and choose Copy, then paste that into a browser. Replace the local ip address with the hostname for your shared server, replace the 7101 embedded WLS Server port with the default standalone port of 7001, and finally replace the longer default context root with the one that you defined for this application. Leave all the remaining parameters as-is. The resulting url will be something like the following:

    http://sharedserver.mycompany.com:7001/BrowseEditApp/faces/adf.task-flow?adf.tfId=orders-flow&adf.tfDoc=/WEB-INF/orders-flow.xml

  16. Click enter to launch the application (you’ll see a spinning “O” first to let you know the application is loading). The result is your test application, deployed to a remote, standalone, JRF-extended WebLogic Server:

    deployed application

  17. Voila!

2 Responses to 'Deploying a simple ADF App to a remote WLS server'

  1. johnbk says:

    As a beginner, the series of posts on deploying adf applications are really helpful for me. The language used in your blog is very simple and easy to follow. Many thanks.

  2. Ravikumar says:

    This is very useful thanks a lot giving such a great explanation.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

For spam filtering purposes, please copy the number 8983 to the field below: