Error encountered during MAIN_NEWBAS/PARRUN_BUSINESS_USER phase during conversion

Hi Folks,

During an In-Place conversion from ECC to S/4HANA on RISE using Software Update Manager (SUM), I encountered an error in the Postprocessing phase(MAIN_NEWBAS/PARRUN_BUSINESS_USER) that completely stopped the conversion. It is due to the RFC communication failures that halted the process during parallel execution phases.

The error message was:

Error during parallel execution of processes!
RFC system error during parallel execution of processes
Shortdump due to RFC communication failure

Problem Description-:

The SUM process failed with an RFC communication error. The logs (SAPupConsole.log) indicated:

RFC system error: [RFC_COMMUNICATION_FAILURE]Shortdump in program SAPLARQ_HQVTask: PDA:DB2:MAIN_NEWBASPARUPL_BUSINESS_USER

Moreover, the internal RFC destination (v_SID_00) for the application server is responding, but the fully qualified hostname (v***.s*p.cpr.cp**) redirects through an intermediate host/proxy. This redirection causes the parallelization framework’s resource collector to fail when attempting to reach the internal RFC destination directly. The issue was caused by FQDN (Fully Qualified Domain Name) resolution behavior and cannot be modified via SM59.

SUM stopped due to RFC communication failure

Resolution

Since RFC cannot be modified via SM59., I applied a schema-level fix using hdbsql to change the destination of RFC from fully qualified name to * to allow dynamic resolution.

Steps Taken

Connect to HANA Database

hdbsql -i <instance_number> -u <user> -p <password>

Locate RFC Destinations SUM stores RFC destinations in the table:
SAPUPRC.RFCDESTBackup the Table Always take a backup before making changes:
SQL
CREATE TABLE SAPUPRC.RFCDEST_BKP AS SELECT * FROM SAPUPRC.RFCDEST;Update RFCOPTIONS Replace FQDN with * to allow dynamic resolution:
SQL
UPDATE SAPUPRC.RFCDEST
SET RFCOPTIONS = REPLACE(RFCOPTIONS, ‘fqdn-hostname’, ‘*’)
WHERE RFCDEST = ‘vh*****_SID_00’;

update SCHEMA_USER.RFCDES set RFCOPTIONS=replace(RFCOPTIONS, ‘d=2,7=60D9,7=60D9,’, ‘H=*,d=2,7=60D9,7=60D9,’) where RFCDEST = ‘vh*****i_SID_00’

I have tried to explain further with diagram -:

The diagram illustrates three scenarios related to RFC resolution during an SAP SUM upgrade/conversion:

Top Section: FQDN Redirection Causing RFC Failure

SUM → RFC Destination → FQDN → Proxy → App ServerHere, the RFC destination uses a Fully Qualified Domain Name (FQDN).The FQDN resolves through an intermediate proxy, which SUM’s parallelization framework does not handle well.This redirection leads to RFC communication failure during parallel processing.

Middle Section: Dynamic Resolution with *

SUM → RFC Destination → * → App ServerWhen the RFC destination is changed to *, SUM uses dynamic resolution via the message server.This bypasses the proxy and connects directly to the application server.Result: Parallelization works successfully.

Bottom Section: Ideal Direct RFC Communication

SUM → RFC Destination → App ServerRepresents the ideal scenario where RFC resolves directly to the application server without any proxy or intermediate hop.

Validation

Repeat the SUM phase at a point where it stopped.Verified successful RFC communication.

Key Learnings

FQDN issues can break parallel processing.Schema-level changes can resolve RFC failures when standard options are unavailable.

Conclusion

This workaround helped me resume the conversion successfully. If you face similar RFC issues during upgrades/conversion, this approach can save time and effort.

Hi Folks, During an In-Place conversion from ECC to S/4HANA on RISE using Software Update Manager (SUM), I encountered an error in the Postprocessing phase(MAIN_NEWBAS/PARRUN_BUSINESS_USER) that completely stopped the conversion. It is due to the RFC communication failures that halted the process during parallel execution phases.The error message was:Error during parallel execution of processes!RFC system error during parallel execution of processesShortdump due to RFC communication failure Problem Description-:The SUM process failed with an RFC communication error. The logs (SAPupConsole.log) indicated:RFC system error: [RFC_COMMUNICATION_FAILURE]Shortdump in program SAPLARQ_HQVTask: PDA:DB2:MAIN_NEWBASPARUPL_BUSINESS_USERMoreover, the internal RFC destination (v_SID_00) for the application server is responding, but the fully qualified hostname (v***.s*p.cpr.cp**) redirects through an intermediate host/proxy. This redirection causes the parallelization framework’s resource collector to fail when attempting to reach the internal RFC destination directly. The issue was caused by FQDN (Fully Qualified Domain Name) resolution behavior and cannot be modified via SM59. SUM stopped due to RFC communication failure ResolutionSince RFC cannot be modified via SM59., I applied a schema-level fix using hdbsql to change the destination of RFC from fully qualified name to * to allow dynamic resolution. Steps TakenConnect to HANA Databasehdbsql -i <instance_number> -u <user> -p <password> Locate RFC Destinations SUM stores RFC destinations in the table:SAPUPRC.RFCDESTBackup the Table Always take a backup before making changes:SQLCREATE TABLE SAPUPRC.RFCDEST_BKP AS SELECT * FROM SAPUPRC.RFCDEST;Update RFCOPTIONS Replace FQDN with * to allow dynamic resolution:SQLUPDATE SAPUPRC.RFCDESTSET RFCOPTIONS = REPLACE(RFCOPTIONS, ‘fqdn-hostname’, ‘*’)WHERE RFCDEST = ‘vh*****_SID_00’; OR update SCHEMA_USER.RFCDES set RFCOPTIONS=replace(RFCOPTIONS, ‘d=2,7=60D9,7=60D9,’, ‘H=*,d=2,7=60D9,7=60D9,’) where RFCDEST = ‘vh*****i_SID_00’ I have tried to explain further with diagram -: The diagram illustrates three scenarios related to RFC resolution during an SAP SUM upgrade/conversion: Top Section: FQDN Redirection Causing RFC FailureSUM → RFC Destination → FQDN → Proxy → App ServerHere, the RFC destination uses a Fully Qualified Domain Name (FQDN).The FQDN resolves through an intermediate proxy, which SUM’s parallelization framework does not handle well.This redirection leads to RFC communication failure during parallel processing. Middle Section: Dynamic Resolution with *SUM → RFC Destination → * → App ServerWhen the RFC destination is changed to *, SUM uses dynamic resolution via the message server.This bypasses the proxy and connects directly to the application server.Result: Parallelization works successfully. Bottom Section: Ideal Direct RFC CommunicationSUM → RFC Destination → App ServerRepresents the ideal scenario where RFC resolves directly to the application server without any proxy or intermediate hop. ValidationRepeat the SUM phase at a point where it stopped.Verified successful RFC communication. Key LearningsFQDN issues can break parallel processing.Schema-level changes can resolve RFC failures when standard options are unavailable. ConclusionThis workaround helped me resume the conversion successfully. If you face similar RFC issues during upgrades/conversion, this approach can save time and effort. Read More Technology Blog Posts by SAP articles

#SAP

#SAPTechnologyblog