ALE Transactional and VA01 Again

Dear Friends
Some of you gives me good links fordocumentation but after customizing and done a lot of thing I can't have an automatic IDOC when I create a sale order via VA01.
As it was explain in the documentation I have written a module function and done a lot of thing but nothing appens.
With an user exit SAPMVFZZ I can create the IDOC and it well sent to the good port. So BD64 is good.
==========================================================
Table NAST is not filled up when I create an Sales order.
==========================================================
Here after a resume of what I heve done.
If you have a good idea and may be you know why no IDOC when I create an Sales order, you are wellcome.
1. OUTBOUND PROCESSING
1.1. Create IDoc type (WE30) Client independent
IDoc type ZSALES01
To create the IDoc type, follow these next few steps:
Enter transaction WE30 (ALE -> Extensions -> IDoc types -> Maintain IDoc type)
Type in ZSALES01 and click on Basic IDoc type, click the Create icon
EC1VBAK (father) and two sons
EC1VBAP Enter EC1VBA2
1.2. Create message type (WE81) Client independent
To create a new message type, follow these next few steps:
Enter transaction WE81 (ALE -> ALE Development -> IDoc -> IDoc types Development -> WE81 logical messages ZORDER01
Save and exit.
1.3. Link message to IDoc type (WE82 & BD69) Client independent
To link the message types to the IDoc type follow these next few steps:
Enter transaction WE82 (ALE -> ALE Development -> IDoc -> IDoc types Development -> WE82 IDoc Type for message
Enter the message type ZORDER01 and the Basic IDoc type as ZSALES01
Save and exit the result is set in SAP table EDIMSG
1.4. Transaction NACE / NACT
Creation of OUTPUT TYPE Z001 for application V1.
Access sequence 004 = SalesOrg/Sales Order Type
Default Value
Dispatch time send immediately
Transmission Medium Distribution ALE
Time
Timing 2 is set off Job and time entry
Condition table 5 has been generated.
Consistency check for output control all is OK
Assignment output type to partner function In the IMG
Creation of Procedure Z00001 OUTPUT FOR IDOC ZSALES01 for Usage B and application V1
The control procedure: control type z001 requirement 2 (Order confirmation)
1.5. Assign Output type to partner function
Z001 A SP (sold to party)
Transaction V/43 assign Output determination Procedure
Allocate Sales Document header
Sale doc type OR Output procedure Z00001 Output type Z001
1.6. Transaction WE20
Partner profile
Partner number 0000000001
Partner type KU
Partner role SP
Message type ZORDER01
Partner status Actif
Output options
Port A000000002
Pack size 1
Transfer IDOC Immediate YES
Cancel processing after syntax error YES
IDOC Type Basic type ZSALES01
Message control
Application V1
Process code ZVA01
Message type z001
Result of checking (program RSECHK07) with partner 0000000001 and partner type KU: All OK
Table EDP13, table EDP12 message control are well filled up.
A module function is created with the good parameters ZSALESORDERIDOC
The process code point to a function ZSALESORDERIDOC (transaction WE41) Outbound process code
Process code ZVA01 Linked to module function ZSALESORDERIDOC processing with ALE service
Function module version 3.0
Table EDIMSG Output Types and Assignment to IDoc Types give
Message type ZORDER01 Basic type ZSALES01 release 50A
Enter transaction BD69 (ALE -> Extensions -> IDoc types -> Maintain message type for intermed. Structure -> Assign message type to IDoc for ALE)
Enter the message type ZORDER01 and the Basic IDoc type as ZSALES01
1.7. Maintain object type for message type (BD59) Client independent
Type in your message type ZORDER01 and press enter
Enter your object type, KUNNR (We need to use the customer as a filter object), the segment name where KUNNR resides, EC1VBAK, a number 1 for the sequence followed by the actual field name KUNNR
1.8. Configuring the Distribution Model BD64
This task is performed on your ALE reference client.
Manual Configuration (BD64) Client dependent
Create a new model. (Create model POCALE)
POC ALE to send Outbound Idoc POCALE
Choose the receiving systems to which the sending system must forward message type ZORDER01 to.
We have generated the model view after creation.

He Ferry,
I try your checking and with VA02 -> Enter <sales order> -> Enter -> Extras -> Output -> Header -> Edit.
The system propose me Z001 when I click on OUTPUT TYPE (F4).
I have selected Z001 and submit. The following message comes "Processing program missing for output Z001 " ==> "No processing program is defined in table TNAPR for output type Z001 (transmission medium A) in application V1."
In transaction NACE for V1 and OUTPUT type, in TAB Processing routine I can add one program and Form routine.
The module function created zsalesorderidoc has generated a program (SE38) ZSALESORDERIDOC===============FT
Is this one I have to use or I have to create a special one? If I have to create one may I have a model?
In the program ZSALESORDERIDOC===============FT we have these FORM.
FORM EXISTENCE_CHECK CHANGING VARIA.
FORM FUNCTION_CALL.
FORM CLEAR_DATA.
FORM CLEAR_TABLE.
FORM DELETE_LINE USING KEY INDEX.
FORM INIT_EXCEPTIONS USING NAME.
FORM PARAM_ACCESS_TYPES USING KEY DEST P_MODE P_UPPER.
FORM PARAMETER_SET USING NAME DIRECTION VALUE.
PERFORM CB_CALLBACK_VALUE_SET(SAPLSEUJ)
 USING VALUE
 CHANGING %_IOBJECT.
FORM PARAMETER_GET USING NAME DIRECTION
 CHANGING VALUE
 OLD_VALUE.
FORM PARAMETER_TABLE_SET USING NAME VALUE.
FORM PARAMETER_TABLE_GET USING NAME
 CHANGING VALUE.
FORM PARAMETER_DESCRIBE USING CBPROG
 NAME.
FORM PARAMETER_CONTAINER TABLES LCONT STRUCTURE SWCONT
 USING NAME
 DIRECTION .
FORM TABLES_CONTAINER TABLES LCONT STRUCTURE SWCONT
 USING NAME
 DIRECTION.
FORM SET_VARIABLES USING KEY VALUE.
FORM GET_VARIABLES USING KEY
 CHANGING VALUE.
FORM PARAMETER_READ_INPUT USING NAME
 KEY
 CHANGING VALUE.
FORM PARAMETER_READ_OUTPUT USING NAME
 KEY
 CHANGING VALUE.
FORM PARAMETER_COMPARE USING NAME
 CHANGING VALUE.
FORM EXPORT_IMPORT_MEMORY USING SEL KEY STRUCTURE EXPORTKEY.
FORM EXPORT_IMPORT USING SEL KEY STRUCTURE D102N_EXPORTKEY.
FORM GET_EXCEPTION_DIFFERENCE
FORM COMPARE_DATA
 TABLES DIFFERENCES STRUCTURE UNTERSCHIED
 USING FIELD
 CHANGING RETCODE.
Thank you for All
Best regards
Henri

Similar Messages

Regarding updattion of record...in BDC call transaction and session method.

Hi all,
I am uploading 10 records in to sap . By using call transaction method . But after insertion of 5 record server suddenly shutdown. Then what happens . What we have to do
and what about the updated 5 recs as well as remaining 5 recs.
And if it happens in case of BDC-SESSION then what is the status what we have to do..
PLEZ GIVe reply soon...its urgent
regards,
anilreddy...

Hi,
If you are using call transaction , you will not get error messages for balance 5 records that not updated. you need to cross check with the transaction and rerun again.
Session method is concerned no session will be created. system shutdown happened before the close_group,
a®

Last question on ALE and VA01 : how link ALE and VA01 ?

My aim is to send via ALE sales orders when created with transaction VA01 or when modified with transaction VA02.
I have done a lot of customizing and create module function and so and so.
Now what I don't know is how it's working! When I create a sales order with transaction VA01, what I have to do, to make a relationship between transaction VA01 and my IDOC?
It's automatic and I have forgotten some customizing?
Use an Use exit to call the Module function?
Create a workflow on events ?
Or ????
I have created a function to populate and distribute Idocs
but by which action this function will be called during the sales order creation ?
I have used transaction BDBG to link ALE interface and BAPI, WE41 to link process code to function module.
If some one have a little solution, wellcome
Henri

Hi Henri,
I wish I could help you more
But please check this online documentation which will help you to understand and configure the ALE/IDoc for sales orders.
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCSRVEDISC/CAEDISCAP_STC.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCSRVEDI/CAEDI.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/SDEDI/SDEDI.pdf
Again, let me know if you need further assistant.
Regards,
Ferry Lianto
Please reward points if helpful.

SHD0 and VA01 transaction variant: Changes not showing in Test mode

Hi,
I am trying to create a transaction variant using SHD0 for VA01 and VA02 that will grey out the PLTYP field in screens 4301 and 4900.
Everytime I go through the process and exit and save it looks fine, but when I test the variant, the fields are still editable, even though my variant shows them listed as Output Only checked off for the aforementioned screens
I am using the following:
T_Code for variant: VA01
Variant: copy of BUS2032 renamed Z_BUS2032_KPW.
screens to be affected : 4301 and 4900.
I do not want to override the default variant. I am currently in R/3 4.6c.
Any help other than links to the SAP help website (which I have exhausted) would be greatly appreciated.
Thanks,
Kevin Webb
www.innovapost.com

Hello Sai P,
HELP!
I have a similar situation: VA01 running standard and ZVA01, with a hidden field, once I assigned NO_VARIANT to the Order type ZVPV, it is working as desired. However, one strange thing is happening... when I enter ZVA01 and assign the order type ZVPV (which has NO_VARIANT at VOV8) I enter and the field is hidden this all good, then I go back to the screen were the order type is assigned and then I choose another order type ZTA (which has variant in VOV8 in blank) and the hidden field shows, all good as well. However, when I go back again to the order type screen (without going back to the menu screen) and choose again ZVPV and enter the field is showing. Any idea?
Regards.

ALE and VA01 Thank a lot

I would like to thank Ferry Lianto for his help.
Now my ALE transactional flow is working.
It was not easy to me because it is the first time I do it.
Best regards
Henri

Hi Henri,
Glad to help you and finally ... you score big goal.
Enjoy world cup soccer! (if you are soccer fan)
Regards,
Ferry Lianto
Please don't forget to reward the points

I'm really sorry i just bay my griAddress again to my phone please grindar extra just for one month and you charge me for one year so i would like to cancel that transaction and pay only monthly many thanks marcel

I'm really sorry i just bay my griAddress again to my phone please grindar extra just for one month and you charge me for one year so i would like to cancel that transaction and pay only monthly many thanks marcel

These are user forums. You are not speaking to Apple. We can't assist you. You must contact Apple directly in your country.
Customer Service: Contacting Apple for support and service - this includes international calling numbers.

Create transaction and screen variants

Hello
I want to create transaction variant for VA01 and MM01 in order to simplify the data entry. I know SAP has SHD0 as a tool and Synactive has GuiXT to make all these changes. But I wonder what are the differences between these 2 tools.
Please let me know,
Thanks,
George

Dear Mr.George,
Transaction Variant
You can only create transaction variants for dialog transactions and reporting
transactions.Only "normal" screens, dialog boxes, and subscreens can be
included in the variant.
Screen Variants are automatically created anytime you create a
transaction variant.
Initial Screen
Enter the name of the transaction and the transaction variant on the initial screen. The system creates a cross-client transaction variant. If you want to create a client-specific transaction variant, choose Goto -> Client-specific transaction variants tp branch to the client-specific transaction variant maintenance transaction.
Client-specific transaction variants only exist in the client in which they are created. The field contents of the transaction variant must be available in this client. Cross-client transaction variants are available throughout the system, regardless of the client currently being used. The field contents of these transaction variants must be available in all clients.
Creating the Transaction Variant
Choose Create to create a variant.
The system calls the application transaction that you want to create a variant for. Enter the values you want to use in the in the input fields. Each time an action is completed, a Dialog Box, appears listing the fields of the current screen with their current values. The kind of dialog box called depends on the kind of screen currently being processed (see Requirements).
Here you can determine:
if you want to save the field values you have inserted on the current screen (the "Adopt field values" checkbox)
if you want to hide the entire screen (the "Do not display screen" checkbox). This is only possible if settings are copied to your variant ("Adopt field values")
if field contents are saved (the "With contents" checkbox)
if the ready for input status of specific fields should be revoked (the "Output only" checkbox)
if specific fields should be hidden (the "Invisible" checkbox)
if specific fields should be mandatory the "Mandatory" checkbox)
You may or may not be able to select each of these checkboxes for every field depending on the field's type (--> Requirements).
Screen variants are created automatically for each screen where values have been saved (adopted). Enter screen variant names in the "Name of screen variant" field. These names must be unique. If the system is able to find a unique name for a screen variant it is automatically inserted into this field. The convention reads like so: (< name_of_transaction_variant>_(<client>)_<screen_number>).
Choose the function Continue to proceed. The following pushbuttons are available:
The Cancel function displays the current application transaction screen again. Here you can make changes to your settings.
The Menu functions function displays an additional dialog box wher you can deactivate menu functions.
The GuiXT function allows the user to edit a GuiXT script for the current screen (--> GuiXT).
The Exit and Save function exits and saves the application transaction. A list appears containing all of the screens in the application transaction that you want to save entries for (that is, all screens for which screen variants will be created).
Enter a short text for your transaction variant here.
Display settings can be changed as needed from this list in the future. Settings that require information at application transaction runtime (field values, table control columns) cannot be changed from this list.
Choose "Save". The system saves your transaction variant and the corresponding screen variants. The Workbench Organizer dialog box is displayed for the transaction variant and for each screen variant. Use it to assign each of these objects to a package.
You can also branch to this list using the Change values function during the function selection process.
Deleting Preassigned Values
You can delete all of the values you assigned to fields of a single screen in a transaction variant by resetting (deselecting) the Adopt field values checkbox. This deletes the screen from your variant, even those entries that were transferred to the variant during previous processing.
If a screen variant has already been created for this screen, then the system simply deletes the screen variant's transaction variant assignment; the screen variant itself is not actually deleted.
Individual fields can be deleted from transaction and screen variants by resetting (deselecting) their corresponding checkboxes.
If useful reward points.
Regards
Mangal

Re: Transactions and Locking Rows for Update

Dale,
Sounds like you either need an "optimistic locking" scheme, usually
implemented with timestamps at the database level, or a concurrency manager.
A concurrency manager registers objects that may be of interest to multiple
users in a central location. It takes care of notifying interested parties
(i.e., clients,) of changes made to those objects, using a "notifier" pattern.
The optimistic locking scheme is relatively easy to implement at the
database level, but introduces several problems. One problem is that the
first person to save their changes "wins" - every one else has to discard
their changes. Also, you now have business policy effectively embedded in
the database.
The concurrency manager is much more flexible, and keeps the policy where
it probably belongs. However, it is more complex, and there are some
implications to performance when you get to the multiple-thousand-user
range because of its event-based nature.
Another pattern of lock management that has been implemented is a
"key-based" lock manager that does not use events, and may be more
effective at managing this type of concurrency for large numbers of users.
There are too many details to go into here, but I may be able to give you
more ideas in a separate note, if you want.
Don
At 04:48 PM 6/5/97 PDT, Dale "V." Georg wrote:
I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save'button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for any ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
>
>
>
>
====================================
Don Nelson
Senior Consultant
Forte Software, Inc.
Denver, CO
Corporate voice mail: 510-986-3810
aka: [email protected]
====================================
"I think nighttime is dark so you can imagine your fears with less
distraction." - Calvin

We have taken an optimistic data locking approach. Retrieved values are
stored as initial values; changes are stored seperately. During update, key
value(s) or the entire retieved set is used in a where criteria to validate
that the data set is still in the initial state. This allows good decoupling
of the data access layer. However, optimistic locking allows multiple users
to access the same data set at the same time, but then only one can save
changes, the rest would get an error message that the data had changed. We
haven't had any need to use a pessimistic lock.
Pessimistic locking usually involves some form of open session or DBMS level
lock, which we haven't implemented for performance reasons. If we do find the
need for a pessimistic lock, we will probably use cached data sets that are
checked first, and returned as read-only if already in the cache.
-DFR
Dale V. Georg <[email protected]> on 06/05/97 03:25:02 PM
To: Forte User Group <[email protected]> @ INTERNET
cc: Richards* Debbie <[email protected]> @ INTERNET, Gardner*
Steve <[email protected]> @ INTERNET
Subject: Transactions and Locking Rows for Update
I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save' button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for
any
ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
------ Message Header Follows ------
Received: from pebble.Sagesoln.com by notes.bsginc.com
(PostalUnion/SMTP(tm) v2.1.9c for Windows NT(tm))
id AA-1997Jun05.162418.1771.334203; Thu, 05 Jun 1997 16:24:19 -0500
Received: (from sync@localhost) by pebble.Sagesoln.com (8.6.10/8.6.9) id
NAA11825 for forte-users-outgoing; Thu, 5 Jun 1997 13:47:58 -0700
Received: (from uucp@localhost) by pebble.Sagesoln.com (8.6.10/8.6.9) id
NAA11819 for <[email protected]>; Thu, 5 Jun 1997 13:47:56 -0700
Received: from unknown(207.159.84.4) by pebble.sagesoln.com via smap (V1.3)
id sma011817; Thu Jun 5 13:47:43 1997
Received: from tes0001.macktrucks.com by relay.macktrucks.com
via smtpd (for pebble.sagesoln.com [206.80.24.108]) with SMTP; 5 Jun
1997 19:35:31 UT
Received: from dale by tes0001.macktrucks.com (SMI-8.6/SMI-SVR4)
id QAA04637; Thu, 5 Jun 1997 16:45:51 -0400
Message-ID: <[email protected]>
Priority: Normal
To: Forte User Group <[email protected]>
Cc: "Richards," Debbie <[email protected]>,
"Gardner," Steve <[email protected]>
MIME-Version: 1.0
From: Dale "V." Georg <[email protected]>
Subject: Transactions and Locking Rows for Update
Date: Thu, 05 Jun 97 16:48:37 PDT
Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT"
Content-Transfer-Encoding: quoted-printable
Sender: [email protected]
Precedence: bulk
Reply-To: Dale "V." Georg <[email protected]>

Transactions and Locking Rows for Update

I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save' button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for any ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
[email protected]------------------

I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save' button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for any ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
[email protected]------------------

Call transaction and skip first screen

Hi,
I have a little but I think difficult problem
I have a selection screen and after that I call my dnypro. In this dynpro I can open a dynpro which looks like a popup where I have the possibility to call the same transaction with other input paramters.
the problem is when I make call transaction and want to go back I see the pop up dynpro which calls the transaction. so how can I close this popup dynpro by calling again transaction?

I think I can't eyplain it.
Following. I have:
call transaction trans: selection screen calls dynpro 100, in dynpro 100 button with dynpro 200 with starting parameters.
dynpro 200 calls again transaction trans with skip first screen.
now I have displayed again dynpro 100 with new values. When I now want to go back I can see dynpro 200 which called the transaction. So how can I achieve this that dynpro 200 isn't shown when I go back ?

ALE , EDI and IDOC with MM??

hii
What is ALE, EDI and IDOC in SAP??
How its linked with MM??
Explain the above things with example
Thanks

Hi!
IDOC = Intermediate Document
IDoc or Intermediate Document is a standard SAP document format. IDoc's allow different application systems to be linked via a message-based interface.
For more detailled information look in SAPNET under
http://service.sap.com/EDI
For exapmle in purchasing:
The IDoc message type ORDERS is used to send a purchase order to a vendor.
EDI = Electronic Data Interchange
EDI stands for Electronic Data Interchange, which means that data is electronically transmitted from one system to another. The main requirement of EDI is that the systems of the communicating partners understand each other. Usually, the data from one partner gets mapped into the format of the other partner and vice versa.
Supporting this there exist EDI standards (named EDIFACT, ANSIX12, ODETTE, VDA, TRADACOMS, SPEC2000, ...), where the data formatting for exchanging documents are specified. Normally the partners agree using a special standard message (for example EDIFACT message ORDERS for a purchase order).
In the SAP system the outgoing data are stored in IDoc format. When processing a receiving document, the Inbound SAP system receives the data in IDoc format too.
Further processing (converting/mapping from IDoc in another format and vice versa) depends on the partner agreement:
If the partners have agreed using a special EDI standard, mapping between IDoc and the EDI standard is necessary. This mapping is not supported by SAP, external converters or EDI subsystems must be installed by the customers for this purpose.
If both systems use SAP software, there is usually no need for mapping (which can save users a lot of money). The two systems are often connected via ALE (Application Link Enabling).
If partners are using XML, the SAP Business Connector can be used. The business connector is a tool used to help customers connect via EDI. It includes routing and mapping and is XML compatible. To read more about XML at SAP go to SAPNet Alias 'XML' (http://intranet.sap.com/XML).
For example:
Vendor can send the invoice by EDI creating an IDoc with message type INVOIC using IDoc Type INVOICxx. He can determine (depending on the partner agreement) how to create an IDoc for Inbound processing with FI or MM-IV.
ALE = Application Link Enabling
ALE is short for Application Link Enabling. Special Basic programs support this functionaliity (see documentation of BC_MID_ALE).
To link applications you have to configure an ALE model. It contains all relevant data about how a system's configuration (normally a central system and assigned local systems) exchange data.
With help of the ALE technology, the distribution of contracts is possible in MM via the following business process:
Contracts that a central purchasing organization distributes to local purchasing organizations to allow the latter to utilize the more favorable conditions they contain for the procurement of materials or external services.Each local purchasing organization sends information on its own release orders back to the central purchasing organization.
For this purpose the contract in the central system can be copied to the local systems (with message BLAORD and COND_A). When a release order to a distributed contract is created in a local system, the release docu is automatically sent to the central system (with message BLAREL) updating the release docu of the contract in the central system.
Precondition for this scenario is, that in all systems the used master data (material, vendor, sources of supply, ...) are the same. This master data can be distributed by ALE, which should be done before sending the contract from the central system. Available message types for distribution of master data are:
MATMAS (ARTMAS in retail system) for material master
CREMAS for Vendor master
INFREC for info record
SRCLST for source list
COND_A for conditions of info record
SRVMAS for service master data
Technical documentation to ALE can be found by path:
Basis Components / Middleware (BC-MID) / Application Link Enabling (BC-MID-ALE)
The most important Transactions for testing Idoc:
WE02 Display IDOC
WE05 IDOC list
WE19 Testing IDOCs
BD87 Status Monitor for ALE Messages (reprocess)
Notes:
456127 FAQ: Electronic Data Interchange (EDI) in Purchasing
536411 Sample scenario for ALE contract distribution (only internally released)
I hope I could help you fruther
Best regards
Erika

Why it is difficult to copy Business Transactions and make it a Z object

Hi
I am looking for a proper explanation why it is difficult and not suggested to make a copy of the entire business transaction ( example va01 or any other transactions ) and make a z object and modify it so as to companies business scenarios.
I need explanation with respect to solution manager,
where standard sap ticket processing needs to be modified, why can't we copy it into a z object and modify, why we need access key to modify sap standard.
Thanks & Regards
Abhimanyu L

Firstly what is the transaction you wish to modify.
If I were doing it, I would look at how I would modify the standard SAP code compared to the effort in taking a copy. You should also take into consideration the time it may take to resolve any upgrade issues. Personally I would say that changing the standard SAP in most cases would be the quickest to develop. However, your business case may be to complex to amend the standard SAP.
When you copy a standard transaction, there are occasions when the SAP Main program is hardcoded into the SAP code. This can also cause you problems as you would need to amend this to use your version of the main program. You can also have problems with Status menu's as they may be coded to use against the SAP Main program.
Hope that makes sense.

Distributed Transactions and Linked Servers

I'm somewhat of a novice with SQL Server but I'm learning rapidly from an application I'm developing that uses SQL Server very heavily. In conjunction with the development of this application, I have 3-4 systems set up running SQL Server and I am using those
systems to develop the database that will ultimately support the application. I decided to try to use linked servers because I am moving data back-and-forth among the different servers frequently and I ran into some consequences that I wasn't expecting.
I was doing a simple delete query on one of the servers (Delete from TableName Where ...) and I was expecting, of course, that it would only impact the server I was running it on; however, when the query finished after running for a long time, it was apparent
that SQL Server had automatically escalated that simple delete query into a distributed transaction and applied it to all four of the linked servers I had defined. I was totally surprised by that and it took some time to recover the data that was inadvertently
lost on the other servers.
I want to ensure that this doesn't happen again without me expecting it - I think the right way to prevent this from happening is to run the following stored procedure:
EXEC sp_serveroption 'servername', 'remote proc transaction promotion', 'false';
Can someone please verify that this assumption is correct and will prevent SQL Server from automatically creating distributed transactions impacting multiple servers?
Thanks,
Chuck

Hello,
Based on your description, it seems that when you connect to a SQL Server database and execute a DELETE statement to delete a recode on a table, and then the same recode were delete in the linked server which has the same table.
As pre my understand, the statement executed on one server will not apply to the linked servers unless you specify the logic yourself in the application. For example, you use dynamic query and exec the query synchronously on linked servers.
What's more, did you specify replication between this linked server?
If I have any misunderstanding, please let me know.
Regards,
Fanny Liu
If you have any feedback on our support, please click here.
Fanny Liu
TechNet Community Support

Main diff between call transaction and session method

hi frnds.
my friend went for an interview they asked her whts the diff between call tran adn session?
she told more thn one transaction we can call for an session she told itseems. but he told tht by cal tran also u cn call more thn one tran it seems... so please canu help me out regarding this question? how we hve to tell in interview?
in advance thanks....

Hi
Batch Input and CALL TRANSACTION are both data transfer methods. Batch Input usually are used to transfer large amount of data. For example you are implementing a new SAP project, and of course you will need some data transfer from legacy system to SAP system. If there is no standard batch input program, direct input program, you would need to write your own data transfer program and it is going to be batch input program. CALL TRANSACTION methods is real-time method, whenever you run the program CALL TRANSACTION can be triggered. CALL TRANSACTION is used especially for integration actions between two SAP systems or between different modules. Users sometimes wish to do something like that click a button or an item then SAP would inserts or changes data automatically. Here CALL TRANSACTION should be considered. You use CALL TRANSACTION and you do everything automatically, collect necessary data, call transaction and so do database update. If any error occurs, show the user them.
Batch Input
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 session.
It 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 modules calls from the ABAP program.
The most important aspects of the session interface are:
Asynchronous processing
Transfer data for multiple transactions
Synchronous database update. During processing, no transaction is started until the previous transaction has been written to the database.
A batch input processing log is generated for each session
Sessions cannot be generated in parallel. The batch input program must not open a session until it has closed the preceding session.
CALL TRANSACTION
In the second method, your program uses the ABAP statement CALL TRANSACTION USING to run an SAP transaction. External data doesnt have to be deposited in a session for later processing. Instead, the entire batch input process takes place inline in your program. With CALL TRANSACTION USING, the system process 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:
Synchronous processing
Transfer of data from an individual transaction each time the statement CALL TRANSACTION USING is called
You can update the database both synchronously and asynchronously. The program specifies the update type.
Separate LUW (Logical Units of Work) for the transaction. The system executes a database commit immediately before and after the CALL TRANSACTION USING statement.
No batch input processing log

Regarding call transaction and session method???

HI All,
Cud u pls let me know
1. differences between call transaction and session???
2. Is it possible to schedule call transaction in background?? ( all are saying MODE N = background scheduling in call transaction.......but i dont think so)
3. Is it posible to handle multiple transactions in call transaction ? if so,how?
4. Is it posible to handle multiple transactions in session ? if so,how?
5. How can we see the log in session method????

Hi ,
Check this documentation.
About Session method
In this method you transfer data from internal table to database table through sessions.
In this method, an ABAP/4 program reads the external data that is to be entered in the SAP System and stores the data in session. A session stores the actions that are required to enter your data using normal SAP transaction i.e., Data is transferred to session which in turn transfers data to database table.
Session is intermediate step between internal table and database table. Data along with its action is stored in session i.e., data for screen fields, to which screen it is passed, the program name behind it, and how the next screen is processed.
When the program has finished generating the session, you can run the session to execute the SAP transactions in it. You can either explicitly start and monitor a session or have the session run in the background processing system.
Unless session is processed, the data is not transferred to database table.
BDC_OPEN_GROUP
You create the session through program by BDC_OPEN_GROUP function.
Parameters to this function are:
User Name: User name
Group: Name of the session
Lock Date: The date on which you want to process the session.
Keep: This parameter is passed as X when you want to retain session after
processing it or to delete it after processing.
BDC_INSERT
This function creates the session & data is transferred to Session.
Parameters to this function are:
Tcode: Transaction Name
Dynprotab: BDC Data
BDC_CLOSE_GROUP
This function closes the BDC Group. No Parameters.
Some additional information for session processing
When the session is generated using the KEEP option within the BDC_OPEN_GROUP, the system always keeps the sessions in the queue, whether it has been processed successfully or not.
However, if the session is processed, you have to delete it manually. When session processing is completed successfully while KEEP option was not set, it will be removed automatically from the session queue. Log is not removed for that session.
If the batch-input session is terminated with errors, then it appears in the list of INCORRECT session and it can be processed again. To correct incorrect session, you can analyze the session. The Analysis function allows to determine which screen and value has produced the error. If you find small errors in data, you can correct them interactively, otherwise you need to modify batch input program, which has generated the session or many times even the data file.
CALL TRANSACTION
About CALL TRANSACTION
A technique similar to SESSION method, while batch input is a two-step procedure, Call Transaction does both steps online, one after the other. In this method, you call a transaction from your program by
Call transaction <tcode> using <BDCTAB>
Mode <A/N/E>
Update <S/A>
Messages into <MSGTAB>.
Parameter 1 is transaction code.
Parameter 2 is name of BDCTAB table.
Parameter 3 here you are specifying mode in which you execute transaction
A is all screen mode. All the screen of transaction are displayed.
N is no screen mode. No screen is displayed when you execute the transaction.
E is error screen. Only those screens are displayed wherein you have error record.
Parameter 4 here you are specifying update type by which database table is updated.
S is for Synchronous update in which if you change data of one table then all the related Tables gets updated. And sy-subrc is returned i.e., sy-subrc is returned for once and all.
A is for Asynchronous update. When you change data of one table, the sy-subrc is returned. And then updating of other affected tables takes place. So if system fails to update other tables, still sy-subrc returned is 0 (i.e., when first table gets updated).
Parameter 5 when you update database table, operation is either successful or unsuccessful or operation is successful with some warning. These messages are stored in internal table, which you specify along with MESSAGE statement. This internal table should be declared like BDCMSGCOLL, a structure available in ABAP/4. It contains the following fields:
1. Tcode: Transaction code
2. Dyname: Batch point module name
3. Dynumb: Batch input Dyn number
4. Msgtyp: Batch input message type (A/E/W/I/S)
5. Msgspra: Batch input Lang, id of message
6. Msgid: Message id
7. MsgvN: Message variables (N = 1 - 4)
For each entry, which is updated in database, table message is available in BDCMSGCOLL. As BDCMSGCOLL is structure, you need to declare a internal table which can contain multiple records (unlike structure).
Steps for CALL TRANSACTION method
1. Internal table for the data (structure similar to your local file)
2. BDCTAB like BDCDATA
3. UPLOAD or WS_UPLOAD function to upload the data from local file to itab. (Considering file is local file)
4. Loop at itab.
Populate BDCTAB table.
Call transaction <tcode> using <BDCTAB>
Mode <A/N/E>
Update <S/A>.
Refresh BDCTAB.
Endloop.
(To populate BDCTAB, You need to transfer each and every field)
The major differences between Session method and Call transaction are as follows:
SESSION METHOD CALL TRANSACTION
1. Data is not updated in database table unless Session is processed. Immediate updation in database table.
2. No sy-subrc is returned. Sy-subrc is returned.
3. Error log is created for error records. Errors need to be handled explicitly
4. Updation in database table is always synchronous Updation in database table can be synchronous Or Asynchronous.
Error Handling in CALL TRANSACTION
When Session Method updates the records in database table, error records are stored in the log file. In Call transaction there is no such log file available and error record is lost unless handled. Usually you need to give report of all the error records i.e., records which are not inserted or updated in the database table. This can be done by the following method:
Steps for the error handling in CALL TRANSACTION
1. Internal table for the data (structure similar to your local file)
2. BDCTAB like BDCDATA
3. Internal table BDCMSG like BDCMSGCOLL
4. Internal table similar to Ist internal table
(Third and fourth steps are for error handling)
5. UPLOAD or WS_UPLOAD function to upload the data from the local file to itab. (Considering file is local file)
6. Loop at itab.
Populate BDCTAB table.
Call transaction <tr.code> using <Bdctab>
Mode <A/N/E>
Update <S/A>
Messages <BDCMSG>.
Perform check.
Refresh BDCTAB.
Endloop.
7 Form check.
IF sy-subrc <> 0. (Call transaction returns the sy-subrc if updating is not successful).
Call function Format_message.
(This function is called to store the message given by system and to display it along with record)
Append itab2.
Display the record and message.
Check this program for session method using multiple transactions.
Have one BDC_OPEN_GROUP, multiple BDC_INSERT s and one BDC_CLOSE_GROUP.
You should have multiple BDC_INSERT s for multiple transactions.
call function BDC_OPENGROUP.
Build BDC data and cal lBDC_INSERT for transaction 1
Build BDC data and cal lBDC_INSERT for transaction 2
Build BDC data and cal lBDC_INSERT for transaction 3
call function BDC_CLOSE_GROUP.
Check out this sample program
REPORT ztest_report
NO STANDARD PAGE HEADING
 LINE-SIZE 255
 MESSAGE-ID ZRASH.
 Internal Table Declarations *
*--Internal Table for Data Uploading.
DATA : BEGIN OF IT_FFCUST OCCURS 0,
 KUNNR(10),
 BUKRS(4),
 KTOKD(4),
 ANRED(15),
 NAME1(35),
 SORTL(10),
 STRAS(35),
 ORT01(35),
 PSTLZ(10),
 LAND1(3),
 SPRAS(2),
 AKONT(10),
 END OF IT_FFCUST.
*--Internal Table to Store Error Records.
DATA : BEGIN OF IT_ERRCUST OCCURS 0,
 KUNNR(10),
 EMSG(255),
 END OF IT_ERRCUST.
*--Internal Table to Store Successful Records.
DATA : BEGIN OF IT_SUCCUST OCCURS 0,
 KUNNR(10),
 SMSG(255),
 END OF IT_SUCCUST.
*--Internal Table for Storing the BDC data.
DATA : IT_CUSTBDC LIKE BDCDATA OCCURS 0 WITH HEADER LINE.
*--Internal Table for storing the messages.
DATA : IT_CUSTMSG LIKE BDCMSGCOLL OCCURS 0 WITH HEADER LINE.
DATA : V_FLAG1(1) VALUE ' ',
"Flag used for opening session.
 V_TLINES LIKE SY-TABIX,
 "For storing total records processed.
 V_ELINES LIKE SY-TABIX,
 "For storing the no of error records.
 V_SLINES LIKE SY-TABIX.
 "For storing the no of success records.
 Selection screen *
SELECTION-SCREEN BEGIN OF BLOCK B1.
PARAMETERS : V_FNAME LIKE RLGRAP-FILENAME,
 V_SESNAM LIKE RLGRAP-FILENAME.
SELECTION-SCREEN END OF BLOCK B1.
 Start-of-selection *
START-OF-SELECTION.
*-- Form to upload flatfile data into the internal table.
PERFORM FORM_UPLOADFF.
 TOP-OF-PAGE *
TOP-OF-PAGE.
WRITE:/ 'Details of the error and success records for the transaction'
ULINE.
SKIP.
 End of Selection *
END-OF-SELECTION.
*-- Form to Generate a BDC from the Uploaded Internal table
PERFORM FORM_BDCGENERATE.
*--To write the totals and the session name.
PERFORM FORM_WRITEOP.
*& Form form_uploadff
 Form to upload flatfile data into the internal table.
FORM FORM_UPLOADFF .
*--Variable to change the type of the parameter file name.
DATA : LV_FILE TYPE STRING.
LV_FILE = V_FNAME.
*--Function to upload the flat file to the internal table.
CALL FUNCTION 'GUI_UPLOAD'
 EXPORTING
 FILENAME = LV_FILE
 FILETYPE = 'ASC'
 HAS_FIELD_SEPARATOR = 'X'
 HEADER_LENGTH = 0
 READ_BY_LINE = 'X'
 DAT_MODE = ' '
IMPORTING
 FILELENGTH =
 HEADER =
 TABLES
 DATA_TAB = IT_FFCUST
 EXCEPTIONS
 FILE_OPEN_ERROR = 1
 FILE_READ_ERROR = 2
 NO_BATCH = 3
 GUI_REFUSE_FILETRANSFER = 4
 INVALID_TYPE = 5
 NO_AUTHORITY = 6
 UNKNOWN_ERROR = 7
 BAD_DATA_FORMAT = 8
 HEADER_NOT_ALLOWED = 9
 SEPARATOR_NOT_ALLOWED = 10
 HEADER_TOO_LONG = 11
 UNKNOWN_DP_ERROR = 12
 ACCESS_DENIED = 13
 DP_OUT_OF_MEMORY = 14
 DISK_FULL = 15
 DP_TIMEOUT = 16
 OTHERS = 17
IF SY-SUBRC = 0.
*--Deleting the headings from the internal table.
 DELETE IT_FFCUST INDEX 1.
*--Getting the total number of records uploaded.
 DESCRIBE TABLE IT_FFCUST LINES V_TLINES.
ENDIF.
ENDFORM. " form_uploadff
*& Form Form_bdcgenerate
 Form to Generate a BDC from the Uploaded Internal table
FORM FORM_BDCGENERATE .
*--Generating the BDC table for the fields of the internal table.
LOOP AT IT_FFCUST.
 PERFORM POPULATEBDC USING :
 'X' 'SAPMF02D' '0105',
 ' ' 'BDC_OKCODE' '/00' ,
 ' ' 'RF02D-KUNNR' IT_FFCUST-KUNNR,
 ' ' 'RF02D-BUKRS' IT_FFCUST-BUKRS,
 ' ' 'RF02D-KTOKD' IT_FFCUST-KTOKD,
 'X' 'SAPMF02D' '0110' ,
 ' ' 'BDC_OKCODE' '/00',
 ' ' 'KNA1-ANRED' IT_FFCUST-ANRED,
 ' ' 'KNA1-NAME1' IT_FFCUST-NAME1,
 ' ' 'KNA1-SORTL' IT_FFCUST-SORTL,
 ' ' 'KNA1-STRAS' IT_FFCUST-STRAS,
 ' ' 'KNA1-ORT01' IT_FFCUST-ORT01,
 ' ' 'KNA1-PSTLZ' IT_FFCUST-PSTLZ,
 ' ' 'KNA1-LAND1' IT_FFCUST-LAND1,
 ' ' 'KNA1-SPRAS' IT_FFCUST-SPRAS,
 'X' 'SAPMFO2D' '0120',
 ' ' 'BDC_OKCODE' '/00',
 'X' 'SAPMF02D' '0125',
 ' ' 'BDC_OKCODE' '/00',
 'X' 'SAPMF02D' '0130',
 ' ' 'BDC_OKCODE' '=ENTR',
 'X' 'SAPMF02D' '0340',
 ' ' 'BDC_OKCODE' '=ENTR',
 'X' 'SAPMF02D' '0360',
 ' ' 'BDC_OKCODE' '=ENTR',
 'X' 'SAPMF02D' '0210',
 ' ' 'KNB1-AKONT' IT_FFCUST-AKONT,
 ' ' 'BDC_OKCODE' '/00',
 'X' 'SAPMF02D' '0215',
 ' ' 'BDC_OKCODE' '/00',
 'X' 'SAPMF02D' '0220',
 ' ' 'BDC_OKCODE' '/00',
 'X' 'SAPMF02D' '0230',
 ' ' 'BDC_OKCODE' '=UPDA'.
*--Calling the transaction 'fd01'.
 CALL TRANSACTION 'FD01' USING IT_CUSTBDC MODE 'N' UPDATE 'S'
 MESSAGES INTO IT_CUSTMSG.
 IF SY-SUBRC <> 0.
*--Populating the error records internal table.
 IT_ERRCUST-KUNNR = IT_FFCUST-KUNNR.
 APPEND IT_ERRCUST.
 CLEAR IT_ERRCUST.
*--Opening a session if there is an error record.
 IF V_FLAG1 = ' '.
 PERFORM FORM_OPENSESSION.
 V_FLAG1 = 'X'.
 ENDIF.
*--Inserting the error records into already open session.
 IF V_FLAG1 = 'X'.
 PERFORM FORM_INSERT.
 ENDIF.
*--Populating the Success records internal table.
 ELSE.
 IT_SUCCUST-KUNNR = IT_FFCUST-KUNNR.
 APPEND IT_SUCCUST.
 CLEAR IT_SUCCUST.
 ENDIF.
*--Displaying the messages.
 IF NOT IT_CUSTMSG[] IS INITIAL.
 PERFORM FORM_FORMATMSG.
 ENDIF.
*--Clearing the message and bdc tables.
 CLEAR : IT_CUSTBDC[],IT_CUSTMSG[].
ENDLOOP.
*--Getting the total no of error records.
DESCRIBE TABLE IT_ERRCUST LINES V_ELINES.
*--Getting the total no of successful records.
DESCRIBE TABLE IT_SUCCUST LINES V_SLINES.
*--Closing the session only if it is open.
IF V_FLAG1 = 'X'.
 PERFORM FORM_CLOSESESS.
ENDIF.
ENDFORM. " Form_bdcgenerate
*& Form populatebdc
 FOrm to Populate the BDC table.
FORM POPULATEBDC USING VALUE(P_0178)
 VALUE(P_0179)
 VALUE(P_0180).
IF P_0178 = 'X'.
 IT_CUSTBDC-PROGRAM = P_0179.
 IT_CUSTBDC-DYNPRO = P_0180.
 IT_CUSTBDC-DYNBEGIN = 'X'.
ELSE.
 IT_CUSTBDC-FNAM = P_0179.
 IT_CUSTBDC-FVAL = P_0180.
ENDIF.
APPEND IT_CUSTBDC.
CLEAR IT_CUSTBDC.
ENDFORM. " populatebdc
*& Form FORM_OPENSESSION
 Form to Open a session.
FORM FORM_OPENSESSION .
*--Variable to convert the given session name into reqd type.
DATA : LV_SESNAM(12).
LV_SESNAM = V_SESNAM.
*--Opening a session.
CALL FUNCTION 'BDC_OPEN_GROUP'
 EXPORTING
 CLIENT = SY-MANDT
 GROUP = LV_SESNAM
 HOLDDATE = '20040805'
 KEEP = 'X'
 USER = SY-UNAME
 PROG = SY-CPROG
IMPORTING
 QID =
 EXCEPTIONS
 CLIENT_INVALID = 1
 DESTINATION_INVALID = 2
 GROUP_INVALID = 3
 GROUP_IS_LOCKED = 4
 HOLDDATE_INVALID = 5
 INTERNAL_ERROR = 6
 QUEUE_ERROR = 7
 RUNNING = 8
 SYSTEM_LOCK_ERROR = 9
 USER_INVALID = 10
 OTHERS = 11
IF SY-SUBRC <> 0.
 WRITE :/ 'Session not open'.
ENDIF.
ENDFORM. " FORM_OPENSESSION
*& Form FORM_INSERT
 fORM TO INSERT ERROR RECOED INTO A SESSION.
FORM FORM_INSERT .
*--Inserting the record into session.
CALL FUNCTION 'BDC_INSERT'
 EXPORTING
 TCODE = 'FD01'
 POST_LOCAL = NOVBLOCAL
 PRINTING = NOPRINT
 SIMUBATCH = ' '
 CTUPARAMS = ' '
 TABLES
 DYNPROTAB = IT_CUSTBDC
 EXCEPTIONS
 INTERNAL_ERROR = 1
 NOT_OPEN = 2
 QUEUE_ERROR = 3
 TCODE_INVALID = 4
 PRINTING_INVALID = 5
 POSTING_INVALID = 6
 OTHERS = 7
IF SY-SUBRC <> 0.
 WRITE :/ 'Unable to insert the record'.
ENDIF.
ENDFORM. " FORM_INSERT
*& Form FORM_CLOSESESS
 Form to Close the Open Session.
FORM FORM_CLOSESESS .
CALL FUNCTION 'BDC_CLOSE_GROUP'
 EXCEPTIONS
 NOT_OPEN = 1
 QUEUE_ERROR = 2
 OTHERS = 3.
IF SY-SUBRC <> 0.
ENDIF.
ENDFORM. " FORM_CLOSESESS
*& Form FORM_FORMATMSG
 Form to format messages.
FORM FORM_FORMATMSG .
*--Var to store the formatted msg.
DATA : LV_MSG(255).
CALL FUNCTION 'FORMAT_MESSAGE'
 EXPORTING
 ID = SY-MSGID
 LANG = SY-LANGU
 NO = SY-MSGNO
 V1 = SY-MSGV1
 V2 = SY-MSGV2
 V3 = SY-MSGV3
 V4 = SY-MSGV4
 IMPORTING
 MSG = LV_MSG
 EXCEPTIONS
 NOT_FOUND = 1
 OTHERS = 2.
IF SY-SUBRC = 0.
 WRITE :/ LV_MSG.
ENDIF.
ULINE.
ENDFORM. " FORM_FORMATMSG
*& Form form_writeop
 To write the totals and the session name.
FORM FORM_WRITEOP .
WRITE :/ 'Total Records Uploaded :',V_TLINES,
 / 'No of Error Records :',V_ELINES,
 / 'No of Success Records :',V_SLINES,
 / 'Name of the Session :',V_SESNAM.
ULINE.
ENDFORM. " form_writeop
Hope this resolves your query.
Reward all the helpful answers.
Regards

ALE Transactional and VA01 Again

Similar Messages

Maybe you are looking for