Skip to Content


Oct 02, 2017 at 06:46 PM


avatar image

We are attempting to copy files from our QA system to PRD. How do we resolve the RFC error?



selection.png (104.3 kB)
rfc-error.png (12.9 kB)
10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

3 Answers

Vadim Kalinin Oct 02, 2017 at 06:54 PM

Sorry, but please explain, what are you doing!

ZUJF_COPY_FILES_TO_TARGET_SYS - looks like some custom development!

Show 5 Share
10 |10000 characters needed characters left characters exceeded

Yes - i can't upload the sap document. I saved the file to a file share. Please copy-paste the link below into ie to see sap documentation. Let me know if it fails. To Promote Reports and Input Schedules Through Your System Landscape.pdf


First - all links are broken! Why not to check yourself?

Second - what do you mean by sap document????

sap copy tool pdf file step4.png step5.png step6.png final-step-7.png

you have to copy the whole string from http through .pdf. anyway... the ZUJF is an SAP file copy tool. I have used it with incredible results in the past but that was two years ago. I now need to use it to copy files than promote reports through transport or save them one by one or use the file utility to download to a local drive and save up to a different environment. This nifty tool allowed me to choose my files, choose my target and boom - copy!! now i am getting the RFC error - hence my question. I love this tool and it has saved me hours and hours of time.

SAP BusinessObjects Planning and Consolidation 7.5 , version for NetWeaver

Business Scenario

Within this scenario, we will explore how to use a custom program to copy SAP BusinessObjects
Planning and Consolidation,version for Netweaver (BPC) file service files from a source system to any
number of target systems


In this How-To Guide, you will learn how to copy files from the BPC File Service to other BPC systems
in your landscape. Currently, transporting of files at a granular level within BPC using the existing
BPC transports framework is not supported. This guide is an attempt to satisfy the requirement for
copying files, such as “Reports” and “Input Schedules” to other BPC systems, without the user having
to do manual steps.

This guide comes with a custom program which reads BPC file service records from the database,
compiles a list of RFC destinations, and presents this information to the end user. The user can then
choose specific files to be copied, as well as the target systems which the files are to be copied to.
Before using this program, make sure that any/all RFC destinations for target systems have been
configured correctly, and are working properly in transaction SM59.
Currently, only directories for “Reports” and “Input Schedules” are supported by this custom program.
This means, only files from the following directories will be available to copy to target systems.

Step by step

This How-To guide contains transport request files, K901105.PMR and R901105.PMR (please see
section 5 „Appendix“). This transport request contains all the NetWeaver objects that are required to
complete this How-To Guide. In order for this process to work correctly, the
ZUJF_COPY_FILES_TO_TARGET_SYS function module must exist on every target system in which
you want to copy files to. After deploying this transport request to your development system, you must
be sure to promote this function module throughout your landscape.
 ZUJF_COPY_step1.pngFILES_TO_TARGET_SYS BPC: Copy Files to Target Systems
Function Groups
 ZBPC_CD BPC: Custom Development Function Group
Function Modules
 ZUJF_COPY_FILES_TO_TARGET_SYS BPC: Copy Files to Target Systems via RFC
As the process of importing a transport request is not covered here, it is suggested that you seek
assistance from your basis administrator in order to have this transport request imported into your

step1.png (96.2 kB)
step3.png (117.0 kB)
step4.png (206.0 kB)
step5.png (77.5 kB)
step6.png (90.2 kB)
final-step-7.png (66.6 kB)

"ZUJF is an SAP file copy tool" - it's not an official SAP tool, it's some code that you can use on your own risk. From this document:

"Any software coding and/or code lines / strings (“Code”) included in this documentation are only examples and are not intended to be used in a productive system environment."

Perform debugging yourself.


I managed to recover the link to pdf file.

This document is about unofficial and unsupported development (on your own risk). Ask you ABAP developer to debug execution of this program. May be you RFC setup is done incorrectly. May be you have incorrect user rights.

P.S. I am even unable to look on ABAP code of this program without installing it on my system (and I don't want to do it).

Deborah Silverman Oct 02, 2017 at 07:56 PM

We have DEV. TRAINING, QA, UAT, PRD environments. To copy reports and input schedules through this chain is very time consuming. We do not use transports for BPC reports and input schedules. Considering SAP high tech I am amazed there isn't a tool already in place for such efficiencies. To make a change on a report starting in DEV and 'promote' it - with is actually copy it - is very time consuming. We have to log into each environment and overwrite the file one by one. I am open for suggestions. ??

Show 1 Share
10 |10000 characters needed characters left characters exceeded

"We do not use transports for BPC reports and input schedules." - why?

If you want to use unofficial tool you need to have a person able to debug it. It's the same story with all unofficial tools.

Nothing is perfect :)

Deborah Silverman Oct 02, 2017 at 08:29 PM

The reason is there are different teams managing different content. To create a transport for one or few reports is counterproductive to efficiencies. The number of transports to support ongoing changes will become untenable. In BPC we do one transport for go-live for the entire environment. From this point on reports and input schedules are copied not transported. We are not a small SAP shop. With over 500 users nationwide, with which we have more than 50 developers for reporting objects, being subject to transports for reporting will kill productivity and generate distaste for the tool/project. We sell productivity and efficiency. If a change is made to a report or a new report is created - non-admin people (usually a small group) with admin access should be able to simply grab the files and copy them top update DEV to UAT to TRAINING to QA to PRD servers than log into one by one for each file. we shouldn't need to tie down Admins who are far removed from BPC business development (reports) to copy a file.

Show 8 Share
10 |10000 characters needed characters left characters exceeded

Do you test and develop reports on different server? You can have a copy of production environment on the same production server to test reports. Then you can copy files within the same server.


But I am still unable to understand - do you have ABAP specialist?


We do have people who can do ABAP. Access to these resources are not possible at this time - normally we troubleshoot things like this far sooner than pre-go-live activities. If the solution to the problem is to grab an ABAPer to debug the code (to understand the RFC error) it will need to wait. I was putting the question out there to see if this was something the admin could remediate, such as configuration/parameter ... the code has worked for me for many years with multiple environments until now without ABAP code trouble-shooting.

So, that said - my comment earlier was soliciting ideas to copy reports from server to server - efficiently - without the use of a transport. 1) UJFS, 2) ZUJF 3) EPM Add-in saving files locally and then saving them to respective servers. With UJFS I can zip the entire reporting directory and upload to each server. ZUJF is the custom copy tool, where if working I just choose my suource and my destination and, option 3, is time consuming.


The issue is that this code is VERY old, written for BPC 7.0 originally (supporting 7.5). Currently I do not have 7.5 test system available to check it.

By the way, are you unable to copy files only to BPQCLNT500 or to all destinations?


I agree - the code is very old, and with syntax changes it's probably at the end of it's life cycle (sad). The code doesn't work to copy to any destination. I have been trying to just copy one file to any place willing to take it! I am a 'former' ABAPer - the last time I worked on logic was 10 years ago ... in my spare time I'll crack it open (spare time - right). This kind of utility is a time-saver for people. I t was useful, productivity was increased without having to rely on other people or jump through multiple environments to bring a file through to PRD. the only people who could trigger the code was someone with access to SAP GUI, which itself was a control and it worked well. BPC reports are changed far too often to force transports as a requirement. We use transports for everything else. Granted access to all environments (specific users) there is no reason why this tool shouldn't be a part of SAP deliverable. Disappointed.


"why this tool shouldn't be a part of SAP deliverable" - there are a lot of nice to have things in BPC not implemented for years :) Now all efforts are concentrated on BPC embedded.

If none of destinations are working then it can be code compatibility issue or user rights issue (request SAP_ALL to test). But it's easy to debug it in SE38. The program is not huge :) You can even post the code here...


Bringing objects from DEV to PRD (and all the alt environments in between) shouldn't be rocket science. The focus on productivity tools from the USER perspective. The math is simple - the simple copy tool can save one user an hour to copy files - worldwide and tens of thousands of users? I think that warrants the enhancement. To have people complain the task is time-consuming isn't good for SAP and isn't good for customer's bottom line. I don't see this tool as an enhancement - from my perspective this is essential. I'll crack that thing open - but I don't think using it from DEV through to PRD would ever be an option unless it is from SAP ....but if we can get the files 3/4of the way it will be worth it.


Different companies use different workflows! I remember some huge company that don't use UJFS templates storage at all :)

In general if you need a productivity tool - do it yourself and maintain it yourself! Not everything can be available from the box. Do you have locally developed badi's in your system? Same approach.

P.S. I am not working for SAP