Before You Begin
This 20-minute tutorial shows you how to verify that a system has been setup correctly for running as a virtual batch host with a virtual batch queueing environment.
Background
Virtual batch queues will enable EnterpriseOne to meet cloud elasticity needs for batch processing. By using a virtual host name, you can tie multiple EnterpriseOne batch processing servers to that virtual host name to facilitate simple scaling of EnterpriseOne batch processing. For example, a job submitted to QBATCH on one enterprise server could be processed by any physical node on that virtual host.
What Do You Need?
You must have completed the following tasks:
- All servers must be on Tools Release 9.2.5 or higher and the latest Tools ESU must have been applied.
- All servers used in a batch cloud must be on the same operating system, database type, and on the same port.
- All servers used in a batch cloud must have the File in Database enabled.
- All servers used in a batch cloud must share the same server map, SY or SVM, and packages.
- Required print queues must be set up identically.
- Security servers must have been federated to accept the same tokens.
- Unused columns with obsolete data must be cleaned from F986110.
Verifying
that the UBE Output to Database Option is Enabled
- Navigate to the P98617 program.
- Click Search to populate data.
Note: The Default Output Location column must be set to either database (recommended) or filesystem+database (recommended not as a default value, but as an override value for specific reports if needed).

Verifying
Virtual Hosts Configuration
- Navigate to the Work With Locations and Machines Web program (P9654W).
- Click Search to select the data you will use to define the location.
- In the lower section of the powerform, select the Virtual Host tab.

Note that the Virtual Host section shows that the virtual host is configured with the machine name vbqcloud and is on port 6017. It is also host type 35, which is Linux.
The Machine Name section show that two the enterprise servers jdeent1-2 and jdeent1-3 have been added as participants of the virtual host.
Verifying
Database Data Sources
- Navigate to System Administration Tools (GH9011), Database Data Sources.
- Verify that the Database Data source is set as System - 920 for one of the servers. This is used by the JAS and FAT clients.
- Reconfirm the same in the jdeent1-2 - 920 Svr Map data source (all the servers should be sharing the same database data source tables, and therefore you should see identical data when configured correctly).
- Select the row with System – 920 and click OK.
- Click Search and then enter SVM920 in the Object Owner field to see all the database mapping records used by the JAS and development clients.


You have now seen that the actual and virtual hosts have valid database data source records in the client and the server database mapping tables.
Verifying
Logical Data Sources
- Navigate to GH9011, Logical Data Sources.
In this application, you will confirm the Logical Data sources in the System – 920 data source, which is used by the JAS and development clients and you will reconfirm in the jdeent1-2 - 920 Svr Map data source (all the servers should be sharing the same server map tables, and therefore you should see identical data when configured correctly).
- Select the row with System – 920 and click OK.
- Click the Search option to view the list of available
virtual hosts and their corresponding machines.
Logical Data Sources - Work With Data Sources Form - Repeat steps 2 and 3, selecting “jdeent1-2 - 920 Svr Map” in step 3\2, verifying the server map records used by the enterprise servers. (“jdeent1-3 - Svr Map” and “vbqcloud - 920 Svr Map” should show data from the same table).

Note that the actual servers jdeent1-2 and jdeent1-3 have their regular logical map sources. The virtual host vbqcloud also has a logical map data source.
You have now verified that the actual and virtual hosts have valid logical data source records in the client and the server logical data source tables.
Verifying
OCM Configuration for UBEs on Virtual Host
In this task, you will learn how to verify that your OCM mappings are configured correctly for clients and servers for UBE submission when using a virtual host.
- Fast path to navigate to OCM, then select System - 920 to examine the client OCM.
- Now set selection in the header of the form before searching
for the UBE using the following values:
Environment:
JPD920 Object Name:
DEFAULT Object Type: UBE
- Click Search.
- Use the Fast Path to navigate to OCM, then select jdeent1-2 - 920 to examine the enterprise server OCM.
- Use the header filters to filter records with the following
values:
Environment:
JPD920 Object Name:
DEFAULT Object Type: UBE
- Click Search.


Note that the AV (active) mapping in the Object Status column is of the virtual host VBQCLOUD.


Note that the AV (active) mapping in the Object Status column is of the virtual host VBQCLOUD.
You have now confirmed that the default UBE mapping for the client and the server will be the virtual host for the JPD920 environment.
Verifying
Default Queue Configuration
In this exercise, you will learn how to verify that a default queue is configured for a virtual host.
- Navigate to GH9013, Batch Processing Setup, Job Queues.
- On the Job Queues – Work With Job Queues form, select Virtual Host Queues from the Form exit to see the queues configured for the virtual host.
- 3. If no records are displayed, click Search.
The top half of the powerform shows virtual host default queues.

You can see in the powerform that QBATCH is the default queue for the virtual host vbqcloud. You can also see, in the lower section of the powerform, the queues of all the hosts that are part of the virtual batch host, and if those queues are active or not.

The search will not yield any result if default queues are not defined for any virtual host .
You have now confirmed that a default queue is available for the virtual batch host.
Verifying
Configuration of Virtual Host Enterprise Servers
In this exercise, you will learn how to submit a report to a non-default job queue by overriding the job queue when a report is submitted. This practice will be used throughout the rest of this workshop for all jobs submitted.
- Navigate to the Work With Virtual Host program (P9655).

This application shows that both jdeent1-2 and jdeent1-3 are up and actively scheduling jobs.
When one of these servers has its EnterpriseOne services stopped in Server Manager Console, the Queue Kernel Status column for the server will be set to Inactive, while the Allow Batch Processing field will remain enabled, that is, the field will display a green circle. When services are restarted, the queue kernel will resume scheduling jobs.
At any time, if you click on the Allow Batch Processing button again, this first column will be set to green. If the server is up, the queue kernel will immediately start scheduling any available jobs on the virtual batch host that are available.
You have now confirmed that the enterprise servers are functional and available for scheduling jobs.
Additional
Configuration Notes: Server Manager
In this exercise, you will configure hosts that participate in a virtual batch cloud to make their needed kernel types operational when the server is brought up, to be ready to process jobs. You must configure the hosts to automatically start the kernels, especially the Queue and XMLPublisher kernels, so that they can poll for work and process jobs without receiving messages. The kernels can only perform these tasks if they are autostarted.
- Using your access to Server Manager, ensure to:
- Autostart one queue kernel per VBQ host
- Autostart at least one UBE kernel per VBQ host
- Autostart at least one XMLPublisher kernel per VBQ host
- In the Server Manager, after clicking on the enterprise server, set the Configuration tab to Basic.
- For each server in the Virtual Batch host, confirm that one queue kernel is set to be autostarted.
- For each server in the Virtual Batch host, confirm that one UBE kernel is set to be autostarted.
- If you use embedded BI Publisher, for each server in the Virtual Batch host, confirm that at least one XML Publisher kernel is to be autostarted.


