BDC_OPEN_GROUP USING DEST

Hi, I need to use Dest parameter in the BDC_OPEN_GROUP function to generate a data set in other system than the program that create this data set. I tried to use the DEST parameter but i can't generate the data set in the other system. Can anybody help me?
Thanks.

BDC_OPEN_GROUP is not a remote enabled function module so you can't call it via RFC with the Destination addition.
If you really need to do this then write a custom RFC module to wrap the standard BDC_OPEN_GROUP FM and set that to be RFC enabled.
I'm honestly not sure why you'd want to do this to be honest or if it will work but hey ho
Gareth.

Similar Messages

%dest

Using "%dest" in LabView's Application Builder results "%dest", but not the correct path! Can anyone help?

Found the solution in the document ID: 2FJA5PXC in the LabView Knowledge-Base

Closed SO shown in Open Item List

Hi experts,
Unfortunately, the below problem (mentioned in Note 948670) occurred in my client's database.
My question is --> In order to hide this kind of CLOSED sales orders in the Open Item List, can I just change RDR6.status from "O" to "C" ?
Note 948670 :
****Closed documents shown in Open Item List - XXX6 table****
Symptom
There are cases where the document is closed, but the sixth table of the document is still open.
As a result the document is shown in the Open Item List.
Other terms
Open document, open item list, 6 table, sixth table, SAP Business One
Reason and Prerequisites
Solution
In order to track these documents the following query should be run on the database:
USE *DEST*
-- change DEST to the name of customer's DB.
declare @doc varchar(3),@fld varchar(10)
Put document----
-- enter here the name of the table acording to the list below.
Set @doc = 'rdr'
Set @fld = CASE
WHEN @doc = 'pdn' THEN 'opencreqty'
ELSE 'openqty'
END
exec ('
SELECT T0.DocNum, T0.DocEntry, T0.DocStatus as ''DocStatus'', T1.Status AS ''Doc6Status''
FROM O' + @doc + ' T0 INNER JOIN ' + @doc + '6 T1 ON T0.DocEntry = T1.DocEntry
Where T0.DocStatus = ''C'' AND T1.Status = ''O''
AND NOT EXISTS
(SELECT 1 FROM ' + @doc + '1 T2 WHERE T0.DocEntry = T2.DocEntry AND
(T2.' + @fld + ' <> 0 OR T2.LineStatus <> ''C''))
You should run the query above on the following tables (documents):
Rdr - in order to track Sales Order that remained open,
Dln - in order to track Deliveries that remained open,
Rdn - in order to Returns that remained open,
Por - in order to track Purchase Order that remained open,
Pdn - in order to track Good Receipt PO that remained open,
Rpd - in order to track Good Returns that remained open.
If you get results after running the select query, please contact your Support Center

hi,
If u update status from open to close directly in db you will lose support,
Raise support ticket as per note in service market place.
Jeyakanthan

What are the ways to Copy Firm Planned Order from one ASCP Plan to another?

We run two EDD Plans with very similar options, but with different plan horizons.
To have the suggestions synchronized, we need to copy the "Firm Planned Orders" from one plan to another.
We tried inserting the records in MSC_ST_SUPPLIES with Order type 5 and firm planned type 1 with appropriate plan id, but Planning ODS Load is not considering those inserted records.
We don't want to insert directly into MSC_SUPPLIES.
Any inputs is appreciated.
Thanks
Sundar

You can also call a custom DTSX package in SSIS via the datamanager.
there are at least 5 ways of transfering data in BPC between apps.
1. Through the front end (excel etc) via evdre/evsnds
2. Through Script logic using *Dest App
3. Using BPC's standard export dtsx package via DM
4. Using SSIS using BPC's custom SSIS tasks
5. Through Script logic using stored procs.
i am sure people will come up with more.
remember if you use ssis and move data into any table but the wb, you need to process the cube afterwards.

PI7.11 AAE configuration

I have Interfaces that use both Classical (pinpline steps in ABAP stack) and local processing (bypassing ABAP stack and thus pipeline steps in AAE).
This is an example scenario for the Local processing I like to do:
ECC<--(soap)PI--
>JDBC client.
I've created RFC destination correctly.
Then sxmif--->created sumparameter, Senderid
In sxmb_adm:
I have IS_URL current value = dest://A_INTEGRATION_SERVER which is the classical way.
Then I added IS_URL assigned subparameter (I named it RECONRPTSENDER" for above scenario) with current value, "dest://AAE_PEH"
According to "How to Set up the Communication between ABAP backend and SOAP Adapter using XI Protocol (http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/70066f78-7794-2c10-2e8c-cb967cef407b?quicklink=index&overridelayout=true)", page 6,
the system checks the entries with sub parameter first (for instance the above scenario has subparameter, RECONRPTSENDER that I assigend) then it should use "dest://AAE_PEH", but it is going to "dest://A_INTEGRATION_SERVER"
When I change the Corresponding Integ. Server to : dest://AAE_PEH, it does work! But I do not want to do that because I need to use the Classical processing for other scenarios!
What am I missing here? Anyone please..

Just FYI on a different note, I ran a test using the direction (dest://AI_INTEGRATION_SERVER) and the error involes calling Inbound proxy.
<Trace level="1" type="B" name="CL_XMS_HTTP_HANDLER-HANDLE_REQUEST" />
- 
<Trace level="1" type="T">XMB was called with URL /sap/xi/engine?type=entry</Trace>
<Trace level="1" type="T">COMMIT is done by XMB !</Trace>
<Trace level="1" type="B" name="CL_XMS_MAIN-ENTER_XMS" />
- 
<Trace level="1" type="B" name="CL_XMS_MAIN-SET_START_PIPELINE" />
- 
<Trace level="1" type="B" name="SXMBCONF-SXMB_GET_XMB_USE" />
<Trace level="1" type="B" name="CL_XMS_TROUBLESHOOT-ENTER_PLSRV" />
<Trace level="1" type="T">****************************************************</Trace>
<Trace level="1" type="T">* *</Trace>
<Trace level="1" type="T">* *</Trace>
<Trace level="1" type="T">XMB entry processing</Trace>
<Trace level="1" type="T">system-ID = RS1</Trace>
<Trace level="1" type="T">client = 400</Trace>
<Trace level="1" type="T">language = E</Trace>
<Trace level="1" type="T">user = PIAPPLUSER</Trace>
<Trace level="1" type="Timestamp">2011-02-04T19:06:51Z EST</Trace>
<Trace level="1" type="T">* *</Trace>
<Trace level="1" type="T">* *</Trace>
<Trace level="1" type="T">****************************************************</Trace>
<Trace level="1" type="B" name="CL_XMS_MAIN-CALL_UC_EXECUTE" />
- 
<Trace level="1" type="T">Message-GUID = 4D4A84750C5E30BFE10000000AFE14E1</Trace>
<Trace level="1" type="T">PLNAME = RECEIVER</Trace>
<Trace level="1" type="T">QOS = BE</Trace>
<Trace level="1" type="B" name="CL_XMS_MAIN-CALL_PIPELINE_SYNC" />
- 
<Trace level="1" type="T">Get definition of external pipeline RECEIVER</Trace>
<Trace level="1" type="B" name="CL_XMS_MAIN-LOOKUP_INTERNAL_PL_ID" />
<Trace level="1" type="T">Corresponding internal pipeline SAP_RECEIVER</Trace>
<Trace level="1" type="B" name="CL_XMS_MAIN-WRITE_MESSAGE_LOG_TO_PERSIST" />
<Trace level="1" type="B" name="PLSRV_CALL_INBOUND_PROXY" />
- 
- <Trace level="1" type="B" name="CL_XMS_MAIN-CALL_PLSRV">
<Trace level="1" type="B" name="CL_XMS_MAIN-CALL_PLSRV_LOCAL" />
- 
</Trace>
<Trace level="1" type="T">System Error at Receiver... => ROLLBACK WORK</Trace>
<Trace level="1" type="B" name="CL_XMS_MAIN-WRITE_MESSAGE_TO_PERSIST" />
- 
</SAP:Trace>

RFC export parameters missing

Hi all,
My scenario is SAP 4.6 RFC to XI 3.0 to SAP 4.6 RFC...I created function Z_SEND_PCARD_PAYMENTS in 4.6 with export and table parameters....Imported this into XI...Setup messages, interface mappings, etc...When I execute RFC (async) using dest XI and look at XML monitor....I see only my table parameters....My RFC export parameters do not show in the payload....
Thanks,
Wiley

Hi,
import parameters in the RFC
are EXPORTING (not export)
parameters in the calling program
>>>Setup messages, interface mappings, etc...
did you define messages in XI for request RFC or response?
(it should be for request)
EXPORTING parameters from your abap report are
import parameters in th RFC and these are request RFC messages in the XI repository
at least that's how it works for me:)
Regards,
michal

Setting External Destination

I have a website (made in VS 2005) that calls the creation of reports from Crystal Enterprise 10. I am trying to get it such that through the website coding I can modify the external destination that the reports are sent to, as they are different each time a report is run. So far I have not been able to successfully get this to work. This is what I am currently getting in CMC when a report is run:
Status: Failed
Printer: The instance is not printed.
External Destination: Not Authorized
Data Refresh Settings: Use the server defaults.
Start Time: 30/09/2008 2:25:59 PM
End Time: 30/09/2008 2:26:06 PM
Server Used: dest.reportjobserver
Error Message: destination DLL disabled. //dest... /CURRENT/ME/309/2009/Maintenance/M/:
I believe that I may inadvertently be setting the instance location, and that it why it is failing, but can't figure out how I should be setting the external destination then. The report runs fine from CE from the same user, even if I modify the destination directory to be what would otherwise fail. I've more than triple checked the security settings for the directory, but perhaps there is still something I missed?
I have tried to set this location through a schedulingInfo object by way of
ceSchedulingInfo.Destination.Name = destination
and directly from the InfoObject through ceReportObject.SchedulingInfo.Destination.Name = destination
and neither worked.
Any ideas?
Edited by: Ryan Beaulieu on Sep 30, 2008 10:51 PM

This forum is dedicated to topics related to legacy SDKs, including the Report Designer Component (RDC), OCX, VCL, and Crystal Reports Print Engine (CRPE).
Please post this query to the .NET Development - BusinessObjects Enterprise forum:
.NET SDK Application Development
That forum is monitored by qualified technicians and you will get a faster response there.
Thank you for your understanding,
Ludek

Batch data communication

How do i decide which method to use when uploading data from legacy system to sap?
In session method
suppose they are 10 records to upload ,if an error occurs at 6th record when uploading data through session ,will the 7,8,9,10 records be processed ,what willhappen?
what is direct input method

Hi Aravind,
Data Transfer
BDC
Batch Data Communication
It is used to transfer data from Sap to Sap or from Non Sap to sap system. It uses the normal transaction codes to transfer the data.
Data Transfer Methods
You can use the following methods to transfer data:
        CALL TRANSACTION: Data consistency check with the help of screen logic.
        Batch input with batch input sessions: Data consistency check with the help of screen logic
Difference between Batch Input and CALL TRANSACTION
If the direct input cannot be used for your task, this makes creating a data transfer program easier since the underlying transactions ensure that the data consistency checks are executed.
In the case of an error during the data transfer (if data records are inconsistent, for example), you can restart the transfer at the point in the program where the error occurred.
Data Transfer Overview
Batch input methods
With the batch input method, an ABAP program reads the external data that is to be entered in the SAP system and stores the data in a batch input session. The session records the actions that are required to transfer data into the system using normal SAP transactions.
When the program has generated the session, you can run the session to execute the SAP transactions in it. You can explicitly start and monitor a session with the batch input management function (by choosing System  Services  Batch input), or have the session run in the background processing system.
CALL TRANSACTION methods
In the second method, your program uses the ABAP statement CALL TRANSACTION USING to run an SAP transaction. External data does not have to be deposited in a session for later processing. Instead, the entire batch input process takes place inline in your program.
Choosing Data Transfer Methods
Selecting a Data Transfer Method
When you transfer data in ABAP, you have three options to submit the data for the data transfer. Only the first two methods can be recommended without reservation. The third method, by way of CALL DIALOG, is outmoded. CALL DIALOG is less comfortable than the other methods. You should use it only if you must.
     Use the CALL TRANSACTION USING statement
Summary: With CALL TRANSACTION USING, the system processes the data more quickly than with batch input sessions. Unlike batch input sessions, CALL TRANSACTION USING does not automatically support interactive correction or logging functions.
Your program prepares the data and then calls the corresponding transaction that is then processed immediately.
The most important features of CALL TRANSACTION USING are:
o     Synchronous processing
o     Transfer of data from an individual transaction each time the statement CALL TRANSACTION USING is called
o     You can update the database both synchronously and asynchronously
The program specifies the update type
o     Separate LUW (logical units of work) for the transaction
The system executes a database commit immediately before and after the CALL TRANSACTION USING statement
o     No batch input processing log
     Create a session on the batch input queue.
Summary: Offers management of sessions, support for playing back and correcting sessions that contain errors, and detailed logging.
Your program prepares the data and stores it in a batch input session. A session is a collection of transaction data for one or more transactions. Batch input sessions are maintained by the system in the batch input queue. You can process batch input sessions in the background processing system.
Your program must open a session in the queue before transferring data to it, and must close it again afterwards. All of these operations are performed by making function module calls from the ABAP program.
The most important aspects of the session interface are:
o     Asynchronous processing
o     Transfers data for multiple transactions
o     Synchronous database update
During processing, no transaction is started until the previous transaction has been written to the database.
o     A batch input processing log is generated for each session
o     Sessions cannot be generated in parallel
The batch input program must not open a session until it has closed the preceding session.
Executing Data Transfer Programs
Procedure
If you are using an SAP data transfer program, follow the procedure specified in the program documentation.
If you are using a generated data transfer program, proceed as follows:
1.     Start the data transfer program.
2.     Decide which batch input method you want to use for the data transfer.
a) CALL TRANSACTION USING:
You must specify the:
Processing mode: You use this parameter to specify whether processing should take place in the background or in dialog mode.
Possible values are:
A     Display all
E     Display only errors
N     No display
Update mode: This parameter determines how the data is to be updated:
Possible values are:
S     Synchronous
A     Asynchronous
L     Local update
Error session: Here you have the option to specify a session name for a batch input session in which data is to be written in the case of an error. You can use this to identify incorrect data records after the batch input program has run and to import the records into the R/3 System once you have corrected them.
If you are creating an error session, you must also specify:
User: Specify the user with whose authorizations the sessions are processed.
Keep session: This specifies whether or not the session should be deleted once it has been processed.
Lock date: Specify the processing date for the error session.
b) Generate session:
Session name: Specify a name for the batch input session to be generated.
User: Specify the user with whose authorizations the sessions are processed.
Keep session: This specifies whether or not the session should be deleted once it has been processed.
Lock date: Specify the processing date for the error session.
3.     Specify a character that is to be used as the NODATA character.
4.     Specify the path of the data file from which the data is to be imported into the R/3 System.
5.     Execute the program.
6.     If you have generated a session, or if errors occurred in CALL TRANSACTION USING mode, you must now edit the generated sessions. You can find information on this in BC - System services in batch input sessions.
Creating a Session with BDC_OPEN_GROUP
Use the BDC_OPEN_GROUP function module to create a new session. Once you have created a session, then you can insert batch input data into it with BDC_INSERT.
You cannot re-open a session that already exists and has been closed. If you call BDC_OPEN_GROUP with the name of an existing session, then an additional session with the same name is created.
A batch input program may have only one session open at a time. Before opening a session, make sure that any sessions that the program closes any sessions that it previously had opened.
BDC_OPEN_GROUP takes the following EXPORTING parameters:
        CLIENT
Client in which the session is to be processed.
Default: If you don't provide a value for this parameter, the default is the client under which the batch input program runs when the session is created.
        GROUP
Name of the session that is to be created. May be up to 12 characters long.
Default: None. You must specify a session name.
        HOLDDATE
Lock date. The session is locked and may not be processed until after the date that you specify. Only a system administrator with the LOCK authorization for the authorization object Batch Input Authorizations can unlock and run a session before this date.
Format: YYYYMMDD (8 digits).
Default: No lock date, session can be processed immediately. A lock date is optional.
        KEEP
Retain session after successful processing. Set this option to the value X to have a session kept after it has been successfully processed. A session that is kept remains in the input/output queue until an administrator deletes it.
Sessions that contain errors in transactions are kept even if KEEP is not set.
Default: If not set, then sessions that are successfully processed are deleted. Only the batch input log is kept.
        USER
Authorizations user for background processing. This is the user name that is used for checking authorizations if a session is started in background processing. The user must be authorized for all of the transactions and functions that are to be executed in a session. Otherwise, transactions will be terminated with no authorization errors.
The user can be of type dialog or background. Dialog users are normal interactive users in the SAP system. Background users are user master records that are specially defined for providing authorizations for background processing jobs.
Advantages:
Types of BDC :
CLASSICAL BATCH INPUT (Session Method)
CALL TRANSACTION
Session method.
1) synchronous processing.
2) can tranfer large amount of data.
3) processing is slower.
4) error log is created
5) data is not updated until session is processed.
Call transaction.
1) asynchronous processing
2) can transfer small amount of data
3) processing is faster.
4) errors need to be handled explicitly
5) data is updated automatically
<b>Regards,
Azhar</b>

Corresponding Integ. Server Configuration ?

Hi,
As per SAP documentation Corresponding Integ. Server configuration should be either
http://<host>:<port>/sap/xi/engine?type=entry
or
dest://<IntegrationServer-Destination>
In my client PI server they are using
dest://INTEGRATION_DIRECTORY_HMI
which is not correct according to SAP.
My question is would that configuration use by PI if the Role of Business System is Integration ?   Since above configuration mainly for Role of Business Application Server ?
Please advise ?
Thank You and Best Regards
Fernand

Hello,
As Rajesh mentioned above the configuration does not look correct as it is at the moment.
It should look something like this:
XI System:        TRX SXMB_ADMIN -> Integration Engine Configuration
      - Role of Business System:    Integration Server
      - Corresponding IS: http://server:port/sap/xi/engine?type=entry
Business System: TRX SXMB_ADMIN -> Integration Engine Configuration
      - Role of Business System:    Application System
      - Corresponding IS: DEST://<your_sm59_http_destination>
   <your_sm59_http_destination>: This is the RFC Destination pointing to
your XI System, that you have maintained via SM59.
Regards,
Sarah

Startup problem 10g

Hai All,
I am using oracle10g. Inorder to use oraclestreams, we have to run database in archive mode. So i shutdown (SHUTDOWN IMMEDIATE & STARTUP MOUNT)the databse and trying to restart in archive mode, then its not restarting . some people saying that this is known issue in oracle 10g. is there any way to start database in archive mode with out shutting down the database.
Please help me out.
With Regards
Hari

There are no "known issues" with "starting" a database that uses archivelog mode.
When you want to start using archive log mode, you STARTUP MOUNT and then ALTER DATABASE ARCHIVELOG. If you do nothing else, then Oracle will set the parameter LOG_ARCHIVE_DEST_10 = 'LOCATION=USE_DB_RECOVERY_FILE_DEST'. This requires that you define a size and location using the appropriate init.ora parameters. Alternatively, and smarter in my opinion, is to manually define init.ora parameter LOG_ARCHIVE_DEST_1 to a valid value, in which case Oracle will stop using dest 10 and negate the need to set the other parameters. For example,
LOG_ARCHIVE_DEST_1='LOCATION=C:\ORACLE\ARCHLOGS\MYDB1' where MYDB1 is the name of my database.
Note in 10g the parameter LOG_ARCHIVE_START has been deprecated. If it's in your init.ora when you set archivelog mode, then the db won't start.

Copy Form Setting from one user to another

Hi,
I am using 2005A.
How to copy form setting (rows and UDFs at header) from one user to another user?
Thanks

Hi Ming Ming On,
I found a note couple of years ago.
I can't remember the note number, and I attach the note here.
Solution
The following queries enables you to set preferences for one user and copy those to another user who is supposed to have the same preferences.
Explanation for the queries variables:
dest - Company database name
sourcid - Represents the user ID from whom the preferences will be copied.
destid - Represents the user ID to whom the preferences will be copied.
How to get the user ID?
From SAP Business One query interface or from the SQL Query Analyzer, run the query as follows:
1. SELECT T0.U_NAME, USERID FROM OUSR T0 FOR BROWSE
2. From the query's results, identify both the sourcid and the destid.
3. In order to copy the preferences from sourcid to destid, run the query as follows:
a) Replace the text dest with the company database name.
b) Replace the text sourceid with the user ID from which the preferences will be copied.
c) Replace the text destid with the user ID to which the preferences will be copied.
d) Use dest, if exists (select 1 from sysobjects where name = 'temp_dev_sup')
e) Begin - drop table temp_dev_sup
f) End - select * into temp_dev_sup from cprf where usersign='sourcid'
Deleting a certain user:
Delete from cprf where usersign='destid'
Update userid in temporary table:
1. Update temp_dev_sup
2. Set usersign='destid'where usersign='sourcid'
Insert preferces into CPRF table
1. Insert into cprf
2. Select "" from temp_dev_sup where usersign='destid*'
예제)
1. Use TEST_MONAMI
2. drop table temp_dev_sup
3. Delete from cprf where usersign='2'
4. select * into temp_dev_sup from cprf where usersign='1'
5. Update temp_dev_sup
Set usersign='2'where usersign='1'
6. Insert into cprf
Select * from temp_dev_sup where usersign='2'

What are the diffrent ways to copy data from one application to another?

Hi,
Can you guys tell me what are the different ways to copy data from one application to another application??
I know we can do it through script logic using DESTINATION_APP.
Is there any other way to copy data from one application to another application?
Please help me
Thanks,
Charly

You can also call a custom DTSX package in SSIS via the datamanager.
there are at least 5 ways of transfering data in BPC between apps.
1. Through the front end (excel etc) via evdre/evsnds
2. Through Script logic using *Dest App
3. Using BPC's standard export dtsx package via DM
4. Using SSIS using BPC's custom SSIS tasks
5. Through Script logic using stored procs.
i am sure people will come up with more.
remember if you use ssis and move data into any table but the wb, you need to process the cube afterwards.

Some windows-user could not see all images on the print result

We have a Problem when printing images (blobObject).
We are printing all displayed images immediately on the report. The images are represented on the report by Blob objects. At runtime we create a Bitmap object in memory, which is stored in a memory stream, the byte array of MemoryStream is placed in the field of the DataSet, which has deposited on the report as BlobObjekt.
The error that occurs is that some Windows-User didnu2019t see all pictures. But without any Errormessage, the picture is still white.
All users use the same Windows-PC with the Crystal Report Version 10.2.3600.0 .
The difference between the pictures is simple:
Picture 1)
-     Note: This picture appears properly
-     This one exists as JPG-File on the harddisk
-     We read the image, convert it into a memory stream and place the byte array in de DataSet-Field
-      This images are positioned in the header and footer section
Picture 2)
-     Note: this picture does not display properly
-     This one is created by the application
-     It is created in memory by an graphics-object
-     This graphics-Object is converted into an memory stream and so on
-     This images are positioned in the details section
Here are the piece of code, which is the dataset supplied with pictures. (abbreviated version)
Using stream As IO.MemoryStream = New IO.MemoryStream
Using dest As Bitmap = New Bitmap(field.Width, field.Height)
            Using gd As Graphics = Graphics.FromImage(dest)
gd.Clear(Color.White)
gd.DrawImage(Source, destrect, sourcerect, GraphicsUnit.Pixel)
dest.Save(stream, System.Drawing.Imaging.ImageFormat.Bmp)
            End Using
      End Using
ds.Tables(datasourceTableName).Rows(j)(datasourceName) = stream.ToArray
stream.Close()
End Using
Has anyone an ideo whats going wrong?
The logic to print the images is always the same only the windows user is different.

Is this a web or windows based application?
Is this happening on the same computer but with a different user? It could be a user rights issue. Try using the Process Monitor tool to see if it is highlighting any permissions issues.
Regards,
Jonathan

Client Proxy: XML message not well-formed unexpected symbol 'target

Hi,
I'm trying to get a client proxy to work based on several blogs (1387,1672)
The error I'm getting now is:
<SAP:ErrorHeader xmlns:SAP="http://sap.com/exchange/MessageFormat">
<SAP:Context />
<SAP:Code p1="XML message not well-formed in node (7 ,49 )unexpected symbol: 'target'" p2="" p3="" p4="">PARSING.GENERAL</SAP:Code>
<SAP:Text language="EN">Parsing error: XML message not well-formed in node (7 ,49 )unexpected symbol: 'target'</SAP:Text>
</SAP:ErrorHeader>
The proxy has been generated successfully
in SXMB_ADM R/3 role is application system and uses dest://rfc_dest
The rfc destination does not accept ?type=entry but apparently also does not need it. When I test the connection it gives a statuscode 200 (not 500)
SLDCHECK works fine.
Not sure where to look for this error?
Any ideas?
Thanks
Tom

Hello Smitha,
I forgot to mention that the message is still in R/3, it has not arrived in XI yet, so the error is visible in SXMB_MONI in R/3.
Also it is just a dummy message, It only contains one node and that is called differently:
<?xml version="1.0" encoding="utf-8" ?>
- <ns1:IF021_HTTP_MSG xmlns:ns1="http://oce.com/xi/eu1/R3CCSEU/IF021_Ordrsp_TD_to_Ordrsp_CCS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<IF021_DT>GetOrdRsp</IF021_DT>
</ns1:IF021_HTTP_MSG>
Any mappings only take place in XI itself, and even there I have no node called target.
Regards
Tom

Step by step batch input

Hi friends,
Please tell me about how to create a batch input from beginning to end.
How can I achieve the entry of the data?
sm35 or shdb is used to record the transaction steps?
One says sm35, the other says shdb?
Step by step?
Thanks in advance.

Hi,
BDC option
ABAP Runtime Environment (BC-ABA)
Batch Data Communication option.
BDC options define the processing mode for a batch input session.
Examples of modes used for processing sessions are:
     Display all records.
     Display for error dialogs only.
     Process session in the background.
     Process session on the screen.
Purpose
During data transfer, data is transferred from an external system into the SAP R/3 System. You can use data transfer when you:
     Transfer data from an external system into an R/3 System as it is installed.
     Transfer data regularly from an external system into an R/3 System. Example: If data for some departments in your company is input using a system other than the R/3 System, you can still integrate this data in the R/3 System. To do this, you export the data from the external system and use a data transfer method to import it into the R/3 System.
Implementation considerations
Before creating your own data transfer program, you should use the Data Transfer Workbench to find the data transfer programs that are delivered by SAP.
The Data Transfer Workbench
Purpose
The Data Transfer Workbench supports the automatic transfer of data into the R/3 System.
The Workbench is particularly useful for large amounts of data. It guarantees that data is transferred efficiently and ensures that data in the R/3 System is consistent.
Features
The Data Transfer Workbench provides the following functions:
     Integration of standard data transfer programs
     Registration and integration of your own data transfer programs
     Various techniques to load data into R/3.
The data is read from a transfer file in SAP format and loaded into the R/3 System using one of the techniques below:
     Administration and organization of data transfer projects
     Tools for analyzing the required SAP structures
     BAPI interface
     Batch input
     Direct input
Integration
SAP applications support the data transfer of numerous SAP business objects. The data transfer program specifies the data format definition that is necessary to import the data into the R/3 System. Adapt your conversion program for exporting the data from the external system to this definition.
Once the data has been exported, you can import it into your system using a generated data transfer program.
Features
     Data transfer from other, external systems
     Generation of data transfer programs
     Generation of function modules that can be used as an interface to the R/3 System
Initial Data Transfer
Prerequisites
Before you start the initial data transfer, you should have answered the following questions:
     Which business objects are to be transferred?
The objects to be transferred depend on the business applications you are using. If you are using sales and distribution processing, for example, you should transfer the material master records as well as the sales master records .
     How should the business objects be transferred?
Various techniques are available to load the data into the R/3.
Process Flow
The process of transferring data can be divided into the steps:
1.     Preparing the data transfer
     Analyzing and Cleaning Legacy Data
     Analyzing SAP Structures
     Developing Programs, Function Modules and BAPIs
     Creating a Program or FM for Data Extraction
     Creating a Mapping Program
     Registering Programs, Function Modules and BAPIs
1.     Executing the data transfer
     Organizing the Transfer in Projects
     Executing Data Transfer Runs, monitoring (CCMS) and processing (log)
     Checking transferred objects in R/3 using a function module or report (task type AUD).
The graphic below describes the steps involved in transferring the data:
ThThe The Data Transfer Workbench is an integrated project management for all the required steps involved in transferring data to your R/3 System.
You need to use programs or function modules for the various steps. SAP provides a range of BAPIs for loading data into R/3.
You could also carry out all the steps, except for loading the data via BAPIs, without using the Data Transfer Workbench.
In the first step you extract the existing data from a source system into a file and clean it there, if necessary.
To load data into R/3 you need a transfer file in an appropriate SAP format.
Using a mapping program you have to map the extracted data to the structures of the transfer file.
To load the data into the R/3 System one of the Techniques is used depending on the type of business object . I f more than one of these techniques is provided for a particular object type, you should read the documentation to find out what the different uses are .
Once you have created a project, you can start a run. The tasks of the run definition are processed in order.
After the data has been successfully loaded into the R/3 System, it can be checked here.
Result
You have transferred the data into the relevant R/3 application and checked it here.
Data Transfer
Purpose
During data transfer, data is transferred from an external system into the SAP R/3 System. You can use data transfer when you:
     Transfer data from an external system into an R/3 System as it is installed.
     Transfer data regularly from an external system into an R/3 System. Example: If data for some departments in your company is input using a system other than the R/3 System, you can still integrate this data in the R/3 System. To do this, you export the data from the external system and use a data transfer method to import it into the R/3 System.
Implementation considerations
Before creating your own data transfer program, you should use the Data Transfer Workbench to find the data transfer programs that are delivered by SAP.
Integration
SAP applications support the data transfer of numerous SAP business objects. The data transfer program specifies the data format definition that is necessary to import the data into the R/3 System. Adapt your conversion program for exporting the data from the external system to this definition.
Once the data has been exported, you can import it into your system using a generated data transfer program.
Features
     Data transfer from other, external systems
     Generation of data transfer programs
     Generation of function modules that can be used as an interface to the R/3 System
Data Transfer Methods
You can use the following methods to transfer data:
     Direct input: With direct input, the SAP function modules execute the consistency checks. However with batch input, these consistency checks are executed with the help of the screens. This means that direct input has considerable performance advantages.
     CALL TRANSACTION: Data consistency check with the help of screen logic.
     Batch input with batch input sessions : Data consistency check with the help of screen logic.
Difference between Batch Input and CALL TRANSACTION
If the direct input cannot be used for your task, this makes creating a data transfer program easier since the underlying transactions ensure that the data consistency checks are executed.
In the case of an error during the data transfer (if data records are inconsistent, for example), you can restart the transfer at the point in the program where the error occurred.
Batch input methods
With the batch input method, an ABAP program reads the external data that is to be entered in the R/3 System and stores the data in a "batch input session". The session records the actions that are required to transfer data into the system using normal SAP transactions.
When the program has generated the session, you can run the session to execute the SAP transactions in it. You can explicitly start and monitor a session with the batch input management function (by choosing System  Services  Batch input), or have the session run in the background processing system.
CALL TRANSACTION methods
In the second method, your program uses the ABAP statement CALL TRANSACTION USING to run an SAP transaction. External data does not have to be deposited in a session for later processing. Instead, the entire batch input process takes place inline in your program.
The information in Choosing Data Transfer Methods will help you decide which is the best data transfer method.
Data Transfer: Overview of Batch Input
Prerequisites
Before beginning the initial data transfer, you should answer the following questions:
     Which business objects are to be transferred?
The business objects to be transferred depend on the business applications that you will be using. If you are using sales and distribution processing, for example, you must transfer the material masters as well as the sales documents from your legacy system.
     How are the business objects to be transferred?
The data can be transferred either manually or automatically, using an SAP data transfer program or using your own transfer program.
Process flow
During the initial data transfer, data from the external system is converted into a sequential data transfer file and then transferred into the R/3 System using an SAP data transfer program. The data transfer file is the prerequisite for successfully transferring data as it contains the data in a converted format that is suitable for the R/3 System.
1.     Check to see if an SAP data transfer program (direct input, batch input or CALL TRANSACTION) exists for this data using the Data Transfer Workbench. Refer to the notes for this transfer program.
If no SAP data transfer program exists, proceed as follows:
2.     Determine the SAP transactions that a user would use to enter data records.
3.     Record these transactions using the batch input recorder. Ensure that you have filled all of the relevant fields with data.
4.     Use this data to generate a data transfer program.
5.     Display the Data Transfer Workbench and create your own data transfer object.
6.     Now follow the steps for transferring data using the Data Transfer Workbench.
The Transaction Recorder
Use
You can use the transaction recorder to record a series of transactions and their screens.
Features
You can use the recording to create
     Data transfer programs that use batch input or CALL TRANSACTION
     Batch input sessions
     Test data
     Function modules.
The recording can be executed several times. The screens are run in exactly the same way as they were run during the recording.
You can edit recordings that you have already made using an editor.
Activities
1.     To display the batch input initial screen, choose System  Services  Batch input Edit.
2.     Choose Recording. The system now displays the initial screen of the batch input recorder.
3.     Make a recording of the relevant transactions.
4.     Generate one or several of the objects named above.
Special features
     F1 -, F4 - and self-programmed F1 - and F4 help ( PROCESS ON HELP-REQUEST , PROCESS ON VALUE-REQUEST ) are not recorded. The same applies to all commands in the System and Help menus.
     Error and warning dialogs are not recorded. This means that only the OK code field and the field contents that lead to successful further processing in the current screen.
     " COMMIT WORK " in a transaction flow indicates the successful end of the transaction as regards batch input. The recording also ends successfully.
     " LEAVE TO TRANSACTION " in the course of a transaction indicates that it is not suitable for batch input. The recording is terminated.
     In ScreenPainter screens, movements in the scrollbar are not recorded. Use the function keys F21-F24 for positioning.
Recording Transactions
The recording forms the basis of generating data transfer programs, sessions, test data and function modules.
Procedure
1.     Display the initial screen of the batch input recorder.
2.     Assign a name to your recording.
3.     Choose Create.
4.     On the subsequent dialog box, enter the transaction code that you want to record and choose Continue.
The system displays this transaction.
5.     Execute the transaction in the usual way.
6.     When you have finished processing the transaction, the system displays an overview of the transaction and your input.
Choose Get transaction if no errors occurred while the transaction was being recorded.
If you do not want to keep the last recording that you made, go to the next step.
7.     Choose Next transac. If you want to record an additional transaction. Then continue from point 4.
8.     Save your recording when you have finished.
Recording
Once you have recorded the transaction, you can process it again later.
Procedure
1.     Display the initial screen of the batch input recorder (Transaction SHDB).
2.     Choose Overview.
The system displays an overview of all recordings.
3.     Position the cursor on the relevant recording and choose Execute.
4.     Choose one of the following processing modes:
A : Display all screens.
E : Display errors only. In the case of an error, the system displays the screen on which the error occurred. Once this error has been corrected, the system continues to process the recording until the next error occurs.
N : No display. The recording is not processed visibly.
5.     Choose the update mode:
A : Asynchronous update
S : Synchronous update
L : Local update
6.     You begin to process the recording when you choose Enter to exit the dialog box. When the recording is complete, the system displays a log that lists the name of the transaction, the system field SY-SUBRC and the system messages that were output.
Using the Recording Editor
The recording editor contains functions that you can use to edit your recordings.
Procedure
1.     Display the initial screen of the batch input recorder (Transaction SHDB).
2.     Choose Overview.
The system displays an overview of all recordings.
3.     Position the cursor on the relevant recording and choose Change.
4.     The following functions are available on the overview that the system displays:
Delete transaction from the recording: This deletes the selected transaction.
Add a new transaction to the recording: The transaction is added at the end of the recording.
Editing: You can edit the current recording.
If you choose Editing, proceed as follows:
5.     The system displays an editor where you can add and delete individual lines. You can also change the contents of these lines.
6.     If these editor functions are insufficient for your requirements, you can choose Export to download the recording onto your presentation host and use a PC editor to edit it there.
7.     Choose Import to import this file back into the R/3 System. Ensure that the file is still in the correct format.
8.     Choose Check to ensure that the edited version of the recording is still syntactically correct.
9.     Save your changes to the recording when you have finished editing it.
Generating Batch Input Sessions From the Recording
The data from the recording is transferred into batch input sessions that you can process for test purposes using the usual mechanisms.
Prerequisites
Before you can generate a batch input session, you must record the transactions through which the data is to enter the R/3 System. You use the batch input recorder to do this.
Procedure
1.     Display the initial screen of the batch input recorder (Transaction SHDB).
2.     Choose Overview.
The system displays an overview of all recordings.
3.     Position the cursor on the relevant recording and then choose Generate session.
4.     Enter a session name, a user with whose authorizations the session is to be processed, the identification whether the session is to be deleted once it has been processed and the processing date.
5.     Choose Continue to exit the dialog box.
You have generated a batch input session that uses the same data for the input fields that you entered when you created the recording. You can now process this as usual.
Generating Data Transfer Programs
Prerequisites
Before you can generate a data transfer program, you must record the transactions using which the data is imported into the R/3 System. You use the batch input recorder to do this.
Procedure
1.     Display the initial screen of the batch input recorder (Transaction SHDB).
2.     Choose Overview.
The system displays an overview of all recordings.
3.     Position the cursor on the relevant recording and choose Create program.
4.     On the following screen, specify a program name.
5.     You can also choose how the maintained field contents of the recorded screens are to be filled:
Transfer the values that were used during the recording. If you require a flexible data transfer, you must modify this program.
Set the parameters of the input values to be maintained and import these values from a data file. To set the parameters, the system creates a data structure and imports the data records from an external file into this data structure. The program assumes that the external file has been adapted to this data structure.
6.     If you have decided to set parameters for the input values to be maintained, it is useful if you create a test file when you generate the program. To do this, flag the checkbox and enter a name for the test file. For more information, see creating a test file.
7.     Choose Continue.
8.     The system displays the attribute screen of the program editor. Choose the relevant attributes here and save the program.
Result
You have now generated a data transfer program that you can use to import data into the R/3 System. The program can execute the data transfer using batch input or CALL TRANSACTION .
Generating Function Modules
Prerequisites
Before you can generate a data transfer program, you must record the transactions using which the data is imported into the R/3 System. You use the batch input recorder to do this.
Procedure
1.     Display the initial screen of the batch input recorder (Transaction SHDB).
2.     Choose Overview.
The system displays an overview of all recordings.
3.     Position the cursor on the relevant recording and choose Create function module.
4.     On the subsequent dialog box, enter a function module name, a function group and a short text for the function module. Exit the dialog box by choosing Continue.
The system automatically creates the function module.
Result
You have now generated a function module that you can use as an interface for your R/3 System. As well as information relevant for the data transfer, the function module's import interface has a parameter for each input field of the transaction recorded.
Using Function Modules
Prerequisites
The function module was generated from a recording made using the batch input recorder.
Procedure
1.     Cal the function module.
2.     Supply the generic interface of the function module:
CTU : Flag whether the data is to be transferred using batch input method CALL TRANSACTION USING . The system generates a batch input session if this flag is not set.
MODE : Processing mode:
A     Display all
E     Display only errors
N     No display
UPDATE : Update mode:
S     Synchronous
A     Asynchronous
L     Local update
GROUP : (If CTU is already specified): Name of the batch input session to be generated
USER : (If CTU is already specified): User with whose authorizations the session is to be processed
KEEP : Specifies whether this session is to be deleted once it has been processed
HOLDDATE : Specifies the earliest processing date for the error session
NODATA : Defines the NODATA character
3.     Supply the function module's special interface.
For each input field that was filled when you recorded the transactions, the system creates an import parameter. The recorded value is used as the default value for this import parameter.
Creating Test Files
To test the data transfer program that you have created, you can create a data record in a sequential file. This data record contains all the field contents from the recording that are relevant to the data transfer in the format required by the data transfer program. It is therefore useful if you align the format of your conversion program data file with the format of the test file.
Prerequisites
Before you can generate a data transfer program, you must record the transactions using which the data is imported into the R/3 System. You use the batch input recorder to do this.
Procedure
1.     Display the initial screen of the batch input recorder (Transaction SHDB).
2.     Choose Overview.
The system displays an overview of all recordings.
3.     Position the cursor on the relevant recording and choose Create test data.
4.     Enter a test file and exit the dialog box by choosing Continue.
You have now created a test file.
If the test file you have specified already exists, the system appends the new data record.
If you do not specify the path, the system archives the test file in the working directory of the current application server.
Executing the Data Transfer
Purpose
You generally use the Data Transfer Workbench to execute the data transfer. The following section describes how you transfer data directly using the batch input method.
Prerequisites
You require a data transfer program. This may be an SAP data transfer program, or you can create your own program.
Process flow
1.     Provide the data to be imported in a data file. Ensure that the data is in the correct format.
2.     If you are using a generated data transfer program, you can choose a data transfer method.
If you are only dealing with one data record, you can import this directly using a generated function module.
3.     Execute the data transfer program.
4.     Analyze the program and correct any errors that occur.
Writing Data Conversion Programs
The data conversion program is responsible for the following tasks:
     Converting the data that is to be transferred into the R/3 System as required by the SAP data structure or transactions that you are using.
If you are using an SAP batch input standard program, you must generate the data structure from the SAP standard data structure (see generating an SAP data structure).
If you develop your own batch input program, the data structure is determined by the R/3 System when the program is generated. Generate a test file from the recording and align the format of your conversion program with the format of the test file.
A conversion may be necessary for data type and length data type and length. The data type required by all standard SAP batch input programs is C, character data. You can find the required field lengths either in your analysis of the data declaration structure of the generated batch input program or in the data structures that you generate.
     The data is exported in SAP format to a sequential file. The batch input program in the R/3 System reads the data in from this file.
Process flow
The tasks involved in writing a data transfer program are shown in the diagram and list below.
Writing Data Conversion Programs
The data conversion program is responsible for the following tasks:
     Converting the data that is to be transferred into the R/3 System as required by the SAP data structure or transactions that you are using.
If you are using an SAP batch input standard program, you must generate the data structure from the SAP standard data structure (see generating an SAP data structure).
If you develop your own batch input program, the data structure is determined by the R/3 System when the program is generated. Generate a test file from the recording and align the format of your conversion program with the format of the test file.
A conversion may be necessary for data type and length data type and length. The data type required by all standard SAP batch input programs is C, character data. You can find the required field lengths either in your analysis of the data declaration structure of the generated batch input program or in the data structures that you generate.
     The data is exported in SAP format to a sequential file. The batch input program in the R/3 System reads the data in from this file.
Process flow
The tasks involved in writing a data transfer program are shown in the diagram and list below.
Selecting a Data Transfer Method
When you transfer data in ABAP, you have three options to submit the data for the data transfer. Only the first two methods can be recommended without reservation. The third method, by way of CALL DIALOG, is outmoded. CALL DIALOG is less comfortable than the other methods. You should use it only if you must.
     Use the CALL TRANSACTION USING statement
Summary: With CALL TRANSACTION USING, the system processes the data more quickly than with batch input sessions. Unlike batch input sessions, CALL TRANSACTION USING does not automatically support interactive correction or logging functions.
Your program prepares the data and then calls the corresponding transaction that is then processed immediately.
The most important features of CALL TRANSACTION USING are:
o     Synchronous processing
o     Transfer of data from an individual transaction each time the statement CALL TRANSACTION USING is called
o     You can update the database both synchronously and asynchronously
The program specifies the update type
o     Separate LUW (logical units of work) for the transaction
The system executes a database commit immediately before and after the CALL TRANSACTION USING statement
o     No batch input processing log
     Create a session on the batch input queue.
Summary: Offers management of sessions, support for playing back and correcting sessions that contain errors, and detailed logging.
Your program prepares the data and stores it in a batch input session. A session is a collection of transaction data for one or more transactions. Batch input sessions are maintained by the system in the batch input queue. You can process batch input sessions in the background processing system.
Your program must open a session in the queue before transferring data to it, and must close it again afterwards. All of these operations are performed by making function module calls from the ABAP program.
The most important aspects of the session interface are:
o     Asynchronous processing
o     Transfers data for multiple transactions
o     Synchronous database update
During processing, no transaction is started until the previous transaction has been written to the database.
o     A batch input processing log is generated for each session
o     Sessions cannot be generated in parallel
The batch input program must not open a session until it has closed the preceding session.
     Use the CALL DIALOG statement
Summary: Not recommended if you can enter data by way of sessions or CALL TRANSACTION USING.
Your program prepares data for a sequence of dialog screens, and calls a dialog module for immediate processing.
The most important aspects of the CALL DIALOG interface are:
o     Synchronous processing
o     Transfers data for a sequence of dialog screens
o     No separate database update for the dialog
A database update occurs only when the calling program executes a commit operation.
o     Shares LUW with calling program
o     No batch input processing log is generated
Executing Data Transfer Programs
Procedure
If you are using an SAP data transfer program, follow the procedure specified in the program documentation.
If you are using a generated data transfer program, proceed as follows:
1.     Start the data transfer program.
2.     Decide which batch input method you want to use for the data transfer.
a) CALL TRANSACTION USING:
You must specify the:
Processing mode: You use this parameter to specify whether processing should take place in the background or in dialog mode.
Possible values are:
A     Display all
E     Display only errors
N     No display
Update mode: This parameter determines how the data is to be updated:
Possible values are:
S     Synchronous
A     Asynchronous
L     Local update
Error session: Here you have the option to specify a session name for a batch input session in which data is to be written in the case of an error. You can use this to identify incorrect data records after the batch input program has run and to import the records into the R/3 System once you have corrected them.
If you are creating an error session, you must also specify:
User: Specify the user with whose authorizations the sessions are processed.
Keep session: This specifies whether or not the session should be deleted once it has been processed.
Lock date: Specify the processing date for the error session.
b) Generate session:
Session name: Specify a name for the batch input session to be generated.
User: Specify the user with whose authorizations the sessions are processed.
Keep session: This specifies whether or not the session should be deleted once it has been processed.
Lock date: Specify the processing date for the error session.
3.     Specify a character that is to be used as the NODATA character.
4.     Specify the path of the data file from which the data is to be imported into the R/3 System.
5.     Execute the program.
6.     If you have generated a session, or if errors occurred in CALL sTRANSACTION USING mode, you must now edit the generated sessions. You can find information on this in BC - System services in batch input sessions.
Batch Input Authorizations
You do not need special authorization - other than the ABAP run time authorization (authorization object S_PROGRAM - to run a program that creates batch input. Any user can create batch input sessions.
Starting processing for a session once it is in the queue is another matter, however. You can find more information on this in batch input sessions.
Creating a Session with BDC_OPEN_GROUP
Use the BDC_OPEN_GROUP function module to create a new session. Once you have created a session, then you can insert batch input data into it with BDC_INSERT.
You cannot re-open a session that already exists and has been closed. If you call BDC_OPEN_GROUP with the name of an existing session, then an additional session with the same name is created.
A batch input program may have only one session open at a time. Before opening a session, make sure that any sessions that the program closes any sessions that it previously had opened.
BDC_OPEN_GROUP takes the following EXPORTING parameters:
     CLIENT
Client in which the session is to be processed.
Default: If you don't provide a value for this parameter, the default is the client under which the batch input program runs when the session is created.
     GROUP
Name of the session that is to be created. May be up to 12 characters long.
Default: None. You must specify a session name.
     HOLDDATE
Lock date. The session is locked and may not be processed until after the date that you specify. Only a system administrator with the LOCK authorization for the authorization object Batch Input Authorizations can unlock and run a session before this date.
Format: YYYYMMDD (8 digits).
Default: No lock date, session can be processed immediately. A lock date is optional.
     KEEP
Retain session after successful processing. Set this option to the value X to have a session kept after it has been successfully processed. A session that is kept remains in the input/output queue until an administrator deletes it.
Sessions that contain errors in transactions are kept even if KEEP is not set.
Default: If not set, then sessions that are successfully processed are deleted. Only the batch input log is kept.
     USER
Authorizations user for background processing. This is the user name that is used for checking authorizations if a session is started in background processing. The user must be authorized for all of the transactions and functions that are to be executed in a session. Otherwise, transactions will be terminated with "no authorization" errors.
The user can be of type dialog or background. Dialog users are normal interactive users in the R/3 System. Background users are user master records that are specially defined for providing authorizations for background processing jobs.
Adding Data to a Session: BDC_INSERT
Use the BDC_INSERT function module to add a transaction to a batch input session. You specify the transaction that is to be started in the call to BDC_INSERT. You must provide a BDCDATA structure that contains all of the data required to process the transaction completely.
BDC_INSERT takes the following parameters:
     TCODE
The code of the transaction that is to be run.
     POST_LOCAL
Parameter to update data locally. If POST_LOCAL = X, data will be updated locally.
(refer to the keyword documentation of SET UPDATE TASK LOCAL for more information)
     DYNPROTAB
The BDCDATA structure that contains the data that is to be processed by the transaction.
DYNPROTAB is a table parameter in the function module.
Closing a Session: BDC_CLOSE_GROUP
Use the BDC_CLOSE_GROUP function module to close a session after you have inserted all of your batch input data into it. Once a session is closed, it can be processed.
Function Module BDC_CLOSE_GROUP
Exception parameters
Parameter     Function
NOT_OPEN     Client
QUEUE_ERROR     Internal use
BDC_CLOSE_GROUP needs no parameters. It automatically closes the session that is currently open in your program.
You must close a session before you can open another session from the same program.
You cannot re-open a session once it has been closed. A new call to BDC_OPEN_GROUP with the same session name creates a new session with the same name.
Processing Batch Input Sessions
When you create a batch input session, it remains in the batch input queue until it is explicitly started. Session processing can be started in two ways:
     An on-line user can start the session using the batch input menu options. (To access the batch input options, choose System  Services  Batch Input.)
     You can submit the background job RSBDCSUB to start a session in background processing. If several sessions have the same name, RSBDCSUB starts them all.
Its possible to coordinate the generation and execution of a session in the background processing system.
You can, for example, schedule both the batch input program and RSBDCSUB in the background. If you designate the batch input job as the predecessor for RSBDCSUB, then RSBDCSUB will be started automatically when the batch input job successfully completes.
Alternatively, you can schedule both the batch input program and RSBDCSUB as job steps in a single background job. In this case, however, RSBDCSUB is started even if the batch input program should terminate abnormally.
For detailed information about processing batch input sessions, see Managing Batch Input Sessions in the System Services guide.
Frequent Data Transfer Errors
The most frequent errors include:
     The BDCDATA structure contains screens in incorrect sequence.
     The BDCDATA structure assigns a value to a field that does not exist on the current screen.
     The BDCDATA structure contains a field that exceeds the specified length.
General guidelines
You should be aware of the following guidelines when you create sessions and call transactions or dialogs:
     You must provide data for all required fields on a screen.
     You can only specify the initial data for a screen. The system does not accept input as a response to a warning or an error message.
     If there is more than one possible screen sequence for a transaction or dialog, your program specifies the screen sequence for the transaction. You must transfer all screens that the dialog user sees to the selected screen sequence. This applies even if the screen itself is not used to input data.
Direct Input
To enhance the batch input procedure, the system offers the direct input technique, especially for transferring large amounts of data. In contrast to batch input, this technique does not create sessions, but stores the data directly. It does not process screens. To enter the data into the corresponding database tables directly, the system calls a number of function modules that execute any necessary checks. In case of errors, the direct input technique provides a restart mechanism. However, to be able to activate the restart mechanism, direct input programs must be executed in the background only. To maintain and start these programs, use program RBMVSHOW or Transaction BMV0.
Examples for direct input programs are:
Program     Application
RFBIBL00     FI
RMDATIND     MM
RVAFSS00     SD
RAALTD11     AM
RKEVEXT0     CO-PA
Pls reward points.
Regards,
Ameet

BDC_OPEN_GROUP USING DEST

Similar Messages

Maybe you are looking for