Migrating EnterpriseOne to WebLogic Server
•Download as PPTX, PDF•
1 like•1,105 views
We'll cover what the manuals don't about getting your EnterpriseOne users onto WebLogic Server. Learn from field experience, compare notes and discover what comes after the install to make your transition smooth and transparent.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Migrating EnterpriseOne to WebLogic Server
Similar to Migrating EnterpriseOne to WebLogic Server (20)
More from Velocity Technology Solutions
More from Velocity Technology Solutions (19)
Recently uploaded
Recently uploaded (20)
Migrating EnterpriseOne to WebLogic Server
- 1. Migrating EnterpriseOne to WebLogic Server Ivan Oss Velocity Technology Solutions November 7, 2012
- 2. Questions • Why do you need WebLogic Server? • What is new and different? • What’s the best way to deploy and configure WLS for EnterpriseOne? • How do you administer WLS?
- 3. Why WebLogic Server? • Oracle Application Server support ends with 8.98.4 • WebLogic Server rocks. • WebLogic is your density!
- 4. Key concepts and terms • WLS Deployment options • E1 Installation and deployment • Administration • Performance Diagnostics
- 5. Key concepts and terms • Node Manager: The agent • Administration Server: that performs lifecycle WebLogic’s administration operations for all the console running in its own Managed Servers on a WebLogic Java Application machine. Server. • Domain: A group of • Cluster: A group of Managed Managed Servers or Servers administered as if Clusters, controlled by a they were a single entity. single Administration Server. • Deployment: A java • Managed Server: A WebLogic application contained in a Java Application Server managed server. definition and its JVM process.
- 7. WLS deployment options • Installation methods • JVM startup settings • Domain configuration • HTTP Server options • Clustering • HTTP Load balancing • Java choices
- 8. WLS deployment options Installation methods: • OVM Templates • Install Wizard • Silent install script • Packaging and cloning domains
- 9. WLS deployment options Domain configuration • Single node domains • Multi-node domains • Domains scoped by function
- 10. WLS deployment options Clustering: • Managed Server clusters • Java Application clusters • Considerations Cluster: A group of Managed Servers administered as if they were a single entity.
- 11. WLS deployment options Java choices: • Oracle JRockit JRE • Oracle Sun JRE
- 12. Jrockit startup settings • Heap size • Settings for E1 performance – XXAgressive – XX:+UseCallProfiling • Remote JMX Support – Dcom.sun.management.jmxremote – Dcom.sun.management.jmxremote.port=9030
- 13. WLS deployment options HTTP Servers: • WLS HTTP • Oracle HTTP Server • Others
- 14. WLS deployment options HTTP load balancing: • Oracle HTTP Server • Appliances
- 15. E1 deployment • Mixing WLS with OAS and WAS • Domain discovery
- 16. E1 deployment Mixing WLS with OAS and WAS • Why? • Don’t share the serialized object tables!
- 19. Performance diagnostics JRockit Mission Control
- 20. Getting ready for production • Load test! • Document primary, secondary and tertiary lifecycle processes • Script complex processes • Train your staff
- 21. For more information or additional questions please email Ivan Oss, application engineering manager at Velocity Technology Solutions at info@velocity.cc, or call 866.638.2779 THANKS!
Editor's Notes
- My name is Ivan Oss.I’m with Velocity Technology Services. Velociy provides managed DR, infrastructure as a service and hosts Lawson and JDEdwards in the cloud. Before we get started, just let me ask, how many of you are currently running OAS? WebSphere? WebLogic?Ok, now, of those of you who are planning to go to WebLogic, how many are on tools 8.98? So, I’ve spent a lot of time installing, configuring and deploying JDEdwards on WebLogic Server Volocity’s cloud infrastructure and in the process we’ve gained learned a lot about WebLogic Server that’s of specific importance to JDEdwards customers. That’s the information I want to share with you today, so you can get a jump on successfully deploying new WebLogic server nodes in your JDEdwards environments.
- Ok, here’s the agenda. I’m going to move pretty quickly through the first two bullets so we can get to some of the more EnterpriseOne specific details. Now, this is obviously not going to be a step by step guide, but we’ll touch on what you need to consider and then I’ll publish this slide stack along with an appendix listing out the key items in summary.There should also be plenty of time for questions as we go or at the end if I don’t cover something.
- Ok, these are the terms for the basic WebLogic Server topology in order from the lowest level in the stack to the highest. The Node Manager just executes operations like shutdown, startup, deploy, etc directly on the machine where WLS is installed. It does this for all the local Managed Servers regardless of the domain they are in.Anything that the Administration Server has a definition for is considered part of its domain. Domains can span multiple nodes and include multiple managed servers and clusters. A Managed Server in WLS doesn’t match up exactly to the OAS concepts, but you can basically think of it as a “container” in OAS. One difference is that there’s a one-to-one relationship between a WLS Managed Server and it’s JVM, whereas you can run multiple JVMs in a single container in OAS.The Administration Server does three things. It centrally stores all of the Managed Server definitions in its domain. It provides a web interface to change those definitions and it listens for and relays Managed Server lifecycle commands to the appropriate node managers.The concept of a WebLogic cluster is really basic. If you mark two or more Managed Servers as belonging to a cluster, they are treated as a single entity for all lifecycle, administration and configuration processes. Notice, I didn’t say they share session memory or a java object cache or port addresses. We’ll talk about load balancing, but beyond that, I don’t plan on going into the setup for an application server grid because we don’t have time and most JDE customers really don’t need to go to such lengths.
- Here we have a very basic deployment. At the top there’s an HTTP load balancing appliance. Each box below is a machine with a single domain and all of the Managed Servers in each Domain are on same machine as the domain’s Admin Server.Now, lets talk about how communication among the components works. You can see in the diagram we have the good old Server Manager Agent on each machine or node. Let’s say I’m on the Server Manager Console and I want start the PY port on the JS01 machine to the left here. I click the button in Server Manager and it sends the command to the Server Manager Agent which relays the startup request to the Administration Server along with it’s credentials for authentication. The Administration Server recognizes the SM agent’s credentials and sends the Node Manager its own credentials and a startup request along with a fresh copy of the managed servers definition in XML format. The Node Manager authenticates the Admin Server’s credentials and runs the startup script for PY. Simple, right?
- First you need to make some decisions about how your deployment is going to look. So, we’ll briefly go over the considerations for each of the items on this list.
- Here are the options you would commonly want to consider for your installation mechanism. You can just make it easy on yourself and use the EnterpriseOne OVM Templates from edeliveryto produce a development environment on Oracle Linux. Everything is already done for you. You just install the OVM Server on bare-metal and then download the Linux and E1 WebLogic Server templates to create a working WebLogic domain, complete with managed servers for Dev, PY and Pristine JDE_HTML instances. It even gives you a Server Manager Agent. After that, extending the domain to include managed servers for PD is easily done through the WLS Admin Console using its server clone function. Right now, the OVM templates deliver Tools release 8.98.4, so if you are going to 9.1 you’ll need to follow up with an upgrade of the JDE components.The good old install Wizard will also give you the option to create a domain and a managed server. E1 requires you choose “Production Mode” for all environments. You’ll also need to make some adjustments to the JVM startup parameters in order to run E1 effectively. We’ll talk a bout those in a bit. Once you have one Managed Server created you can clone it to create your other environments.Silent installs are easy to do as well. They just read an XML file and put the WLS software in place. You can also package a domain and then use the resulting file to deploy a complete copy of it to another node. So, you can really automate the entire process if you have a lot of installs to do.
- Choices for your Domain Configuration are numerous, so lets take a minute to consider what makes sense for the typical E1 install. Generally speaking, I like to keep things as simple as possible while still ensuring availability. So, first I would recommend at least 2 managed servers for your PD users, even if you only have something like 10 concurrent users. Second, I would put the servers on separate machines so you don’t lose them both in a single hardware or OS failure. Third, I would load balance them with a solution that can dynamically re-direct traffic when a server becomes non-responsive. If you can take care of those three things, I think you’re in good shape. The remaining considerations are around administration. Basically, each domain has its own WebLogic Administration Console. So, if you put all your servers in one domain, you can centrally manage them. However, if you lose the Admin Server, you lose the ability to administer any of those servers, so you have to consider protecting it or limiting the impact of losing it somehow. One way is to just to use two or more single-node domains, so you have redundancy of both the applications and the administration utilities.A multi-node domain has some benefits too. You can use the WebLogic Admin Console to move servers from one node to another, scale to it to new nodes and deploy clones to them, administer everything centrally and so forth. Generally, if you are going to create a multi-node domain, you would probably want to scope it by the function of the servers. So, you might put all your production servers in one domain and your nonproduction in another.
- WebLogic clustering is just logical grouping of Managed Servers within a domain that are administered as a single entity. makes administration more efficient and prevents configuration differences on like entities. The second type of clustering is what most of us think of when we hear the word. Here we’re talking about the Creation of two or more sets of application services that run as a single entity and share their data so if one of the member nodes fails, services are not interrupted and no data is lost. This type of cluster has to include a shared data cache for user session and it has to seamlessly pass user sessions to a surviving node or the user gets an error. This is unacceptable for something like a customer buying a plane ticket through your portal. Generally speaking, if your EnterpriseOne business users lose their session, they can sign back in and resume business without concern about data integrity issues or questions like “Did I book that flight or not?”. The E1 web application is good about externalizing all it’s transactional and state data, so in a basic, business use environment, there’s not really a need to cluster the E1 java tier. Of course, as with all of the Oracle products, you have a robust HA framework if you do need it, but that’s outside of the scope of this presentation.
- My experience has been that the JRockit JVM performs very well and doesn’t require a lot of tuning. By default, it dynamically manages it’s heap allocation, which seems to work fine with E1. I can’t say if its faster than Sun or not. I recommend you use JRockit because Oracle wants you to and its well instrumented and supported. Also, they say its faster. You’ll need to install it before you install Weblogic because you’ll need to specify which you want to use. You could also install it later and change your configuration manually. That’s not a big deal to do.
- The settings I’ll give you are for JRockit. If you stick with the Sun distribution, your on your own. JDEdwards put out a document called “Jrockit Tips for E1”. I’ll give you there recommendations as well as our experience.The document calls for a 2GB heap for a machine with 4GB of memory and we’ve had good success running our PD instances on 2 GB JVMs. That should handle at least 50 users, depending on what they’re up to. Of course, if you get someone doing a big grid export, all bets are off. They also recommend setting the min heap the same as the max.The -XXaggressive option is a collection of configurations that make the JVM perform at a high speed and reach a stable state as soon as possible. To achieve this goal, the JVM uses more internal resources at startup; however, it requires less adaptive optimization once the goal is reached.-XXaggressiveThis UseCallProfilingoption enables the use of call profiling for code optimizations. Profiling records useful run-time statistics specific to the application and can increase performance because the JVM can then act on those statistics. This provides a significant performance improvement with E1.-XX:+UseCallProfilingYou should also consider configuring a jmxremote port to allow you access to JRocket’s management beans from other machines. Jrocket Mission Control uses JMX to give you a nice GUI for gathering and analyzing runtime performance data on the JVM. In order to run it remotely, you need to put the JMXRemote arguments in the JVM startup parameters. -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9030 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=tk0089js01 -Djavax.management.builder.initial=weblogic.management.jmx.mbeanserver.WLSMBeanServerBuilder So, the three things to remember when you go looking for the actual syntax in the appendix are “Xxaggressive”, “UseCallProfiling” and “JMXremote”.
- You have some options for the HTTP server configuration as well. WebLogic Server comes with its own HTTP server built in or you can use Oracle HTTP or a non-Oracle product web server like IIS or Apache in front of your WebLogic servers instead. For anything but WebLogic, you would just use the appropriate WebLogic Server plugin that forwards the HTTP requests to your WebLogic managed servers. One reason that you might want to use Oracle HTTP or some other HTTP server as your front-end is that you can also have it do load balancing for you. It could also let you reduce the number of individual HTTP configurations rather than having one on every node.
- Load balancing with an HTTP server is going to be a basic round-robin style distribution. That’s probably ok from a performance standpoint unless you have a sick server in the mix. If it’s non-responsive, the Oracle HTTP plugin for WebLogic Server can detect that and move on. The timeout for that is configurable. The plug-ins will not recognize application level failures. They notice container level failures, meaning the Managed Server itself stops working. Another approach is to use an appliance like the F5 Big-IP for load balancing, compression and SSL in conjunction with the native WebLogic HTTP server on each of your managed servers. This allows you off-load encryption and compression while maintaining application appropriate control of the web servers. In this scenario, you would need to make sure you turn off compression in the web.xml file for each of your JDE_HTML deployments so you don’t compress everything twice. Similarly, you would not configure your Managed Servers to use SSL if you were encrypting with your appliance.
- Ok, now you have your WLS installed and your Managed servers waiting. Finally, we’re ready to talk about the E1 deployment itself.The headings here are just areas I want to address because there are things you need to be aware of. The first bullet here is probably the most important, so let’s get to that.
- If you’re upgrading from 8.98.4 dot something to 9.1, there’s two ways to do things. You could just set up new WLS servers in a brand new 9.1 implementation and then cut everyone over to the new servers, or you could pre-migrate your web tier ahead of the 9.1 cutover. I think the latter way presents less risk and makes your cutover less complicated. You just add new WLS servers to your existing environments and get everything stable and then decommission your old OAS servers ahead of cutover.Which brings us to the next bullet on serialized objects. OAS uses JDK 1.5 but WLS requires JDK 1.6. The java class that E1 uses to serialize and de-serialize objects is not cross compatible between JDK 1.5 and 1.6. So, if you use the same set of serialized object tables for both types of servers, you’ll get errors in your jas logs indicating the incompatibility and users will have strange experiences where forms don’t render properly on one server but it’s fine on another. The solution is simply to create a special copy of the serialized object tables for your WLS servers. Configure a new datasource in E1 and set your jdbj.ini to point to the tables. You’ll need to do all of this before you start the WLS servers in your environment, otherwise whatever server uses an object first will serialize it in it’s own way and the other won’t be able to de-serialize it!For you WebSphere users, since E1 supports WebSphere with JDK 1.5 or JDK 1.6, upgrade it to 1.6 if it’s not already there. I think that’s easier and cleaner than maintaining separate copies of F98998 and F98999.
- At this point, you’ve got the server manager agent installed and running, you’ve gone to the server manager console and added your WLS instance and now you’re wondering why it’s not showing you any of the Servers you’ve already set up. Well, there are a few things you need to do first. You need the AdminServer running. If you just start it using the provided script, you’ll be prompted for the admin server’s user name and password. In order to run start it without being prompted, you need to create a boot.properties file in the domain home for each of your servers. You can key the username and password in plain text and WLS will encrypt and use those values. That way you can run the startup scipt in the background and leave your console session when you’re done.Step one is to start up node manager – in the right location. When you register your nodemanager with the AdminServer, it creates a home directory wherever you registered it from. So, if you start it while you’re in the root directory, that’s where it will make it’s home, and the SM Agent won’t find it. SM Agent wants the nodemanager directory to be in $WL_HOME/common. So, CD to that directory and then issue the command to start it. Don’t forget to register the NodeManager with the Admin Server.Now you can ask the AdminServer to start up one of your managed servers. You can either use the WLS Admin Console through its URL, or you can start it manually using the WebLogic Scripting Tool life cycle command syntax. We’ll talk a little more about the lifecycle commands you need later.So, what happened when you started the managed server? The Admin server relayed the request along with a file called config.xml to the nodemanager which stashes the config.xml it in it’s home directory. That’s the file that the SM Agent is looking for! It defines all the entities in the domain. Once it finds that, you’ll see all of your managed servers represented in the SM Console and you can move on to deploying the JDE_HTML instances.
- Ok, lets talk a little about administration… mainly lifecycle management. First, remember in this diagram, how the lines of communication go.SM Console sends the command to the SM Agent and that forwards the request to the Admin Server, etc… What this means is, you have to have a running SM Agent, Admin Server and Node Manager to do anything with your managed instances from the SM Console. If the SM Console shows the status of all of your servers as “unknown” it usually means that the Admin Server isn’t responding to the SM Agent. If the status of your servers is up to date but start or stop commands from the SM Console fail, it usually means the nodemanager is down.You can also issue commands from the WebLogic Admin Console, in which case, you don’t need your SM Agent, and if you’re in a pinch and can’t get your Admin Server running, you can start and stop Managed Servers directly from the Nodemanager itself.You can send commands to the Admin Server with the console or using the WebLogic Scripting Tools. WLST commands can be pretty involved in a lot of cases, so I recommend you create scripts to simplify the syntax for your users. I’ve included some useful stuff in the appendix. You should also make sure you have scripts ready in case you need to send commands directly to the NodeManager because you have a problem with your AdminServer. The nodemanager is designed to monitor your servers and can be configured to re-start them if they go down using whatever script you specify. Depending on the cause of death, that may or may not be a good thing. Generally the E1 application doesn’t die without good reason, so re-starting it without an investigation is usually a bad idea, but restarting the Automatically is useful.You can also update the running E1_HTML deployment itself without shutting its managed server down. WebLogic will allow the introduction of certain types of changes dynamically to the running instance. The AdminServer console has a fairly intuitive interface for this and will tell you whether or not your changes require a restart of the E1_HTML deployment.
- JRockit Mission Control is a nice GUI interface that allows you to watch your application events in real time.You can also make what is called a “Flight Recording” that collects a comprehensive set of event data for a period of time. Anyone with an install of JRocket Mission Control can then use it for analysis of what’s going on. It’s a great tool if you’re doing something like a user load test.You can even set up a graph to show how many users you have in E1! Basically everything in the E1 JAS application is exposed through management beans, so you have access to their data using JRMC. That’s what I have on the left here; the tree where you find the E1 user count beans.You’ll probably want to run this remotely rather than on your JAS server because it does take some resources so remember to set up your remote JMX port in the JRockit startup parameters.