Parallel Loads

SAP BW Load architecture is based on the criteria of InfoSource and InfoSource Types. The load runtime knows how to pool simultaneous loads with matching criteria. Stages, Links, and Jobs, that run simultaneously within the same RFC Server control, merge the loads into a single load utilizing the same SAP BW generated InfoPackage Request ID.

For example, when you run a Server PUSH job with multiple, identically configured input links, each link executes in parallel. When the first link (A) reaches a specific spot in the configuration process, it locks a semaphore so that the other links (B) cannot continue until the first is through. At this time, the A link either starts a Process Chain, or schedules an InfoPackage. Once started, the A link frees the semaphore and waits for BW to contact the appropriate RFC Server with a Load Request ID. When the semaphore is released by the A link, the B links recognize that either a Process Chain or InfoPackage has already been scheduled and waits for the Load Request ID, as link A is doing.

When SAP BW returns to the RFC Server with a Load Request ID, all links (A & B) begin their load process utilizing the same Request ID, thus processing a single load in parallel. Coordination of package numbers and total row counts between links, stages, and jobs, is done via semaphores and intermediary files allowing this parallelism.

For an SAP BW Parallel Load to work, the runtime processes:

• must exist on the same host server. This is required as semaphores cannot be shared between servers and they are vital to coordinating packets to BW.
• must all use a common RFC Server or Source System. Multiple links configured the same except for the Source System will not be treated as a single load, they will work individually, at a slower performance measure due to semaphore locking when not really necessary.