BSI TaxFactory Cyclic J and the New RFC Wrapper
No doubt by now you’ve seen some announcements regarding the end of support for the “classic” RFC Library and how this impacts BSI TaxFactory. As a BSI customer, you probably received an email from BSI Support about this. Either way, if you haven’t already, I encourage you to have a look at Note 2219445 (BSI TaxFactory wrapper code redesign – old RFC Library going out of maintenance).
You’ve probably also seen some discussions around the subject of just how to obtain and install or upgrade this new RFC Library, and if you’re like me, perhaps even been a little confused as to just what you need to do.
Take heart! It’s not that difficult. At the core of it, this is just another Cyclic Update, with only a couple easy extra steps. The basic process for applying a Cyclic Update has not changed from the procedure I described in BSI TaxFactory 10 Cyclic Update. Here I’ll just go over the few extra steps.
Remember the deadline for maintaining support: 31 March 2016. So plan on getting this through your DEV and QAS track and into production before that date.
Prerequisite SAP Note
Before you update TaxFactory to Cyclic J, it is necessary to apply Note 2242290 (BSI: Changes for Cyclic J of BSI TaxFactory 10.0) to your ECC system. This is due to some changes in the structure of the data that TaxFactory sends back to ECC once this Cyclic is applied. Note, it’s perfectly fine to apply this Note at any time before you apply the Cyclic, as it is backwards-compatible with earlier Cyclics.
Apply the Cyclic
Now apply Cyclic J to your TaxFactory system using the same standard procedure outlined in BSI TaxFactory 10 Cyclic Update. Only a few items are different from the update to Cyclic F described in that blog.
TF10 Client
During the TF10j client update, you may notice the message:
Querying Tomcat7-PRD failed (0). Waiting…
Do not be alarmed! This is normal. What is happening here is that the installer is stopping the Tomcat service and is querying to determine when it has stopped before going on to delete files. The query “fails” until it detects a successful stop, which may take a moment or two. Once the service stops, the query succeeds and the installer proceeds. Otherwise, this part is the same as previous TF10 client cyclic updates.
TF10 Server
Again, this process is mostly the same, but here there is one additional step to take. Also, you might find it necessary to shutdown the SAP Gateway (via SAPMMC) before copying the new executables into the working folder, as the gateway process may hold a lock on the tf10server.exe file.
You will notice two new files that didn’t exist in prior cyclics: tf10server_new.exe and tf10serverdebug_new.exe. These are the versions that use the new NetWeaver RFC Library. By default, BSI is providing them as optional files, while the default files still use the Classic RFC Library — the one that is being deprecated.
However, we don’t want to use the old library, we want the new one, so the procedure is to rename the files:
- Rename tf10server.exe and tf10serverdebug.exe to tf10server_old.exe and tf10serverdebug_old.exe, respectively.
- Rename tf10server_new.exe and tf10serverdebug_new.exe to tf10server.exe and tf10serverdebug.exe, respectively.
Cyclic Data File
Don’t forget, to launch the new client in your browser, you must edit your favorite or shortcut URL. The new URL will look something like this:
http://<TFhost>.<domain>.com:8091/eTF10j/PRD
Notice the part in bold, where the letter indicator of the Cyclic is included. That’s the part you must change.
Load the cyclic data file as you would normally. You will notice a new feature in the client for monitoring the manual load status, which is a nice addition.
New RFC Library
Here comes the fun part. At this point, nothing works. Well, ok the TF client works, but you don’t have any working communication between ECC and TaxFactory, and not just because you haven’t restarted your Gateway yet. If you’re like me, you probably assumed that your fancy 7.42 Gateway would have the new RFC functions embedded. Nope. Then you might assume that you can use the 7.42 version of sapnwrfc.dll, etc. Maybe, but I had a devil of a time trying to make that work.
You might assume the readme.txt that came with the new Cyclic J server executables would have detailed installation instructions. Not really. It just says to put the new libraries in the directory where tf10server.exe is running, but doesn’t say which libraries. Note 1025361 (Installation, Support and Availability of the SAP NetWeaver RFC Library), which everything points to, does give some hints, but it isn’t very explicit in its instructions. Indeed, as it kept pointing to a 7.20 version of the RFC Library, not to mention a full SDK, and it seemed that a 7.42 version was available, I figured the Note must be out of date.
I spent more than a day or two trying to make it work with a 7.42 version of sapnwrfc.dll, fruitlessly.
There might indeed be a way to make the 7.42 dlls work, but for our purposes here you do in fact require the 7.20 version mentioned in the Note.
Download the RFC Library
To obtain the correct library, open up Support Packages and Patches | SAP Support Portal, and under Software Downloads… Support Packages and Patches select Browse Download Catalog. Navigate to Additional Components… SAP NW RFC SDK… SAP NW RFC SDK 7.20… <server OS platform, e.g. “Windows on x64 64bit”> and select the latest patch level of the NetWeaver RFC Library (at this writing, it is patch 38 published on 11/13/2015). Download the file and unpack it with SAPCAR as you normally would.
Install the RFC Library
The installation is simple. You simply copy the appropriate files to the appropriate folder. To find the files you need, drill into the folder you unpacked to \nwrfcsdk\lib and copy all the files you find there.
Paste these copied files into your working TaxFactory server folder (e.g. \BSI\TaxFactory\server), where your tf10server.exe executable resides.
That’s pretty much it!
You can restart your Gateway via SAPMMC now.
Test and Sync
Time to test that it works. A connection test to BSI10-US-TAX via SM59 should be successful. Good old RPUBTCU0 via SA38 should be successful. And HRPAYUS_SYNC_TAX_DT should correctly report the new Cyclic and appropriate Regulatory update for Level in BSI Client.
However, you still don’t have Cyclic J in your ECC system. For that you’ll need to run a sync, even if your Regulatory levels already match. And, as usual after a sync in DEV, you’ll need to create both cross-client and client-specific transports to migrate the new status to QAS and PRD.
Great job with this Matt as know many customers are waiting until things settle down in Q1 to start this work effort. Hopefully will see you at HR2016.
Thanks, Jarret. Unfortunately, I will probably not be there, though it's not yet ruled out.
Thanks ! I needed this - Been working on cyclic J this week and confused by RFC libraries 🙂
Thanks for the document Matt.. Have a question.. I have done everything you documented but my application server will still not talk to BSI, I get an error on the RFC. Did you come across that issue with any of your systems? My CI is just fine, RFC works, BSI works. I am going to try a restart tomorrow morning but not sure that will fix the issue. Regards, Todd Scheider
Hi Todd,
Was this a working BSI system before applying the new Cyclic and the new RFC wrapper? Or is this a new install? Basically, did it work before?
If so, then the next thing to try is see if it works using the "old" TF10server.exe executable that was delivered with the cyclic. Just rename the files back the way they were delivered, so your batch file calls the "old" executable, which still uses the classic RFC. If it works fine with the classic RFC, and only fails once you switch to the new executable, then it's definitely something with the setup of the RFC library. If it doesn't work with the classic RFC, then this isn't the problem; you'll need to check everything else about your configuration to find it.
Also, don't forget you can modify your batch file so as to call the "debug" version of the executable as well. This will give you much more detailed logging and can often provide important clues.
Cheers,
Matt
Hi Matt.. thanks for the reply.. Yes, we were using cyclic I and the classic rfc just fine before going to cyclic J. I see your blog details moving the files from lib folder,, I saw the bin folder had two executable files, rfcexec and startrfc,, do these also need copied? I am running Unix not windows.. I am going to restart SAP on our Dev box tomorrow so the gateway restarts, I don't think it will help but worth a shot. Todd
While I can't speak specifically to Unix, I don't think you need rfcexec and startrfc. You just need what's in the lib folder, not the bin folder.
Is your BSI installation on the same host with your ECC system? I generally recommend separating it out, and thus giving it its own gateway, which can help avoid things like restarts. For one thing, the gateway process could hold a lock on the BSI executable, which will prevent replacing it with the new one from the cyclic update. Shutting down the gateway solves that, which is easy if it's a standalone gateway, but might be a bit more problematic if it's part of your ECC system. Anyway, in this circumstance, restarting ECC may actually help.
Yes,, on the same host.. so I have many other things using the gateway.. If the restart doesn't fix the app server I will open an message with either SAP or BSI.. I agreed with your blog,, the instructions on applying the Netweaver RFC is just terrible from SAP. Thanks again. Todd
Hi Matt,, just wanted to update you.. The restart did fix the rfc test issue on the application server. So it was around the gateway most likely.. Thanks again for all your input!! Todd
Hi Matt,
Thanks for your great explanations. I have one question: After doing the upgrade and run a sync for Tube 74, we are still seeing different versions in the back-end like in the below print:
Do you know how we can correct this?
Ionut,
You must apply Note 2242290 to your backend system as a prerequisite to Cyclic J, as the version reporting mechanism has changed with this cyclic. This is most likely the cause of this mismatch you are seeing.
Cheers,
Matt
Hi Matt,
Thanks for your response, but this was the first step we did when we implemented the new version:
I just saw your reply on this subject to the old BSI 10 upgrade thread from two years ago. At this point I think your best course is to start a new discussion thread and ask this question there, so that you can get the most people potentially helping. If that doesn't yield results, then you may need to open an Incident with SAP Support.
Matt,
thank you for providing the steps to upgrade BSI cyclic J with new server rfc.
I am in a process of doing the upgrade as well.
so,I have rename the server.exe file as you requested -
Before we had to edit the server.bat file with the complete path with user id and pwd. so am i doing this here as well?
what should I define in SM59 --> BSIrfc --> program -?
before we had the complete path defined - E:\BSI\BSITF10.i\Server\server\tf10server.bat
please do let me know.
we are using windows 2008 and with sql 2012.
Hello Abhimanyu,
The point of renaming the executables is so that you do not have to edit your tf10server.bat file. You could alternatively not rename the executables and instead change the batch file so that it calls the _new.exe versions instead. Either way will work. Everything should still be in the same path as before, i.e. "E:\BSI\TaxFactory\server."
Likewise, there should be no need to change anything in your RFC Connection in SM59. You aren't changing the path to the batch file, or the executables. You are just updating the executables in that path.
My recommendation, on any cyclic update, is to make a copy of the current "server" folder and rename that to the old cyclic, i.e. "server.tf10i," as a backup, and then overwrite the files in the original "server" folder, so there is no change of path for the RFC call or anything in the batch file.
Cheers,
Matt
Matt
so i have upgraded to cyclic J and kept server.bat file and rename those executable. but I still dont understand the real meaning for updating new rfc files and sdk? its still the same thing.
can you please explain?
There are three versions of the RFC library: Classic Non-Unicode, Classic Unicode, and the new NetWeaver library (which supports both unicode and non-unicode in the same library). Many of the functions of the two classic libraries have been made available in the single new library, as well as some new functions, and so support for the classic libraries is ending. All developers who use the RFC library must port their applications to use the new NetWeaver library.
That is what BSI has done. With Cyclic J, they are providing you with "old" and "new" versions of tf10server.exe: the "old" one uses the classic RFC library, the "new" one uses the new NetWeaver RFC library. As the Cyclic became available before the end of support for the classic library, BSI is giving you a choice. Eventually, however, you need to use the new executables with the new library in order to maintain support.
As far as running TaxFactory is concerned, there is no functional difference, at least not yet. This is just a matter of getting onto a version of the program that works with the new library.
This is explained in Notes 1005832 (Overview on RFC Libraries and SDKs) and 2219445 (BSI TaxFactory wrapper code redesign - old RFC Library going out of maintenance).
Hi Matt,
Any idea what note 2242290 BSI Changes for Cyclic J actually does? I am trying implement the note, but I am getting "cannot be implemented" in SNOTE. I have implemented two pre-req notes (2195497 and 2193769) prior to trying to implement 2242290.
I had some help from BASIS, so Im try to determine if they already implemented 2242290. Any ideas?
Thanks,
Brandyn
Hi Brandyn,
Cyclic J, besides introducing support for the new RFC library, also made some changes in the way that TaxFactory reports its version information back to ECC. Note 2242290 introduces the necessary code changes on the ECC side to correctly read that version information, and that's why it's a prerequisite to the cyclic. Technically, you should be able to operate on Cyclic J without this Note, but you will get lots of warning messages in the payroll run logs about version mismatches, and that will likely cause your payroll administrators to tear out their hair and complain to Basis, or you, or someone. You can put the Note in without Cyclic J, and it should be fine, as it is backwards-compatible to earlier cyclics.
If you are getting "cannot be implemented" in SNOTE, that usually implies that your system doesn't meet the support pack level requirements for it. For instance, if you're on SAP_HR 6.04, then you need to have at least HRSP 77 in your system. You probably have that, as you needed 92, I think, for year-end 2015, so the other possibility is that you're on a higher SP level. The Note is contained in HRSP 94, so if you're on this or higher (or the equivalent for 6.00 or 6.08), then you don't need to implement it.
If someone else might have already implemented the Note, you should see a log to that effect in SNOTE. Select Goto... SAP Note Browser, then put the Note number in the selection field and execute. If the Note has been applied, it should come up in the list, along with a status and access to implementation logs, and who put it in.
Cheers,
Matt
We are actually only on 604.76. Why do you think the minimum SP is 77? I didn't read that anywhere. Could that be the issue?
Thanks,
Brandyn
That is definitely the issue. You can see this information in the Note by clicking on the correction instruction for your release:
This will open a new tab. In that window you'll see a section for Validity Details of Correction, and it will show a start and end support pack range:
But, you have a larger issue to think about. If you are running payroll and doing US payroll tax reporting in your system (which you must be, if you are using BSI TaxFactory), then you need to meet minimum year-end requirements for tax reporting. Year-End 2015 required all 6.04 customers to be on HRSP 92 or higher (Note 2214237 and http://service.sap.com/hrusa). Plus, you probably need at least this level of HR support pack to meet the new ACA reporting requirements. So, I think you need to talk to your management and your support team about a support pack update project, unless you are meeting these reporting requirements outside of your system via some third-party arrangement.
Sorry for the potentially bad news.
Thanks for info (even if bad news).
We handle both tax reporting and ACA via a third party, not SAP's standard solution. .... so we have never needed to be exactly up-to-date for SPs in regards to year end.
Im going to go ahead and load the cyclic to see what happens, but also look into updating to the latest SP. I will keep your blog posted. Thanks for the help.
Brandyn