z/OS installation and configuration overview WebSphere Process Server for z/OS V7.0 WebSphere Enterprise Service Bus for z/OS V7.0 z/OS installation and configuration overview This presentation will cover the installation and configuration of WebSphere® Process Server for z/OS V7.0 and WebSphere Enterprise Service Bus for z/OS V7.0 Goals Goals Describe prerequisites and product packaging Describe WebSphere Process Server for z/OS V7.0 configuration process The goals of this presentation are to look at the prerequisites and packaging of the products and then look at the configuration of the products at a high level. Once you understand the high-level process, you can look at the more detailed presentations that talk about the various configurations. WebSphere Application Server, ESB, and Process Server WebSphere Application Server, ESB, and Process Server WebSphere Application Server WebSphere Application Server Network Deployment WebSphere Enterprise Service Bus WebSphere Process Server Application server Clustering Mediation Choreography This slide is meant to show where the WebSphere Process Server and the WebSphere Enterprise Service Bus fit in the product stack. Notice that the WebSphere Enterprise Service Bus is built on top of the WebSphere Application Server which provides the Java™ 2 Enterprise Edition framework for the stack products. The WebSphere Enterprise Service Bus adds mediation capabilities to the picture, allowing mediation of message flows between service requestors and providers. WebSphere Process Server is built on top of that, which means that the WebSphere Process Server includes the mediation functions found in the WebSphere Enterprise Service Bus. The WebSphere Process Server also adds choreography capabilities for business process management applications. Prerequisites and product packaging Prerequisites and product packaging Section This next section will look briefly at the prerequisites for the products and how the products are packaged. Prerequisites (derived from base WebSphere) Prerequisites (derived from base WebSphere) Hardware requirements Any hardware that supports z/OS and z/OS.e V1.7, or later Software requirements z/OS 1.7 or higher or z/OSe 1.7 or higher with several features installed, enabled and configured. They are: z/OS Communications Server (TCP/IP) or equivalent z/OS UNIX® System Services and hierarchical file system (HFS) or zSeries file system (zFS) support SecureWay™ Security Server (RACF®) or equivalent security management product System logger System SSL security required when using SSL Workload management in goal mode Resource recovery services Requirements officially documented here: http://www.ibm.com/support/docview.wss?rs=2307&uid=swg27016269 The requirements for WebSphere Process Server for z/OS V7.0 and WebSphere Enterprise Service Bus for z/OS V7.0 come from the base WebSphere Application Server. WebSphere Process Server or the WebSphere Enterprise Service Bus is installed on top of the base WebSphere Application Server. Notice that z/OS 1.7 is the minimum z/OS level with WebSphere Process Server V7.0 and WebSphere Enterprise Service Bus V7.0. For an official list of requirements, you can refer to the Web site shown on the slide. Implementation options (optional) Implementation options (optional) DB2® Universal Database™ Server for z/OS, Version 8 or higher Need stored procedure builder enabled (DSNTPSMP/WLM Environment) if using Relationships CICS® TS for z/OS V2.3 and above Information Management System, IMS™, V9 or later WebSphere MQSeries® for z/OS V6.0 and higher WebSphere Integration Developer 7.0 Many of the implementation options shown here, such as CICS and IMS, are determined by the applications that are run on the server. They are optional. In the case of DB2, if you plan to implement a Network Deployment solution with WebSphere Process Server or WebSphere Enterprise Service Bus, DB2 becomes a requirement. WebSphere Process Server and WebSphere Enterprise Service Bus require many databases as you will see during configuration of the product. The Stored Procedure Builder (DSNTPSMP) in DB2 also needs to be enabled if using Relationships. WebSphere Integration Developer V7 is the tool that should be used to build the applications to be run in a WebSphere Process Server environment. Prerequisites: Base WebSphere Application Server for z/OS Prerequisites: Base WebSphere Application Server for z/OS Minimum WebSphere base application server level: WebSphere Application Server for z/OS V7.0.0.9 -OR- WebSphere Application Server for z/OS V7.0.0.7 with ++APAR AK99267 This ++APAR also includes the V7.0.0.8 fixpack so no need to install 7.0.0.8 when available Minimum optional materials levels: WebSphere Application Server for z/OS V7.0.0 Optional Materials are required SCA 1.0.1 (APAR PM00924) XML 1.0 (APAR PM00740) SDO 2.1.1 (APAR PM00925) In order to use WebSphere Process Server for z/OS and WebSphere Enterprise Service Bus for z/OS, you must be running WebSphere Application Server for z/OS V7.0.0.7 or later. At the V7.0.0.7 level, you are required to apply ++APAR PK99267. This includes the function contained in V7.0.0.8, however, so there is no need to apply 7.0.0.8. Once V7.0.0.9 is available, that will become the minimum level. You are also required to install optional materials SDO 1.0.1, XML 1.0 and SDO 2.1.1, as shown on the slide. The corresponding APAR numbers for these feature packs are listed. Prerequisites: WebSphere Process Server for z/OS, WebSphere Enterprise Service Bus for z/OS and feature packs Prerequisites: WebSphere Process Server for z/OS, WebSphere Enterprise Service Bus for z/OS and feature packs WebSphere Process Server for z/OS V7.0.0.1 or WebSphere Enterprise Service Bus for z/OS V7.0.0.1: Feature pack usermods (needed for SCA runtime problem) – need to request these from support PM03252 for the Feature Pack for SCA V1.0.1. PM03254 for the SDO 2.1.1 Feature of the Feature Pack for SCA V1.0.1. PM03255 for the Feature Pack for XML V1.0.0 WebSphere Process Server for z/OS and WebSphere Enterprise Service Bus for z/OS V7.0.0.1 is the minimum required level for full function of the product. It became available in January 2010 and should be the minimum level for a successful configuration and running of the products. You should also ensure that you have the APARS shown for the required feature packs. They are not in the base levels shown on the previous slide and will need to be requested from support until they become generally available. Important URLs Important URLs Recommended interim fixes: http://www.ibm.com/support/docview.wss?uid=swg21414253 Includes APAR numbers ++APAR AK99267, required for WebSphere Application Server for z/OS V7.0.0.7 found here for download Known issues: http://www.ibm.com/support/docview.wss?uid=swg27017572 Documents known issues and their circumvention z/OS only Shown here on the slide are some important URLs. The first one lists known problems for WebSphere Process Server V7 and WebSphere Enterprise Service Bus V7. Here is where you will find a link to the required ++APAR that is needed for WebSphere Application Server for z/OS V7.0.0.7. The second URL is z/OS-specific and lists known issues with circumventions. This is a handy reference if you see any problems. Packaging Packaging Each product INCLUDES base WebSphere Application Server for z/OS HESB700 WebSphere Application Server for z/OS V7.0.0.7 WebSphere Enterprise Service Bus for z/OS WebSphere Application Server for z/OS Optional Materials HWPS700 WebSphere Application Server for z/OS V7.0.0.7 WebSphere Process Server for z/OS (includes ESB) WebSphere Application Server for z/OS Optional Materials This slide shows the packaging of the products. WebSphere Process Server for z/OS V7.0 and WebSphere Enterprise Service Bus for z/OS V7.0 are built on top of WebSphere Application Server for z/OS V7.0. This includes some feature packs that are shipped as PTFs on the Optional Materials FMID. When you order either product, you will receive a copy of the base WebSphere Application Server for z/OS at the latest PTF level and the code for the Optional Materials FMID. You should note that V7.0.0.7 is the minimum required PTF level. Until V7.0.0.9 is available, the ++APAR AK99267 noted on a previous slide is also required. You should also note that the WebSphere Process Server product INCLUDES the WebSphere Enterprise Service Bus product so the WebSphere Enterprise Service Bus product is really a subset of the WebSphere Process Server product. Structure for WebSphere Process Server for z/OS and WebSphere Enterprise Service Bus for z/OS Structure for WebSphere Process Server for z/OS and WebSphere Enterprise Service Bus for z/OS PSP Bucket: http://www.ibm.com/support/docview.wss?uid=isg1_WPSZ_HWPS700 H28W700 JIWO700 HWPS700 (HESB700) Configured on top hlq.SBBOHFS /usr/lpp/zWebSphere/V7R0 hlq.SBPZHFS (hlq. SBSBHFS) /usr/lpp/zWPS/V7R0 (/usr/lpp/zWESB/V7R0 1000 cyls (550 cyls) hlq.SIWOHFS /usr/lpp/zWebSphere_OM/V7R0 WebSphere Process Server for z/OS and WebSphere Enterprise Service Bus for z/OS are configured on top of WebSphere Application Server for z/OS and the WebSphere Application Server for z/OS Optional Materials FMID, as seen on the slide. Starting with V7, all products involved in the configuration are completely contained within its HFS. When WebSphere Process Server for z/OS or WebSphere Enterprise Service Bus for z/OS are completely configured, you will point to a minimum of three product HFSes. WebSphere Application Server for z/OS, WebSphere Application Server for z/OS Optional Materials and WebSphere Process Server for z/OS (or WebSphere Enterprise Service Bus for z/OS) each SMP/E install into their own HFS. You should note that while the Program Directory specifies 774 cylinders for the WebSphere Process Server HFS and 440 cylinders for WebSphere Enterprise Service Bus HFS, you will actually use more than that. WebSphere Process Server uses 1000 cylinders and WebSphere Enterprise Service Bus uses 550 cylinders. Configuration process overview Configuration process overview Section The next section will look at an overview of the configuration of WebSphere Process Server for z/OS V7.0 and WebSphere Enterprise Service Bus for z/OS V7.0. Configuration options Configuration options Stand-alone environment Limited to one server Derby – highly automated! DB2 Network deployment environment Multiple servers, clustering available DB2 only! Stand-alone node OR managed (custom) node Manual tasks needed Before starting the configuration of WebSphere Process Server or WebSphere Enterprise Service Bus, you should have an idea of where you are going. Will you need a network deployment environment with clustering or are you just starting out and are looking for an easy environment to set up? To get a look at the various pieces that make up the WebSphere Process Server or WebSphere Enterprise Service Bus environment, a highly automated option using Derby is available. You’ll see that this is the quickest configuration and can be a good place to start if you are new to the product. The stand-alone configuration with DB2 can also be highly automated but you will need to get your DB2 administrator involved to configure that environment. If you will be using DB2, you should review the z/OS DB2 configuration presentation. As you move into the network deployment environment, not only is DB2 your only database option, you add some manual tasks to configure the various pieces of the WebSphere Process Server or WebSphere Enterprise Service Bus environment. With the exception of the DB2 configuration, these tasks can be completed in the administrative console but they are additional steps that are needed to complete the configuration. On the next few slides, you will look at the configuration at a very high level. Other presentations are available to look at the various configuration options in more detail. Installation task overview Installation task overview Configure WebSphere base application server with required feature packs (SCA/XML/SDO) ‘Install’ WebSphere Process Server or WebSphere Enterprise Service Bus function into node profiles (zWPSInstall.sh/zWESBInstall.sh) ‘Augment’ profiles with WebSphere Process Server or WebSphere Enterprise Service Bus function (zWPSConfig.sh) Complete post-configuration tasks, if needed To configure WebSphere Process Server or WebSphere Enterprise Service Bus, there are four general tasks that you need to complete. To start with, you need to configure a WebSphere Base Application Server that will host the WebSphere Process Server or WebSphere Enterprise Service Bus function. This application server also needs to be augmented with the SCA, XML and SDO feature packs. Next, a couple of scripts need to be run against each node that you are configuring. The first script, zWPSInstall or zWESBInstall, will ‘install’ the WebSphere Process Server or WebSphere Enterprise Service Bus function into the node’s profile, creating links to the product code. The second script, zWPSConfig, will augment the node with WebSphere Process Server or WebSphere Enterprise Service Bus function, configuring the various pieces needed to run applications that exploit the function. Finally, there are some post-configuration tasks that you will need to complete depending on whether you are configuring a stand-alone or a Network Deployment environment. 1. Configure WebSphere base application server with required feature packs (SCA/XML/SDO) 1. Configure WebSphere base application server with required feature packs (SCA/XML/SDO) Configure WebSphere base application server with SCA, XML and SDO feature packs Stand-alone application server cell Network deployment cell Deployment manager node and empty node (managed (custom) node) Deployment manager node and stand-alone node WebSphere Customization Tools (WCT) is required for configuration Download site: http://www.ibm.com/support/docview.wss?rs=180&uid=swg24020368 Need to install some WebSphere Customization Tool (WCT) extensions that are shipped with various product code WPS: -PathPrefix- /usr/lpp/zWPS/V7R0/util/WCT/zWBI.wct WESB: -PathPrefix- /usr/lpp/zWESB/V7R0/util/WCT/zWBI.wct SCA: /usr/lpp/zWebSphere_OM/V7R0/FPSCA/util/WCT/sdo.wct XML: /usr/lpp/zWebSphere_OM/V7R0/FPXML/util/WCT/xml.wct SDO: /usr/lpp/zWebSphere_OM/V7R0/FPXML/util/WCT/xml.wct The first thing you need to do when configuring WebSphere Process Server for z/OS or WebSphere Enterprise Service Bus for z/OS is configure a WebSphere base application server with the SCA, XML and SDO feature packs. Depending on the environment planned, you need to create a stand-alone application server cell or a full network deployment cell. The stand-alone application server cell is a nice place to start and can be highly automated for the WebSphere Process Server or WebSphere Enterprise Service Bus configuration as noted earlier. If creating a network deployment cell, you need to configure a deployment manager node AND either an empty node OR a stand-alone node. The empty node is labeled as a ‘managed (custom)’ node in the zPMT tool. However, do not federate either until later. In order to configure an environment for WebSphere Process Server for z/OS or WebSphere Enterprise Service Bus for z/OS, you’ll need to use the WebSphere Customization Tools (WCT) which the zPMT is part of. In the gray box, you’ll find the download site along with a list of extensions that are needed. These extensions include required feature packs and, optionally, WebSphere Process Server for z/OS or WebSphere Enterprise Service Bus for z/OS. For more detailed instructions on how to install the extensions, see the presentation titled ‘IBM WebSphere Customization Tools extension installation’. 1. Configure WebSphere…using updated WCT WebSphere base application server 1. Configure WebSphere…using updated WCT Start with either SCA, XML or ‘vanilla’ server ‘Cell’ is not supported SCA XML ‘vanilla’ …then Augment After updating the WCT with the extensions needed, you will create a WebSphere base application server configuration. You can start with a ‘vanilla’ server which has none of the feature packs included, or a server that includes SCA or XML as shown on the slide. Starting with an SCA or XML configuration is recommended because it will reduce the number of steps needed to configure the environment. Select the environments needed for the final configuration planned. Your choices are ‘Management’, ‘Application Server’ or ‘Managed (custom)’. ‘Management’ will give you a deployment manager environment, ‘Application Server’ will give you a stand-alone application server, and ‘Managed (custom)’ will give you an empty node. You will eventually add the empty node to your deployment manager environment. Note that ‘Cell’ is not a supported environment. More detailed presentations on the configuration of a base application server are found under ‘WebSphere Application Server’. This presentation assumes you know the steps needed to do that. After finishing the configuration on your z/OS mainframe, you will need to augment your configurations with the feature packs. You will see that on the next slides. 1. Configure WebSphere…using updated WCT ‘Augment’ each node with SCA, XML and SDO 1. Configure WebSphere…using updated WCT Depending on what type of configuration option you started with, you will have to augment with up to three different feature packs. For instance, if you started with a configuration that included SCA, you will need to augment with just XML and SDO. If you started with a ‘vanilla’ server, however, you will need to augment with all three. You see that each of the feature packs are available for all three configuration options: Management, Application server and Managed (custom) node. You MUST augment each piece of the configuration you have planned. For instance, if you planned on a network deployment environment, then you need to augment both the Deployment Manager node and the Managed (custom) nodes that are federated into the environment. 1. Configure WebSphere…using updated WCT Upload and run jobs for SCA, XML and SDO: IWODAUGx - SCA IWODBRAK - SCA IWOJAUGx - XML IWOKAUGMx - SDO Where: x=A for application server augmentation x=N for managed node augmentation x=M for deployment manager augmentation 1. Configure WebSphere…using updated WCT Augment XML before SDO! This slide shows the ‘Process’ step which will upload the jobs that need to be run. Be aware that you must augment with XML before SDO. The job names that are created for the augmentation are shown on the slide. 2. ‘Install’ WebSphere Process Server or WebSphere Enterprise Service Bus 2. ‘Install’ WebSphere Process Server or WebSphere Enterprise Service Bus Much cleaner configuration using the WCT than V6.2 Preferred way starting with Version 7 Product still ships with sample response files: Alternatively, can still update these manually -prefix-/usr/lpp/zWPS/V7R0/zos.config DmgrDB2.rsp ManagedDB2.rsp standAloneProfile.rsp standAloneProfileDB2.rsp Configuring WebSphere Process Server for z/OS and WebSphere Enterprise Service Bus for z/OS using the WebSphere Customization Tools was introduced in V6.2. In Version 7, it becomes the preferred way to configure with WebSphere Process Server for z/OS and WebSphere Enterprise Service Bus for z/OS. Sample response files that you can update manually are still shipped with the product but the augmentation process in the WCT should provide you with updated response files that are less subject to typos and finger-checks. The WCT is also being enhanced so that eventually you will have JCL jobs that can be run to configure the system, automating the process even further. 2. ‘Install’ WebSphere Process Server or WebSphere Enterprise Service Bus… (1 of 5) 2. ‘Install’ WebSphere Process Server or WebSphere Enterprise Service Bus… (1 of 5) Augment each node with WebSphere Process Server in the WCT Specify the response file for the node you created Now that you have your nodes augmented with the required feature packs, you need to install WebSphere Process Server and WebSphere Enterprise Service Bus into each WebSphere Application Server node that you have created for your environment. To do this, use the WCT to ‘Augment’ each node with WebSphere Process Server. When you originally created the node you are augmenting, a response file was created. Specify that here now to populate the WCT panels with the correct values to correspond with the node already created. 2. ‘Install’ WebSphere Process Server or WebSphere Enterprise Service Bus… (2 of 5) Update to specify intermediate symbolic link, is using Specify a file name for database design Upload generated jobs and data hlq.CNTL(BPZDOLNK) hlq.DATA(BPZRSPx) 2. ‘Install’ WebSphere Process Server or WebSphere Enterprise Service Bus… (2 of 5) If using DB2 As you go through the augment in the WCT, most information is filled out from your response file if you specified one. Two screens that you should pay special attention to are shown on the slide. In the first one, you will need to change the base file system path name to its intermediate symbolic link if you are using one. It will default to the absolute path from the response file. The second screen shows the ‘Database Design’ input. If you are using DB2, you need to specify a database design file. You have not actually created the database design file yet, so take note of the name you fill in here. You will need this later when you run the DbDesignGenerator tool. For more information on this see the presentations that document the type of environment you are creating. Once you have filled out the screens in the WCT, specify ‘Process’ in the WCT to upload the data to your z/OS system. There are two members you are interested in, BPZDOLNK and BPZRSPx. You will see where to use these in later slides. 2. ‘Install’ WebSphere Process Server or WebSphere Enterprise Service Bus… (3 of 5) 2. ‘Install’ WebSphere Process Server or WebSphere Enterprise Service Bus… (3 of 5) If using symbolic links, run the BPZDOLNK job Run zWPSInstall.sh or zWESBInstall.sh script Tentatively starting with 7.0.0.2, JCL jobs will be also generated from the zPMT to run the zWPSInstall/zWESBInstall scripts for augmentation …in the meantime… You will use BPZDOLNK right away. The next step in the configuration process is to run either the zWPSInstall or the zWESBInstall shell script. If you plan on using symbolic links, you will want to specify the symbolic link that points to the WebSphere Process Server or WebSphere Enterprise Service Bus products when running the script. It needs to exist first. Eventually, a JCL job will be created from the zPMT to run the zWPSInstall and zWESBInstall scripts. Until that is available, however, the scripts need to be run manually or you have to create the JCL yourself. You will see that on the next few slides. 2. ‘Install’ WebSphere Process Server or WebSphere Enterprise Service Bus… (4 of 5) Name change from previous release! 2. ‘Install’ WebSphere Process Server or WebSphere Enterprise Service Bus… (4 of 5) Run zWPSInstall.sh or zWESBInstall.sh script Found in: /usr/lpp/zWPS/V7R0/zos.config/bin /usr/lpp/zWESB/V7R0/zos.config/bin Run against each node in your configuration ‘Installs’ WebSphere Process Server or WebSphere Enterprise Service Bus into your profile using many ant scripts Creates symLinks in for directories Updates the administration console for WebSphere Process Server or WebSphere Enterprise Service Bus Log files written to /logs/wbi directory /logs/wbi/zWPSInstall.log /logs/wbi/zWPSInstall.trace /logs/wbi/install/installconfig.log (or zWESBInstall) The zWPSInstall or zWESBInstall shell scripts need to be run against EACH NODE in your configuration. Note that the name has changed from the previous release. This means that if you are doing a network deployment configuration, the script needs to be run against the deployment manager node and the managed (custom) node or stand-alone application server node. The zWPSInstall script will run a lot of ant scripts that, among other things, will create symLinks to the WebSphere Process Server or WebSphere Enterprise Service Bus product code. The script will also update the administration console with plug-ins that are needed to configure the WebSphere Process Server or WebSphere Enterprise Service Bus functions. As shown on the slide, log files are written to the logs/wbi directory. The installconfig.log found in the installation directory is more verbose than the others and is a good place to look for errors. 2. ‘Install’ WebSphere Process Server or WebSphere Enterprise Service Bus… (5 of 5) 2. ‘Install’ WebSphere Process Server or WebSphere Enterprise Service Bus… (5 of 5) Command line structure Installing WebSphere Process Server for z/OS Definitions zWPSInstall.sh -smproot -runtime -install -trace -prereqonly -uninstall Install file system for WebSphere Process Server and Base Script name Procedure Trace Backup file system first! zWESBInstall.sh This slide shows the syntax for the zWPSInstall and zWESBInstall script commands. You need to only supply values for the smproot parameter and the runtime parameter. The smproot parameter tells the script where the WebSphere Process Server or WebSphere Enterprise Service Bus product code was SMP/E installed. The runtime parameter tells the script what profile you plan to add WebSphere Process Server or WebSphere Enterprise Service Bus functionality to. The ‘procedure’ parameter will normally be install. The prereqonly parameter verifies arguments and the environment. When specifying install, the code will automatically validate the arguments and environment, or in other words, perform the function of the prereqonly parameter anyway. The install parameter will create symbolic links from the WebSphere Application Server for z/OS /lib and /bin directories to the WebSphere Process Server or WebSphere Enterprise Service Bus read-only HFS directories. It will also enable WebSphere Process Server or WebSphere Enterprise Service Bus features by running configuration manager scripted actions. This will create any new administrative console plug-in extensions needed. A trace parameter is also available for debug. Before running this command, be sure to backup your file system first. 2. Run zWPSInstall.sh script…options -prereqonly Verify command arguments and environment. -install Validates prerequisites (see -prereqonly) Creates symlinks from the read-only file system directories to the /lib and /bin directories, installing the definitions. Enables features by running Configuration Manager scripted actions, thus creating new administrative console plug-in extensions. Creates post install file Updates code base permissions -uninstall Disables features by running Configuration Manager scripted actions and removes administrative console plug-in extensions... 2. Run zWPSInstall.sh script…options This slide spells out the various procedure options and talks in more detail about what each of them does when specified. As noted on the previous slide, you should always save or backup the WebSphere Application Server configuration root before configuring WebSphere Process Server or WebSphere Enterprise Service Bus in the WebSphere Application Server environment. 2. Run zWPSInstall.sh script…JCL example 2. Run zWPSInstall.sh script…JCL example JCL example of running zWPSInstall Note that a symbolic link has been specified for smproot trace example This is an example of running the zWPSInstall shell script from JCL. If you are using symbolic links for your product code, be sure to specify that here for the smproot parameter. This example also shows an example of using the trace parameter. 3. ‘Augment’ profiles with WebSphere Process Server or WebSphere Enterprise Service Bus 3. ‘Augment’ profiles with WebSphere Process Server or WebSphere Enterprise Service Bus Run zWPSConfig.sh or zWESBConfig.sh Found in: /bin/zWPSConfig.sh /bin/zWESBConfig.sh Run against each node in your configuration ‘Augments’ profile with WebSphere Process Server or WebSphere Enterprise Service Bus function using many ant scripts Create resource definitions Create resources (databases, buses, queues) Deploy needed applications Log files written to /logs/ directory /logs/wbi/zWPSConfig.log /logs/wbi/zWPSConfig.trace /logs/manageprofiles/default_augment.log In the third step, you will run another script, zWPSConfig or zWESBConfig, against each node in your configuration. If you are creating a network deployment cell, the managed (custom) or stand-alone node should not yet be federated. These scripts will again call many ant scripts which will augment the node profiles with needed resources and functions necessary for the WebSphere Process Server or WebSphere Enterprise Service Bus products. As listed on the slide, the augmentation will create needed resource definitions, create the actual resources such as databases, buses and queues and deploy needed applications. Other presentations go into more detail on what these resources and applications are. Log files for this script are written to the logs/manageprofiles directory. The default_augment.log is the best place to look for errors as it is more verbose than the others. Slide 28 3. ‘Augment’ profiles with WebSphere Process Server or WebSphere Enterprise Service Bus… Command line structure Configure WebSphere Process Server for z/OS zWPSConfig.sh -augment -response -Z -trace Script name Procedure Configuration response file Property Override Trace -Z parameter can override any values in the response file (useful for user ID/password) -trace ‘*=all=enabled’ zWESBConfig.sh Response file required -prereqonly The zWPSConfig and zWESBConfig scripts require that you provide a response file to provide information to the configuration process. Sample response files are found in the product HFS; those are shown on a later slide. A response file has also already been populated for you in the BPZRSPx member of the DATA PDS if you used the zPMT to augment your nodes. Using the one generated for you will help to prevent errors during the augmentation process. The augment and response parameters are the only required parameters when running the zWPSconfig or zWESBConfig scripts. The Z-parameter is used to override any of the properties specified in the response file. An example usage of this parameter is to specify user IDs and passwords on the command line so that they are not specified in clear text in the response file. You can also specify a trace string with the trace parameter if needed. To specify the trace string, put it in single quotation marks as shown on the slide. Both scripts are available with the WebSphere Process Server for z/OS product. When dealing with the WebSphere Process Server for z/OS product, it is possible to configure an Application Server with the WebSphere Process Server function OR the WebSphere Enterprise Service Bus function only. Remember that WebSphere Process Server INCLUDES the WebSphere Enterprise Service Bus function. If you have the WebSphere Enterprise Service Bus for z/OS product, only the zWESBConfig.sh script is available. 3. Run zWPS/zWESBConfig.sh script…options -prereqonly Validates that zWPSInstall.sh has successfully created the product definitions for WebSphere Process Server -augment Validates prerequisites Verifies arguments Enable profile augmentation using scripted actions Mutually exclusive actions 3. Run zWPS/zWESBConfig.sh script…options This slide again shows the various procedure options and talks in more detail about what each of them does when specified. They are mutually exclusive and you can only specify one. 3. Run zWPS/zWESBConfig.sh script…response files 3. Run zWPS/zWESBConfig.sh script…response files Needed by the zWPSConfig.sh and zWESBConfig.sh scripts Samples found in: /usr/lpp/zWPS/V6R1/zos.config /usr/lpp/zWESB/V6R1/zos.config Samples provided: standAloneProfile.rsp – Derby only standAloneProfileDB2.rsp DmgrDB2.rsp ManagedDB2.rsp Populated response file found in ‘hlq.DATA(BPZRSPx)’ where: x=A for application server augmentation x=N for managed node augmentation x=M for deployment manager augmentation wbidbDesign is a parameter needed for DB2 configurations wbidbDesign=/u/wsuser/wpswork/wps.nd.topology.dbDesign Now, let’s look at the response files needed by the configuration scripts. Again, the response files supply values needed for the configuration. Sample response files are found in the zos.config directory in the SMP/E install root. Four sample response files are provided. “stand-aloneProfile.rsp” is the response file used for the simplest configuration and uses Derby databases. It allows for an automated configuration of a stand-alone application server environment. To configure a stand-alone application server with WebSphere Process Server or WebSphere Enterprise Service Bus function using DB2, you will start with the standAloneProfileDB2.rsp file. That configuration can also be highly automated if you are able to configure the databases during augmentation. When you move to the network deployment configuration, DB2 is the only option for the databases and there are two response files for that configuration: DmgrDB2.rsp and ManagedDB2.rsp. You will first use the DmgrDB2.rsp file to augment the deployment manager node with WebSphere Process Server or WebSphere Enterprise Service Bus function. You then augment an empty node using the ManagedDB2.rsp file before federating it into the Network Deployment Cell. As noted earlier, you can also start with a stand-alone node in the network deployment configuration. In that case, you use the standAloneProfileDB2.rsp file to augment your stand-alone node before federation. Starting with Version 7, the zPMT augment function for WebSphere Process Server will populate a response file for you. When you ‘Process’ your augmented node to upload customization jobs to your z/OS system, a populated response file is uploaded. It is found in the BPZRSPx member of the DATA PDS where the ‘x’ is dependent on the type of node as shown on the slide. This is the recommended option as it should cut down on errors in the configuration process. You must copy this member to the HFS. You will see this on the next slide. Note that when you ‘augmented’ using the WCT, you specified a database design file name if DB2 was in use. This became a needed parameter, wbidbDesign, in your response file. To run the augment, it needs to exist so you need to run the DbDesignGenerator before running the augment if you are using DB2. You can find more information on dbDesignGenerator in the z/OS DB2 configuration presentation. 3. Run zWPS/zWESBConfig.sh script…USS example 3. Run zWPS/zWESBConfig.sh script…USS example Run zWPSConfig.sh or zWESBConfig.sh Copy response file into UNIX System Services (USS) from TSO oput 'HLQ.DATA(BPZRSPA)' '/u/s7admin/standAloneProfile.rsp‘ OR Copy response file from USS cp "//‘HLQ.DATA(BPZRSPA)'“ /u/s7admin/standAloneProfile.rsp Run shell script cd /etc/wasv7cfg/s7basea/s7nodea_wpssmpe/bin ./zWPSConfig.sh -response /u/s7admin/standAloneProfile.rsp -augment 1> /tmp/zWPSConfig_40135.out + 2> /tmp/zWPSConfig_40135.err An example of running the zWPSConfig shell script command from UNIX Systems Services is shown here. You can copy the response file from TSO using the oput command as shown or an example using the cp command from USS is also shown. 3. Run zWPS/zWESBConfig.sh script…JCL example 3. Run zWPS/zWESBConfig.sh script…JCL example JCL example of running zWPSConfig This is an example of running the zWPSConfig shell script from JCL. Notice the first thing you should do is copy the response file to the HFS. This example shows the copy being done using OPUT. You can use the ‘cp’ command in the BPXBATCH step instead. The copied response file is then used as a parameter to the zWPSConfig command. 4. Complete post-configuration tasks, if needed 4. Complete post-configuration tasks, if needed Stand-alone application server cell (with Derby) No post-configuration tasks!! Stand-alone application server cell (with DB2) Create DB2 databases and tables Network deployment cell Federate managed (custom)/stand-alone node Create DB2 databases and tables Configure WebSphere Process Server and WebSphere Enterprise Service Bus components If you are configuring a stand-alone application server cell using Derby as the database, you are done at this point! You can start your server and are able to exploit the WebSphere Process Server or WebSphere Enterprise Service Bus function right away. If configuring with DB2, there are most likely some post-configuration tasks that are needed. If configuring a stand-alone application server cell with DB2, you will need to talk to your DB2 administrator and have some SQL run to create databases and tables before having a fully functional environment. For more information on the DB2 requirements, you should look at the z/OS DB2 configuration presentation. If configuring a Network Deployment Cell, you need to federate the empty/stand-alone node into your network deployment cell and have the DB2 database and tables created. Depending on whether you decide to start with an empty node or a stand-alone node will determine the other post-configuration steps needed. If you are starting with an empty node, you will have to actually create a cluster or server in the environment before continuing configuration and configure the Service Component Architecture environment. If you are starting with a stand-alone node, you will have a server but you might need to configure CEI and the Business Process and Human Task containers. This depends on how much you allowed the zWPSConfig script to do for you. Some of the tasks that might be needed for the network deployment cell in either case are configuring the Business Process and Human Task containers and CEI. Administrative console – after configuration Administrative console – after configuration Business Integration configuration Many new applications installed Looking at the administrative console after the configuration is complete; you should see a new ‘Business Integration’ section. There you will see configuration information for the various components that make up WebSphere Process Server, including Business Process Choreographer, SCA and CEI. You will also see many applications that were installed into your server. The applications include the business process choreographer explorer which allows you to start and stop business processes and claim human tasks. You also see the business process container, human task manager applications and applications for business rules and business space. Note that these were all deployed for you automatically during the augmentation or during the post configuration task. New resources after configuration New resources after configuration New buses Many databases defined Simple configuration, very automated! You will also note that many new resources were defined for you. On the left, you see the service integration buses that were created for you and on the right you see some new data sources that are created during configuration. There are many databases needed to run WebSphere Enterprise Service Bus and WebSphere Process Server. Again, these are detailed in the z/OS DB2 configuration presentation. EJBROLE profiles for WebSphere Process Server EJBROLE profiles for WebSphere Process Server Roles Default permission Notes BPESystemAdministrator Group name entered during the installation Access to all business processes and all operations. BPESystemMonitor All authenticated users. Access to read operations. BPEAPIUser All authenticated users. Access the Business Process Choreographer APIs TaskSystemAdministrator Group name entered during the installation. Access to all human tasks. TaskSystemMonitor All authenticated users. Access to read operations. TaskAPIUser All authenticated users. Access the Human Task APIs WebClientUser All authenticated users. Access the Business Process Choreographer Explorer. WBIOperator Everyone Access to Failed Event Manager Businessspaceusers All authenticated users Access to business spaces Administrator All authenticated users Access to Business Space WebFormUsers All authenticated users Access to business space web forms BusinessRuleUsers All authenticated users Access to business rules API AnyOne Everyone Access to business rules NoOne None Access to resources that should not be accessed directly RestServicesUser All authenticated users Access to Rest services Regardless of what type of cell you configure, there are some security roles that you need to set up for various components of WebSphere Process Server. These roles are shown here on the slide. The ‘Default permission’ column shows the permissions that are defined in the applications that use the roles by default. EJBROLE profiles for Common Event Infrastructure EJBROLE profiles for Common Event Infrastructure Roles Default permission Notes eventAdministrator All authenticated users. Access to query, update, and delete events stored in the event database eventConsumer All authenticated users Access to query events stored in the event database eventUpdater All authenticated users Access to update events stored in the event database eventCreator All authenticated users Access to submit events to an emitter using synchronous EJB calls catalogAdministrator All authenticated users Access to create, update, delete, or retrieve event definitions in the event catalog. This role provides access to all methods of the EventCatalog interface and all functions of the eventcatalog.jacl script catalogReader All authenticated users Access to retrieve event definitions from the event catalog Some additional security roles are needed for the Common Event Infrastructure component. Again, the ‘Default permission’ is the permission defined with the application that uses the role when it is installed. Since you will likely be using RACF or an SAF equivalent, these security roles need to be defined as EJBROLES. The sample commands needed to reflect these permissions are shown on the next slide. Sample EJBROLE profiles commands Sample EJBROLE profiles commands To mimic ‘Group name entered during the installation’: RDEFINE EJBROLE (optionalSecurityDomain).BPESystemAdministrator UACC(NONE) PERMIT (optionalSecurityDomain).BPESystemAdministrator CLASS(EJBROLE) ID(WSCFG) ACCESS(READ) -or particular users only- PERMIT (optionalSecurityDomain).BPESystemAdministrator CLASS(EJBROLE) ID(WSADMIN) ACCESS(READ) To mimic ‘All authenticated users’: RDEFINE EJBROLE (optionalSecurityDomain).BPESystemMonitor UACC(READ) To mimic ‘Everyone’: RDEFINE EJBROLE (optionalSecurityDomain).WBIOperator UACC(READ) PERMIT (optionalSecurityDomain).WBIOperator CLASS(EJBROLE) ID(WSGUEST) ACCESS(READ) No need to match the ‘Default permission’! Chances are you will want to do your security a little different than what the ‘Default permissions’ have provided. Since you are likely using a SAF-based product, your EJBROLE definitions can reflect your own preferences for security. If you want to restrict access to a particular group or just a few users, you can define the EJBROLE with UACC of NONE and then PERMIT the users or groups that you want to allow. If you want to permit anyone who has been successfully authenticated, you can define the EJBROLE with UACC of READ. This will not allow users that have been defined with the RESTRICTED option to gain access however. By default, the ‘unauthenticated user ID’ defined during WebSphere configuration is defined with the RESTRICTED option. By default, this userid is WSGUEST and by giving the equivalent user ID READ access to the EJBROLE, you can mimic ‘Everyone’. RunAs roles for business processes RunAs roles associated with business processes .JMSAPIUser Used by the Business Flow Manager JMS API MDB in bpecontainer.ear. .EscalationUser Used by the task.ear MDB. RDEFINE EJBROLE JMSApiUser UACC(NONE) APPLDATA(xxADMIN) RDEFINE EJBROLE EscalationUser UACC(NONE) APPLDATA(xxADMIN) RunAs roles for business processes Finally, there are RunAs roles that are needed for the business process choreographer. These are used for the JMS API within the business flow manager and the human task container for escalations. In order to create a RunAs role, you need to specify a user ID on the APPLDATA keyword for the EJBROLE. An example is shown on the slide. Summary Summary WebSphere Process Server for z/OS V7 and WebSphere Enterprise Service Bus for z/OS V7 built on top of WebSphere for z/OS V7 WebSphere Process Server for z/OS V7 and WebSphere Enterprise Service Bus for z/OS V7 configuration in all environments has common tasks Stand-alone environment can be highly automated Network deployment environment has additional tasks In summary, the WebSphere Process Server or WebSphere Enterprise Service Bus products are configured on top of WebSphere Application Server V7; which is where they get most of their prerequisites from. DB2 becomes a mandatory prerequisite when configuring in a network deployment environment. The configuration of a stand-alone application server with WebSphere Process Server for z/OS or WebSphere Enterprise Service Bus for z/OS is highly automated, particularly if you use Derby as a starting point. This presentation looked at the configuration of all environments at a high-level. Each configuration has common tasks as seen here. To get a more detailed description of the various configurations, additional presentations are available. Feedback Feedback Your feedback is valuable You can help improve the quality of IBM Education Assistant content to better meet your needs by providing feedback. Did you find this module useful? Did it help you solve a problem or answer a question? Do you have suggestions for improvements? Click to send e-mail feedback: mailto:iea@us.ibm.com?subject=Feedback_about_WBPMv70_zOSWPSInstallOverview.ppt This module is also available in PDF format at: ../WBPMv70_zOSWPSInstallOverview.pdf You can help improve the quality of IBM Education Assistant content by providing feedback. Trademarks