Hosted by Chandra Wobschall and Paul Houtkooper

Hey there, JDE Connection listeners! We’re back with the second part of our deep dive into Virtual Batch Queues (VBQs) with John Holder from Oracle. If you missed Part I, go check out Episode 51, where we introduced VBQs and covered how they originated and some of the architectural changes that occurred along the way that laid the groundwork.

Key Enhancements and Architecture Updates

In this episode, John walked us through some critical architectural changes required for VBQ, particularly the Files to Database Mode in the P9617 application. Here’s why this matters:

• Faster Performance: When files are stored in the database instead of the file system, retrieving outputs is significantly faster.
• High Availability: Even if a server is down, users can still access output files because they’re pulled directly from the database.
• Optimized Resource Usage: Instead of sending output files through multiple layers (Enterprise Server → JAS Server → Browser), the system now fetches files directly from the database, reducing processing overhead.
• Configurable Limits: By default, JD Edwards limits in-memory retrieval of output files to 2MB, but this setting can be adjusted based on system needs.

Future-Proofing with VBQ

One of the most insightful moments of the episode was when John emphasized setting up new servers with VBQ as the default configuration, even if an organization is starting with a single server. Doing so ensures that as workloads grow, new servers can be seamlessly added to the VBQ environment without requiring manual reconfiguration.

For companies that rely on high-volume batch processing, this setup provides flexibility to dynamically scale up or down as needed, whether for month-end closing or handling peak workloads.

Managing Single-Threaded Queues in VBQ

A big question many users have is how single-threaded queues work in a VBQ environment. John explained that:

• A single-threaded queue in VBQ means one job is allowed across all servers, not per server.
• The queue kernel uses database locking to ensure that no more than one job runs at a time.
• JD Edwards has improved the scheduling algorithm to check job status and prevent premature execution of queued jobs.

These improvements ensure consistent, reliable job execution, even when multiple servers are available.

Advanced Configurations and Troubleshooting

We also explored some advanced use cases for VBQs, including:

• Locking jobs to a specific server for integrations that require unique third-party licenses.
• Overriding default job queues based on user role or department, ensuring that financials and manufacturing teams don’t compete for the same processing power.
• Improved logging and troubleshooting tools, including the ability to track who terminated a job and when—a long-requested enhancement.

What’s Next?

As Paul pointed out, this episode just scratches the surface of VBQ troubleshooting and best practices. We’ll be bringing John back for another round to discuss gotchas, implementation challenges, and more real-world scenarios.

Join the Conversation

Are you considering Virtual Batch Queues for your JD Edwards environment? Have questions about how to implement it? Let us know at thejdeconnection@questoraclecommunity.org!

Until next time, let’s keep learning, sharing, and—most importantly—laughing together. Toodles!

Missed an episode? Check out the full episode list! Also, be sure to subscribe on your favorite podcast provider, or select a provider below!

Learn More

Quest Oracle Community is where you learn. Ask questions, find answers, swap stories and connect to other JD Edwards customers and product experts in the JD Edwards Community, where you can also check out what’s happening in the Business Analyst SIG.