I would like to know whether there is any RFC or BAPI functions to display change documents (transaction RSSCD001) based on input query in SAP. The customer requirement is to implement a java monitor system on SAP without adding any ABAP functions on the SAP server.
I tried to make use of 'RFC_READ_TABLE' functions, which is deprecated according to the official documents, to read the CDPOS and CDHDR table and join them. But as vwegert said, to traverse the table CDPOS is really time-costing, as it contains billions of table entries.
My intention of this query is to find changes to all bank details of vendors.
Any other thoughts?
Many thanks in advance!
The least resource-consuming way to do this would be to use the workflow runtime system to actively notify the java application whenever a change document is written. You don't have to write any ABAP functions to do this, just setup the workflow engine (using the automatic customizing) and customize the event generation (documentation). Then, you write a java service that connects to the SAP system using JCo and registers as an RFC server using a destination of Type TCP/IP and a registered program ID. This java server program has to provide a function module handler that can be called using tRFC from the SAP system. Finally, add a linkage entry that will tell the workflow runtime system to call your java program each time a change document is written.
Of course, this will only record the changes that happen after installation, not the historical changes.
warning : I'm not very familliar with this field.
The RFC function BAPI_VENDOR_FIND (BAPI Vendor) seems to be used to find vendor based on values in table. You could use it to check gainst the modification date. This is not perfect, as there is no relationnal operator, only equals, and you'll have to check against several dates...
hopes this helps
Guillaume
Related
One customer wants to access a SAP report via RFC.
Steps:
Third party application connects to SAP via RFC
RFC call gets transmitted
SAP runs the report
SAP returns the report.
How can this be implement the part inside SAP?
I am using PyRFC as client library. But AFAIK this does not matter at all for this question. This question is only about the server part inside SAP.
In this case it is the report RM07MLBS which should be made available via RFC.
You need an ABAPer to make a function to you, I think there's no way without it.
If you have a ABAPer just do something like this:
SUBMIT <REPORT_NAME> ... EXPORTING LIST TO MEMORY AND RETURN.
CALL FUNCTION 'LIST_FROM_MEMORY'
TABLES
listobject = t_listobj.
CALL FUNCTION 'LIST_TO_ASCI'
TABLES
listasci = t_ascilist
listobject = t_listobj.
Now you have the list in ASCII format, you can convert it to what you want.
Another way is send the report result to spool, get the spool and convert it to HTML/PDF.
To convert Spool you can use this functions:
RSPO_RETURN_ABAP_SPOOLJOB
RSPO_RETURN_SPOOLJOB_DAT
RSPO_RETURN_SPOOLJOB_HTML
In a perfect world, you'd have the report logic encapsulated in an abap class or a dedicated function module and use that as the basis for both your report and the RFC calls. But if this is a standard SAP report and SAP themselves weren't nice enough to provide said function module, you may not have this option.
I don't think this is the best solution for your request, but just to add another option to the ones already mentioned in other answers: the commercial product Theobald Xtract Universal can execute reports and return the results using several available destination types. Xtract is a windows service that offers connectivity to several target database types as well as a http based result stream. It isn't cheap though, and it essentially only can connect to SAP Netweaver based systems as its data source (at least S/4 is already supported). Target destinations have to be purchased extra, but at least not per system, only per destination type (Oracle, MySQL, MSSQL...).
https://theobald-software.com/en/xtract-universal/
Xtract Universal uses a number of customer function modules to execute the report in the target system, catch the output and return it, essentially as a wall of text. You'll have to parse that result yourself, you won't get a nice pre-parsed table with data in it.
Just to make sure there's no misunderstanding about a possible conflict of interest: I don't work for Theobald, but we are a paying customer and use Xtract for our own data extractions. It is very simple to use, can be executed in scripts, but as said, just does that one job.
As far as I know there is a limited possibility to trigger a report via a rfc-enabled function module. Otherwise try triggering a transaction (based on your report) via function module.
Also check: https://archive.sap.com/discussions/thread/811196
I dont think that you are able to respond the report result to your third party system.
From consulting perspective I would recommend running the report periodically, write results in a table, fetch data from table (from third party system) via RFC-enabled function module.
The best way to do this would be to wrap your report in a bespoke Function Module that is RFC Enabled, then give them access to run that RFC Function Module.
Has anyone ever created a BAPI to create or edit a vendor in SAP R/3 4.6c in the background? I found two BAPIs: BAPI_VENDOR_CREATE and BAPI_VENDOR_EDIT, but both only work online (they call transactions XK01 and XK02).
Basically I need a way to call a function module that would do the same work as transactions XK01 and XK02 but don't need to be called online.
Looking on the SAP community forums, I found a lot of people with the same needs as me, but the answer was never complete.
Could someone give me a suggestion?
As you have discovered, SAP doesn't provide BAPIs for vendor creation/change that can be called in the background (this is, unfortunately, still the case in newer releases).
You have a few possible options:
Create your own BAPI, using (unreleased) SAP function modules for the vendor update.
Create your own BAPI, creating/changing the vendor via a BDC session.
I'd go with option 2. No, BDCs are never ideal and they have a lot of downsides but even a lot of SAP standard function modules for vendor creation seem to go that route and you'll at least be certain that the data in your system is consistent, unlike if you use something like function module VENDOR_INSERT, which does direct table updates without application validation.
Check if the standard vendor data transfer program (RFBIKR00) is in your system - it uses batch input so could be a very useful starting point for your BDC.
I wonder what is the best way to implement global data version for database. I want for any modification that is done to the database to incerease the version in "global version table" by one. I need this so that when I talk to application users I know what version of data we are talking about.
Should I store this information in table?
Should I use triggers for this?
This version number can be stored in a configuration table or in a dedicated table (with one field).
This parameter should not be automatically updated because you are the owner of the schema and you are responsible for knowing when you need to update it. Basically, you need to update this number every time you deploy a new application package (regardless of the reason for the package: code or database change).
Each and every deployment package should take care of updating the schema version number and the database schema (if necessary)
I tend to have a globals or settings table with various pseudo-static values stored.
- Just one row
- Many fields
This can include version numbers.
In terms of maintaining the version number you refer to, would this change when the data content changes? If so, the a trigger would be useful. If you mean for the version number to relate to table structures, etc, I'd be more inclined to manage this by hand. (Some changes may be irrelevant as far as teh applications are concerned, or there maybe several changes wrapped up into a single version upgrade.)
The best way to implement a "global data version for database" is via your source control system and build process. When all the changes have been submitted and passed testing your build process will increment your versioning number schema.
The version number could be implemented in a stored procedure. The result of the call to the stored proc could be added to a screen in your app so you can avoid users directly accessing a table.
To complete the previous answers, I came across the concept of "Migrations" (from the Ruby on Rails world apparently) today, and there was already a question on SO that covered existing frameworks in .Net.
The concept is still to store DB versioning information as data in a table somewhere, but for that versioning information to be managed automatically by a framework, rather than manually by your custom deployment processes:
previous SO question with overview of options: https://stackoverflow.com/questions/313/net-migrations-engine
Can file operations, like creation of a file, be done in ABAP?
Yes it can be done.
You can code in ABAP by using 'open dataset' / 'transfer' / 'close dataset' statements to create files on the Application Server.
You can also create your file directly to a certain application for e.g. MS Excel like so.
Also there are several function modules and classes that can simplify certain tasks like gathering your report output, putting your file on the AS (such as 'GUI_UPLOAD' / 'GUI_DOWNLOAD' / 'WS_DOWNLOAD' / 'SAP_CONVERT_TO_CSV_FORMAT' / etc.) ...
Bear in mind that certain functions modules were built for foreground tasks so they won't work in background job scheduling ...
Yes, it's possible, as nict said before. You should start reading here - that's the official documentation, it covers pretty much everything, including working with files on both the application and the presentation server. It also explains how to use platform-independent filenames - always remember, someday you might encounter an application server running on OS/400 that will not let you write stuff to C:\Temp\MyExport.csv. One more hint: Be careful about the function modules nict mentioned, some of them are not safe to use when unicode content is involved. Always use the methods of class CL_GUI_FRONTEND_SERVICES to be on the safe side.
You can use CL_GUI_FRONTEND_SERVICES class or GUI_DOWNLOAD function. Here is a link
You may use CL_GUI_FRONTEND_SERVICES class. But this services only work on front end. Or you can use some function modules like GUI_DOWNLOAD, GUI_UPLOAD etc.
we can create a flat file with data entered into it, with tabs-separated.
Now, that dota corresponds to the sap tables-fields, where the tables are related to an application, like say, material master.
Now we can use the standard FMs to upload the data to the internal tables of the program and followed by updating the database.
So, uploading flat-file data can be done.
We have upgraded our development SAP system from ECC6 SPS3 to ECC6 SPS5.
An application external to SAP (KOFAX - a SAP certified product) passes an invoice image and invoice data to the SAP system. It then calls the Function Module Z_DICOM_STORE_USING_FB60_FB65 (supplied by KOFAX) in order to store the image on the SAP Content Server and trigger a workflow.
Before the upgrade of the SAP system, this worked, now it does not. An exception is raised within form check_and_add_delimiter (subroutine pool SCMS) which is effectively called from function module SCMS_ARCHIVE_INFO_GET.
The exception is raised because when class method CL_GUI_OBJECT->CLASS_INIT is called, the flags:
GUI_IS_RUNNING
ACTIVEX
JAVABEAN
WWW_ACTIVE
are set to blank values.
This happens when the process is kicked off from the KOFAX GUI. If I run Z_DICOM_STORE_USING_FB60_FB65 from transaction SE37 and populate the structures with the same data, the image is stored and the workflow is triggered.
Please can you suggest why the flags are not being populated when the program runs?
Thanks.
This is a "technical duplicate" of you other posting. Again, the issue is clear - the "KOFAX GUI" appears to use a RFC connection to call the function module, but the function module then uses some other stuff that requires not a RFC connection, but a full-blown SAP GUI at the other end because it tries to access SAP GUI attributes. I'm not into CMS, so I can't help you to figure out why this was changed during the upgrade...
For most scenarios a normal RFC connection is sufficient, SAP GUI is only required if you try to execute BDC within the function module (e.g. for "direct posting"). Since you say that it worked before I can only assume that this is not the case.
Could it not be that the error happens during the upload of the image? Maybe the upgrade did something to the content server configuration? There is a test program for the content server that you can run.
This was resolved by one of our develpers. The answer he gave me was:
We modified check_and_add_delimiter
(subroutine pool SCMS) in order to
overcome this problem (we effectively
stopped the bit of offending code from
being called)