B Creating and Configuring Multiple Transaction Servers per Environment or User/Role

The default configuration for the Transaction Server defines the F907* tables (event tables) to reside in one datasource. These tables are included in the System datasource database (for example, SY812 or SY900). Using this default configuration, only a single Transaction Server may be configured to monitor the F907* tables.

This appendix provides instructions to set up and configure multiple Transaction Servers so that transactions can be separated by one or more of these criteria:

• Environment

• Role/User

This process allows you to:

• Separate transaction events by environment so that two different transaction servers can service the events

• Use OCM mappings to point to the different environments

This appendix describes these tasks:

• Section B.1, "Creating and Configuring Multiple Transaction Servers per Environment"

• Section B.2, "Creating and Configuring Multiple Transaction Servers per Role/User"

B.1 Creating and Configuring Multiple Transaction Servers per Environment

These general guidelines apply:

• Production Environments

  The F907* tables should remain in the System database as defined by the standard setup and configuration. Since the transaction server is designed to work with only one set of F907* tables, the normal procedure is to configure the transaction server with these system tables.

• Test and Dev Environments

  In order to separate Test and Dev environment transactions from Production, you can copy the F907* tables into the business data database and change the OCM mappings accordingly. A second transaction server is necessary in order to access these copied tables because, by design, each Transaction Server can only work with only one set of F907* tables.

• Multiple Transaction Servers

  In order to support the separation of the F907* tables per environment, you must install an additional Transaction Server per environment or environment combination. For example, if you want to isolate your Production environment and then combine your Test and Dev environments, you would need a total of two Transaction Servers. If you further wanted to separate your Test and Dev environments, you would need a total of three Transaction Servers.

Do not start any added Transaction Servers until you complete the procedure in this appendix.

To create and configure the Transaction Server per environment:

1. With the exception of the tables listed in the Exceptions below, copy all remaining F907* tables from the System database to the business data database.

   Exceptions

   The following tables are initially cached on JD Edwards EnterpriseOne service startup and contain the necessary information needed for all environments and subscribers. Therefore, these tables and their OCM mappings should remain in the System datasource:

   • F90701

   • F907011

   • F90705

2. Use OCM to remap the F907* tables copied in Step 1 to the new business data database for both the system and the server map.

   For example, the completed mappings might look like these:

   JPY900 F90701  TBLE  System - 900 *PUBLIC AV 
   JPY900 F907011 TBLE  System - 900 *PUBLIC AV 
   JPY900 F907012 TBLE  System - 900 *PUBLIC AV 
   JPY900 F90703  TBLE  Business Data - CRP *PUBLIC AV 
   JPY900 F90704  TBLE  Business Data - CRP *PUBLIC AV 
   JPY900 F90705  TBLE  System - 900 *PUBLIC AV 
   JPY900 F90706  TBLE  Business Data - CRP *PUBLIC AV 
   JPY900 F90707  TBLE  Business Data - CRP *PUBLIC AV 
   JPY900 F907071 TBLE  Business Data - CRP *PUBLIC AV 
   JPY900 F907072 TBLE  Business Data - CRP *PUBLIC AV 
   JPY900 F90708  TBLE  Business Data - CRP *PUBLIC AV
   JPY900 F90710  TBLE  Business Data - CRP *PUBLIC AV 
   JPY900 F90711  TBLE  Business Data - CRP *PUBLIC AV 
   JPY900 F90712  TBLE  Business Data - CRP *PUBLIC AV 
   JPY900 F90715  TBLE  Business Data - CRP *PUBLIC AV 
   JPY900 F90720  TBLE  Business Data - CRP *PUBLIC AV 
   JPY900 F90730  TBLE  Business Data - CRP *PUBLIC AV 
   

3. Activate the RT* event for added environment (for example, JPY900) in P90701 by:

   • Taking the Form exit to Event Activation

   • Doing an Add to add the new Event per environment

   • Using the Row exit to change the status to Active

4. Refresh the JD Edwards EnterpriseOne server cache by restarting the EnterpriseOne services.

5. Add subscriber information for the added environment (for example, JPY900).

6. Refresh the Transaction Server cache by restarting the transaction server.

7. Trigger the event.

8. Verify the event is recorded in the F90710 Business Data Source table.

9. From a JD Edwards EnterpriseOne client machine, use this command to run the Table Trigger script for F90710 in the business data for the added environment (for example, PY Business Data):

   <home>\system\bin32\dbtemplates.exe -create

   where <home> is the installation directory of the JD Edwards EnterpriseOne Administration client that is named according to the JD Edwards EnterpriseOne release. For example, E812 or E900.

10. Verify the F986112 table is populated and the new event in F90710 has the status 3 instead of 2.

B.2 Creating and Configuring Multiple Transaction Servers per Role/User

This section describes a configuration where multiple Real Time Events can be processed by multiple Transaction Server instances within the same JD Edwards EnterpriseOne environment. You can process events by Role/User to enable specific users to have their events processed by a specific Transaction Server. This setup is similar to that in the previous section, Section B.1, "Creating and Configuring Multiple Transaction Servers per Environment". Instead of separating the events by environment you are separating the Real Time Event messages by Role/User.

Multiple Transaction Servers

In order to support the separation of the F907* tables per Role/User, you must install an additional Transaction Server per User or Role combination. For example, you have set up a role for processing Sales Orders and another role for processing all other Real Time Events. In this case, you would need an additional Transaction Server for each role addition.

To configure the system to route Real Time Events to specific Transaction Servers based on the JD Edwards EnterpriseOne Role/User user that is generating the event:

1. From JD Edwards EnterpriseOne, create a new Role which will include a group of users that will initiate the Real Time Event messages.

2. Create these tables in the same environment datasource (Business Data - PROD) or create a custom Data Source (for example, TS2 / PD900):

   • F90710 - Event table

   • F90730 - Unique sequence table

3. Copy these tables from the System datasource to the same environment datasource you used in Step 2:

   • F90706 - Event Subscriber

   • F90707 - Event Subscription

   • F907071 - Subscribed Events

   • F907072 - Subscribed Environments

   • F90708 - Event Sequence

   These tables contain the subscriber information and whether they are active or not. It is important to note that when you copy these tables, whenever you want to make changes to the subscriber information you must ensure you are logged in as the appropriate user. This is required to ensure you are making changes to the correct table. If you do not copy these tables, you will continue to see errors in the Transaction Server log where events cannot be delivered to all the subscribers, although this does not affect the delivery of the events to the correct queue.

4. Create new OCM mappings for all the tables listed in Steps 2 and 3 for the new Role (for example, role associated with the PD900 environment and the copied F90710 table and the role associated with the PD900 environment and the F90730 table) to point to Business Data - PROD. You must make mappings for both SYSTEM and Server Map.

5. On a JD Edwards EnterpriseOne client machine, run the program to create the table trigger on the new F90710 table. From a command prompt, navigate to this directory:

   e900\system\bin32\

6. From the above directory, run this command:

   dbtemplates.exe -create

   When prompted ensure you log in as the new user (assigned to your new role) so that the program uses the new OCM mappings to locate the correct table in which to create the new trigger.

   Henceforth when logging in as a user defined by this role, a generated Real Time Event sends the message into the appropriate F90710 table and updates the F90730 table.

7. Install a new Transaction server that will be used to process the events for each new Role/User.

8. Configure the newly installed Transaction Server with one of the users in the new Role as the bootstrap user.

9. Process a transaction that triggers an event for the new Role.

10. Start the newly installed Transaction Server and check the queue to make sure the event was delivered to the new Transaction Server.

11. Verify the previous configuration still functions as expected by logging in as any user not belonging to the new Role and generate an Event and see that the message goes into the F90710 (System - 900) and is delivered to the original Transaction Server.