LUW implementation between RFC calls

Hi Experts,
I have a quick requirement in which i have to implement LUW explicitly during RFC call.My requirement is as below
I have 3 Rfc for a Ztable these are 1. Zcreate_entry , 2.Zupdate_entry and
3. Zdelete_entry. Now i want to create a explicit session for all the operation done by these Rfcs so that at the end of the session i can commit all the operations.
Example
User will call 1 RFC for leting me know that now start a new session.now user will insert 5 entry in Ztable by calling Zcreate_entry(Actually this data should not be saved in ZTable) , Update 4 Entry in Ztable by calling Zupdate_entry(Actually this data should not be updated in ZTable) , delete few entry same way.
Now user will call 1 Rfc for ending this session(for letting me know only that end this session) , At this point only all the data changes (inserted , updated and deleted ) should be actually reflected in database.
Regards,
Abhishek
Edited by: ABHISHEK BAJPAI on Jan 20, 2009 12:43 PM
Edited by: ABHISHEK BAJPAI on Jan 20, 2009 12:43 PM

Hi All,
If you have not got the problem , let me explain complete scenario.
There are three RFcs for creating , updating and deleting in database table(Ztable).
Now these Rfcs will be called from web dynpro, In WD screen user may call Create RFC 5 times for creating entry in Ztable ,then he can call Update RFC for updating in Ztable.
After doing all these operations in single session now he wants to end the session, so before closing the session WD notifies to backend that now at this point only save all the changes to the backend thus for all the operations commit will happen now only.
*Another requirement is * that from WD screen if user1 has created 5 records but he has not commited these changes to database now if User1 searches for just inserted recorded(which is not commited yet) , how to provide these records to the User1 because these records are not in Ztable at that point of time.
Regards,
Abhishek

Similar Messages

Error in parameters assignment between rfc call and xi message

Hi all
In a sender rfc scenario, i am exporting a table.
The table structure is
field name           type          length
resourceno         numc          10
shipmentno -      numc         10
startdate             dats
I have imported the rfc definition in xi design too.
The data i gave in rfc is 1234567890 , 1234567890 , 11112004 ,
But in xi, the message i m getting from the rfc adapter is
<?xml version="1.0" encoding="UTF-8" ?>
- <rfc:Z_UPDATE_FMS xmlns:rfc="urn:sap-com:document:sap:rfc:functions">
- <RESOURCEINFO>
- <item>
<RESOURCENO>1234567890</RESOURCENO>
<SHIPMENTNO>2004111112</SHIPMENTNO>
<STARTDATE>0000-00-00</STARTDATE>
    </item>
</RESOURCEINFO>
</rfc:Z_UPDATE_FMS>
The third parameter date (of 8 characters) is assigned to shipment field and the first 2 characters of shipmentno field is concatenated with that.
Any idea what could have gone wrong?

Aarthi,
Did you checked the source under Inbound Message--->Payloads?
How come <SHIPMENTNO>2004111112</SHIPMENTNO> segment has 2004111112 as per your input it should come as 1111200412 isn't it?
raj.

Questions about the difference between RFC calls with and without JavaProxy

Hello,
I have a two questions:
1. Why is it more user-friendly to access SAP data in conjunction to plain JCo calls as explained here http://help.sap.com/saphelp_nw04/helpdata/en/79/c6213e225f9a0be10000000a114084/content.htm? Waht's exactly the reason for?
2. What's exactly the runtime shown in the picture here http://help.sap.com/saphelp_nw2004s/helpdata/en/ed/897483ea5011d6b2e800508b6b8a93/frameset.htm?
Regards,
Armin

Moin Armin,
from what I understand from the first link, SAP is probably trying to say that it is user friendly because not everyone needs to be concerned regarding the actual JCo calls to the SAP backend. Rather they can simply work with the generated proxies as if they were actually working with the SAP Tables. The mapping, JCo calls and data transfer is taken care of by the Enterprise Connector.
For instance, you can generate proxies of the BAPIs on your side and let 10 users work with the structures and tables and when it is deployed, the JCo calls are automatically taken care of (from the SLD).
The figure in the second link just shows the runtime to illustrate that the native calls are hidden (again probably the same point I made before).
I am not sure, just my interpretation
Bye,
Sameer

Making an RFC call from within the VM container

Hi all,
since a long time I am searching for information on how to implement an RFC call from within the VMC. The problem is that we have implemented several (p)functions in ABAP and we need to implement them in JAVA.
Now I am searching for a way how to just call the already existing pfunctions???
Is it possible to read CRM DB tables too?
Thank you in advance
Boris

Hi Freeto,
This may be due to the Network Failures.
If you have triggered a job then because of the Network fluctuations the system may not respond properly and cannot execute the job.
So, this is the cause for the failure.
Hope you understood.
With Regards,
Ravi Kanth

RFC call failing due to UNICODE implementation

Hi
We are trying to connect to a SAP system using the JCO (SAP-JAVA Connectivity). We are passing the user name as an input parameter and in turn the SAP system send back the no. of item (ABAP Type integer) pending for the user name to the java and its inserted/updated in Oracle DB (which does accept the unicode characters).
It was all wokring fine untill the SAP system has been migrated to Unicode upgrade. Now the RFC call is getting failed from our system. On analysis we found with debug, that the user name is not getting accepted by the SAP system and throwing the error -says Exception in thread "main" com.sap.aii.proxy.framework.core.BaseProxyException: Conversion error between two character sets., error key: RFC_ERROR_SYSTEM_FAILURE and at the SAP end the error says "Conversion of "UNAME" from code page 4103 to 4102 is failed". The unicode change in SAP system cannot be reverted back due to some constraints.
Can you please help, how can we pass the user name as encoded in character set 4102 or any other solution so that it can be accepted by SAP and run the Function module and return the data.
Many Thanks
Snehil Joshi

Check RFC destination in Tx SM59. You must have one tab for unicode settings.
Regards.

Optimize the performance of the RFC call between ECC and CRM

Hi,
We are planning to extract sales orders, sales activites and service orders to dispaly it on the PDF factsheet of the account.
As of now, the PDF factsheet takes a long time to retrieve the data from ECC to CRM. Can you please suggest us on ways to optimize the performance of the RFC call between ECC and CRM.
Thanks in advance,
Vamsi.

Hello,
[SAP Note 636906 |https://service.sap.com/sap/support/notes/636906]is quite useful here.
Many times, the performance is poor due to function module CRM_CCKPT_EXPORTSUMMARY. This function module gets the customer number, the sales organization and the fact sheet view. If in CRM customizing, you use complete view (001), then all the views in ERP including all the info blocks will be retrieved, which will cause performance issue.
To solve the issue, please use a limited view to retrieve the data from ERP - especially a view, which does not contain info block 013.
Hope it helps
Joaquin

Remove RFC calls between SRM and ERP

Hi,
Did any of you ever worked on removing RFC calls between SRM and ERP systems?
Does SAP maintains a lost of these built-in RFC calls?
What are the known constraints to replace them by webservice calls ?
Thanks
Yann

Hi Yann,
There is nothing on the SAP database for SRM and the backend using webservice.
There is for connections to SRM catalog.
I haven't heard anything about plans to change this.
Hope this helps,
Kind Regards,
Matthew

Passing chinese character from RFC call between unicode & non unicode syst.

Hi Experts,
I am making a RFC call from an ABAP in non unicode system to a Function module in Unicode system and filling the itab fields in ABAP by using move statement and using offset in order to populate amount fields correctly from flat structure tables returned by function module. But i am facing problem in getting chinese characters correctly in return from the Remote Function Module.
        CALL FUNCTION 'ZFXX_GET_CLR_OI'
          STARTING NEW TASK W_TASKNAME
          DESTINATION S_RFCDES-LOW
          PERFORMING F3100_GET_RFC_DATA ON END OF TASK
          EXPORTING
            P_WAERS               = P_WAERS             "Screen Curr
            P_AUGDT               = P_AUGDT             "Clearing date
            P_BUKRS               = P_BUKRS             "Comp Code
          TABLES
            T_SEL_TABLE           = T_SEL_TABLE
            T_OUTPUT              = T_MCDATA
            T_ERRORS              = T_EMCDATA
          EXCEPTIONS
            COMMUNICATION_FAILURE = 1
            SYSTEM_FAILURE        = 2
            OTHERS                = 3.
       MOVE : t_mcdata1-line+0(32)   TO t_succs-awsys,
               t_mcdata1-line+32(4)   TO t_succs-bukrs,
               t_mcdata1-line+36(10) TO t_succs-belnr,
               t_mcdata1-line+46(4)   TO t_succs-gjahr,
               t_mcdata1-line+50(1)   TO t_succs-shkzg,
               t_mcdata1-line+51(2)   TO t_succs-bschl,
               t_mcdata1-line+53(4)   TO t_succs-gsber,
               t_mcdata1-line+57(16) TO t_succs-dmbtr,
               t_mcdata1-line+73(16) TO t_succs-wrbtr,
               t_mcdata1-line+89(5)   TO t_succs-pswsl,
               t_mcdata1-line+94(6)   TO t_succs-vbund,
               t_mcdata1-line+100(10) TO t_succs-hkont,
               t_mcdata1-line+110(10) TO t_succs-prctr,
               t_mcdata1-line+120(16) TO t_succs-dmbe2,
               t_mcdata1-line+136(20) TO t_succs-txt20.
        APPEND t_succs.
Can anybody suggest or advice me on it ? Any help or suggestion would be appreciated.
Thanks in advance,
Akash

.

Message transfer between R/3 to XI By RFC call

Hi all,
I am trying to pass some parameters to XI by making an RFC call from R/3.In sm59 the connection is working fine with the RFC destination declared.I have created an RFC enabled function module and it has   5 import parameters .The FM doesn't contain any query as i have queried in the calling program. The program as followes;
DATA : IT_ZXIRFC LIKE ZXIRFC.
DATA: IS_BILL_NUM LIKE ZXIRFC-BILL_NUM,
      IS_BUYERVATNUM LIKE ZXIRFC-BUYERVATNUM,
      IS_BUYERACCNUM LIKE ZXIRFC-BUYERACCNUM,
      IS_PRODUCTDES LIKE ZXIRFC-PRODUCTDES,
      IS_BUYERNAME LIKE ZXIRFC-BUYERNAME.
SELECT * FROM ZXIRFC INTO IT_ZXIRFC
         WHERE BILL_NUM = 'ABC1234'
           AND BUYERVATNUM = 'CH456789'
           AND BUYERACCNUM = 'THE456789'.
ENDSELECT.
       IS_BILL_NUM = IT_ZXIRFC-BILL_NUM .
       IS_BUYERVATNUM = IT_ZXIRFC-BUYERVATNUM.
       IS_BUYERACCNUM = IT_ZXIRFC-BUYERACCNUM.
       IS_PRODUCTDES = IT_ZXIRFC-PRODUCTDES.
       IS_BUYERNAME = IT_ZXIRFC-BUYERNAME.
CALL FUNCTION 'ZRFC_XI_TEST1' IN BACKGROUND TASK DESTINATION 'SAP_X3ATEST'
EXPORTING
    I_BILL_NUM          = IS_BILL_NUM
    I_BUYERVATNUM       = IS_BUYERVATNUM
    I_BUYERACCNUM       = IS_BUYERACCNUM
    I_PRODUCTDES        = IS_PRODUCTDES
    I_BUYERNAME         = IS_BUYERNAME
COMMIT WORK.
I am getting notthing in moniter of XI when i excecute this program.
Please have a look at this and suggest me the solution.
Thank you,
Best regards,
Priya parmeshwar.

Hi,
In SM59 my RFC destination is working fine.I have done the configuration according to Michal' blog
https://weblogs.sdn.sap.com/pub/wlg/1438.The [original link is broken] [original link is broken] [original link is broken] [original link is broken] RFC destination details as followes:
RFC destination : SAP_X3ATEST
Gateway Host :   ld8022
Gateway service: sapgw22
Program Id : RFCTEST1
and here i have checked the Registered server program.
The same data has been updated in communication channel with a sender RFC adapter type.
Thankx,
Priya

Trigger an RFC call to ECC from PI using BPM

HEllo Experts,
This is my first time in ccBPM and require your expertise in gaining some insights onto calling an RFC FM using ccBPM.
I am typically implementing the scenario as it is mentioned in this blog: /people/mitesh.parekh/blog/2008/12/01/receiving-aleaud-as-acknowledgment-in-ccbpm in order to generate acknowledgements from ECC.
I have created the IR and ID and I am successfully able to exceute the BPM till step2. Step 3 is the ABAP mapping part for which i have specified teh required properties and Operation mapping too.
My concern is that how do i proceed from Step 4 i,e how do i trigger this RFC call to ECC and receive it in BPM again?
Thanks in advance,
Elizabeth.

I am developing a scenario which looks like this MDM ->PI ( BPM) -> ECC.
Now the Integration process that I am developing is with reference to blog http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/12249. [original link is broken] [original link is broken] [original link is broken]
I am posting MATMAS from MDM which is received in first step(receive step) of this BPM.
2nd step (Send step - BPM) will send this MATMAS05 Idoc to ECC and Pi will have a message id generated for this message.
3rd step of BPM (ABAP mapping) - which will read the actual PI Idoc number from system tables based on the message id from step 2.
4th step: Idoc number retrieved is to be sent in the requset message of RFC ZALEAUD4XI.
5th step: Response of ZALEAUD4XI RFC is to be received in PI and sent for further processing.
Do i need a mapping between the requset output of ABAP mapping and the input RFC requset message of step4?
Thanks,
Elizabeth

System error during RFC call BAPI_FIXACCOUNT_GETLIST

Hi Gurus,
Below are the error and steps when i perform Payroll Posting to Accounting. To enable communication between distributed systems, the appropriate method have been specified in ALE Customizing for the objects of the following tables. (Basis -> Application Link Enabling (ALE) -> Modelling and Implementing Business Processes -> Maintain Distribution Model and Distribute Views.)
However, error still exists as shown below:-
1.     Run TCode PC00_M99_CIPE
2.     Encountered Error as shown below:
Communication error with system QAS, function FI_ACCT_DET_HR
Message no. 3G404
Diagnosis
The function module "FI_ACCT_DET_HR" has been called remotely in system "QAS". As a result, an error occurred when creating the connection or during communication.
Procedure
Check that the ALE distribution model is correctly maintained.
Account determination could not be performed
Message no. 3G361
Diagnosis
The account could not be determined for one of the following reasons:
No destination could be found in the ALE distribution model for the AcctngEmplyeeExpnses.Check method.
A system or communication error occurred when executing the function FI_ACCT_DET_HR in the target system.
System error during RFC call BAPI_FIXACCOUNT_GETLIST: / CPIC-CALL: 'ThSAPCMINIT' Unknown serv ice
Message no. KI012
3.      Check in SM21: NiConnect Unsuccessful, Return Code: -0003
                    Communication error, CPIC return code 020, SAP return code 665
Please advice. Thanks in advance.
Best Regards,
Fung

Hi,
Probably because of timeout, it is unable to execute the request ..so it is aborted.
btw, is it a synchronous call ? what is the message size ? the given data to RFC is correct and valid structure ? check the mapping .for this use the data from SXMB_MONI and test it
Check this blog for timeout errors-
/people/michal.krawczyk2/blog/2006/06/08/xi-timeouts-timeouts-timeouts
Regards,
moorthy

Unable to differentiate between RFC and BAPI

Hi guys,
    Nowadays I am studying the above concepts:BAPI and RFC. But I am confused by the two.
So far I learnt that the two are both techniques used to realize communication between SAP and external
systems,and frequently via Remote-enabled Function.
   My confusion is the distinctions between the two. Would you please do me a favor? Tks

Hi   Alex,
Just check it out these answers.
Remote Function Call :
RFC is an SAP interface protocol. Based on CPI-C, it considerably simplifies the programming of communication processes between systems.
RFCs enable you to call and execute predefined functions in a remote system - or even in the same system.
RFCs manage the communication process, parameter transfer and error handling.
http://help.sap.com/saphelp_47x200/helpdata/en/22/042860488911d189490000e829fbbd/frameset.htm.
BAPI
BAPI stands for Business API(Application Program Interface).
A BAPI is remotely enabled function module
ie it can be invoked from remote programs like standalone JAVA programs, web interface etc..
You can make your function module remotely enabled in attributes of Function module but
A BAPI are standard SAP function modules provided by SAP for remote access.
Also they are part of Businees Objest Repository(BOR).
BAPI are RFC enabled function modules. the difference between RFc and BAPI are business objects.
You create business objects and those are then registered in your BOR (Business Object Repository)
which can be accessed outside the SAP system by using some other applications (Non-SAP) such as VB or JAVA.
In this case u only specify the business object and its method from external system
in BAPI there is no direct system call. while RFC are direct system call.
Some BAPIs provide basic functions and can be used for most SAP business object types.
These BAPIs should be implemented the same for all business object types.
Standardized BAPIs are easier to use and prevent users having to deal with a number of different BAPIs.
Whenever possible, a standardized BAPI must be used in preference to an individual BAPI.
another points,
BAPI is object oriented. It is placed under Business objects as methods.
RFC is just a Function module or a call.
RFC: is just a FM that can be called from remote system too(destination defined in transaction SM59).
BAPI: Business Application Programming Interface
A BAPI is a method of a business object defined in the Business Object Repository (BOR). For example, in the BOR, you can find a business object called SalesOrder, which conceptually represents a sales order in the system. A business object typically has several methods that can be used to read, create, modify a particular instance of the business object, or list instances of the business object matching certain selection criteria. These methods are BAPIs.
Technically, a BAPI is implemented using a RFM. But, unlike the non-BAPI RFMs, a BAPI is usually well documented, has nicer parameter names, and is supported by SAP for several SAP software releases. You can browse Business objects and BAPIs in the SAP system using transaction BAPI.
Thanks
Eshwar
*Rewards if useful*

Diffrence between RFC & BAPI

hi good morning all ,
please tell me the exact diffrence between RFC & BAPI .
thanks in advance .
regards ,
srinivas

Hi,
1)BAPI are RFC enabled function modules. the difference between RFc and BAPI
are business objects. You create business objects and those are then
registered in your BOR (Business Object Repository) which can be accessed
outside the SAP system by using some other applications (Non-SAP) such as VB
or JAVA. in this case u only specify the business object and its method from
external system in BAPI there is no direct system call. while RFC are direct
system call Some BAPIs provide basic functions and can be used for most SAP
business object types. These BAPIs should be implemented the same for all
business object types. Standardized BAPIs are easier to use and prevent
users having to deal with a number of different BAPIs. Whenever possible, a
standardized BAPI must be used in preference to an individual BAPI.
The following standardized BAPIs are provided:
Reading instances of SAP business objects
GetList ( ) With the BAPI GetList you can select a range of object key
values, for example, company codes and material numbers.
The BAPI GetList() is a class method.
GetDetail() With the BAPI GetDetail() the details of an instance of a
business object type are retrieved and returned to the calling program. The
instance is identified via its key. The BAPI GetDetail() is an instance
method. BAPIs that can create, change or delete instances of a business
object type
The following BAPIs of the same object type have to be programmed so that
they can be called several times within one transaction. For example, if,
after sales order 1 has been created, a second sales order 2 is created in
the same transaction, the second BAPI call must not affect the consistency
of the sales order 2. After completing the transaction with a COMMIT WORK,
both the orders are saved consistently in the database.
Create( ) and CreateFromData! ( )
The BAPIs Create() and CreateFromData() create an instance of an SAP
business object type, for example, a purchase order. These BAPIs are class
methods.
Change( )
The BAPI Change() changes an existing instance of an SAP business object
type, for example, a purchase order. The BAPI Change () is an instance
method.
Delete( ) and Undelete( ) The BAPI Delete() deletes an instance of an SAP
business object type from the database or sets a deletion flag.
The BAPI Undelete() removes a deletion flag. These BAPIs are instance
methods.
Cancel ( ) Unlike the BAPI Delete(), the BAPI Cancel() cancels an instance
of a business object type. The instance to be cancelled remains in the
database and an additional instance is created and this is the one that is
actually canceled. The Cancel() BAPI is an instance method.
Add ( ) and Remove ( ) The BAPI Add adds a
subobject to an existing object inst! ance and the BAPI and
Remove removes a subobject from an object instance. These BAPIs
are instance methods.
2) No it is not possible to connect SAP to Non-SAP systems to retrieve data
using RFC alone. RFC can acces the SAP from outside only through BAPI and
same is for vice versa access.
3) Each Bapi Object has Interface, Key Fields, Attributes,Methods and
Events.
Bapi Function Modules can be attached to these Bapi objects .Function module
has a single bound functionality while a BAPI object can contain many
functionalities
Rgds
Yogesh

Sun*MS body rewriting -- relay implementation per RFCs

I read and understand RFC 2821 to mean that relays should generally try to leave messages alone. To quote just one section of the RFC...
   A 'relay' SMTP system (usually referred to just as a 'relay') receives
   mail from an SMTP client and transmits it, without modification to
   the message data other than adding trace information, to another SMTP
   server fo r further relaying or fo r delivery.There are 76 character length references in RFC2045, but that refers to the encoded body lines and not headers/boundaries nor SMTP.
S1MS rewrites From: lines, message boundaries?, and wraps longish lines (76?). Most of the time, this rewriting is unnecessary and IMHO violates RFC2821 (and RFC2045 is not relevant, reread) and does nothing except involve more work and no doubt reduce throughput.
I can understand the option to rewrite long lines if they are exceptionally long (1000 characters per RFC), but S1MS seems to break all lines longer than 76 characters. I can understand rewriting local From: addresses if needed, but it seems to rewrites all From: lines remote or otherwise. I've also noticed different S1MS sometimes also rewrite Content boundaries as "Boundary_(ID_blah)". I'm wondering what exactly is rewritten, controlled by what options, and under what circumstances? Why the extra work? Because any subsequent smtp server will still need to parse everything anyways, I don't appreciate all the work and don't understand why it is done.
The crux of this was a recent incident where an 83 character attachment filename was wrapped across two lines causing problems with third party software (it has been fixed, but we both looked at RFCs and I felt S*MS was in the wrong on two counts).
Despite this particular incident, I've long had other reservations (delays, truncated messages) along with the how/why modifications. The end result obfuscates spam with each line that is modified (or corrected, dates inserted, etc).
I looked through this message base looking for other posts perhaps related to this and nothing stuck out. It seems from the messages I saw that S*MS only bothers with the exceptionally long 1000 character lines so I'm now wondering what is exactly is responsible for changing the Content Boundary and wrongly wrapping all lines longer than 76 lines which I see time and time again on many different S*MS systems.

Authoratative answers:
The customer is correct that the MTA will under a number of circumstances
rewrite boundary markers, force wrapping of "long" lines, etc. In general, we
process all outermost header lines coming through the MTA, and may well process
inner header lines as well.
We are fully aware of the RFC 2821 wording regarding relay SMTP machines
"leaving messages alone". The problem is that in our experience, that does
not in fact work well. There are NUMEROUS, NUMEROUS message problems that
our MTA "fixes up", without customers ever having been aware of there having
been a problem in the first place. The sorts of problem we used to encounter
tended to be with messages gatewayed in from non-Internet environments; I consider
nowadays the problems tend to be more with messages submitted from "light weight",
and unfortunately sloppy, e-mail clients. (The MTA does in fact have a configurable
approach for "leave relayed messages entirely alone". We've left it undocumented,
and so far continue to leave it undocumented, and beyond strongly discouraging use
of it don't even talk about it with customers, because in real life, it tends to
not work well.)
Customers, being unaware of how much is getting "fixed up", tend to think that
things would be "better" if we'd "just leave the messages alone". Or rather,
what customers really want is "fix up (a), (b), and (c) problems, but leave
(d) alone, except when it's coming from (e) or going to (f), or except on
every other Thursday when the moon is full..." blah, blah. In other words,
customers want to have their cake and eat it too, when it comes to message
"fix up". Our overwhelming experience is that our fix up is overall
beneficial -- and that the supposed "downsides" of message fixup are mostly
bogus: that inherent processing that customers do in fact want gets you so
far down the road of message processing that the supposed "extra" overhead
is not in fact "extra" because it's already had to be incurred, and that
most of the supposed "problems" of the fixup are due to broken other
e-mail software that's not correctly handling the correct message forms
(and that for every one case of broken software that's stumbling on the
corrected message form, there were NUMEROUS cases of which the customer
was blissfully unaware where our correction of the message form improved
interoperability). Also, the MTA has numerous configuration "knobs" that
can affect exactly what we emit, so even when the real problem is a bug
(lack of standards-compliance) on the remote side, it's often possible
to configure something on the MTA side to emit a form that the broken
remote side will be able to handle.
Now it is true that we try to avoid any more processing than necessary
-- but the fact is that there are extremely many cases, triggered by a
wide variety of original message factors and configuration choices, where
processing is necessary.
As regards line folding: Please refer the customer to section 2.1.1
Line Length Limits, of RFC 2822, in particular the second sentence:
Each line of characters MUST be no more than 998 characters and
SHOULD be no more than 78 characters, excluding the CRLF.
Also see 3.5 Overall message syntax, in particular the second sentence:
Lines in a message MUST be a maximum of 998 characters
excluding the CRLF, but it is RECOMMENDED that lines be limited to 78
characters excluding the CRLF.
The MTA's default is therefore to fold header lines at 80 characters,
though this is configurable via the headerlinelength channel keyword
(or individually for individual header lines via header trimming
and the LINELENGTH header trimming option).
Now as regards clients not being able to correctly handle the
correctly wrapped header lines -- well, that I can certainly
believe since correct implementation of header line unfolding
rules (especially when combined with use of RFC 2047 encoded-words
in header lines) seems to be an area where client implementations are
WOEFULLY poor. It is really very irritating: the standards exist
exactly so that data can be preserved, and the clients just get this
area so wrong.
(And by the way, it is legal to wrap within quoted-strings.)
As for message bodies line wrapping -- that is controlled by factors
such as whether the contents had to be encoded with an encoding (such
as QUOTED-PRINTABLE or BASE64) that requires also keeping the lines
short, and note that such encoding can be triggered by use of the
linelength channel keyword. But lacking a need, body lines can
normally be up to the 998 legal limit and the MTA won't be folding
them. If the customer thinks they are seeing something different,
then I would want to see lots of details.
As for what can trigger the MTA to use its own boundary markers:
that would be anything that triggers MIME processing, including
(a) routing through the conversion channel, (b) use of the "thurman"
keyword, (c) application of a CHARSET-CONVERSION, (d) incoming
raw (illegal) 8 bit data, (e) the "inner" keyword, etc., etc.
They're all useful, and typically needed by customers at-some
-time-or-another, for-some-purpose-or-another, sorts of features,
that inherently require that the MTA do MIME processing, at which
point we redo the boundary markers.
Oh, other comments: Yes, the MTA does reorder all the headers.
We output them in an order that the MTA considers default, though
that order is extremely configurable: see header trimming and
the PRECEDENCE header trimming option. And yes, we change
the case on header line names; although the names are per the
standards case-insensitive, we have encountered quite a few cases
of broken software that (incorrectly) expects a particular case,
so what we emit tends towards the "seems to be most interoperable"
case. And that also can be configured, via header trimming and
the RELABEL header trimming option.
Anyhow, Jay, it's perhaps unfair to just dump this information on
you, but I'm not certain I have the patience at the moment
to go through all the questions the customer raised one by one and
point out how each one is either: (a) possibly interesting (e.g.,
supposedly "lost" e-mail) though we'd have to get lots of details
(since as I think you wrote, it's pretty dubious that the messages
were actually lost by the MTA), or (b) the customer is wrong in
their understanding of the RFCs, or (c) the customer is dealing
with standards-incompliant other software, or (d) explain
exactly why the MTA does what it does, or etc...Each question
probably ought to be dealt with as a separate question. The
customer appears to have lumped a bunch of (from my point of view)
separate issues together and decided that "MTA processing of messages
is bad -- the MTA should be leaving the messages alone". I completely
disagree with their conclusion, although many of the details that the
customer has observed are correct -- but it's probably going to take
discussion of each issue individually to enlighten the customer.
and
(Basic complaint) .. . ... almost entirely at odds with reality. For starters, he begins by assuming
we operate as a relay. We don't and have never claimed to. As such, any
restrictions that apply to "relays" don't apply to us. So the argument that
we're incompliant with the relevant RFCs is completely specious.
The role of iMS fills is closest to what the RFCs call a "gateway", although in
practice few sites these days take advantage of the full gateway functionality
we provide. But by the same token, most sites find at least some of the various
operations we perform on messages useful and don't disable them (although most
of them can in fact be disabled). So in practice most sites operate something
that falls between a "relay" and "gateway". (There's also the issue of the
specific operations a submission server is supposed to perform but I don't want
to get into that here.)
He goes on to argue that the various processing steps we perform on messages
are unnecessary and/or result in unacceptable loss of performance. Wrong on
both counts. Everything we do is done because there's been a demonstrable need
for it. We don't spend time implementing stuff nobody wants. Indeed, a lot of
people find many of the operations we perform to be essential and purchase our
product because it has rewriting and message alteration capabilities lacking in
other messaging servers. As for performance, we have one of the fastest MTAs
around. I'd say that pretty much proves the performance impact is negligable.
A specific point of complaint is that we change boundary markers. The reason for
this is simple: When performing MIME processing the only way to do it correctly
in a single pass is to randomize the boundary markers. (I'll leave it as an
exercise to the reader to figure out why if you're so inclined.) In any case,
I see no evidence that there is anything wrong in our boundary handling.
He then starts complaining about header wrapping and reorderng. Header
wrapping and rewrapping is (a) Entirely legal and (b) Wrapping at 80 columns
or less is strongly encouraged by the relevant RFCs.
This brings me to the one point he makes that I think is somewhat valid: Header
reordering. We're RFC compliant here as well: If you read the relevant RFCs
you'll find that reordering of trace (Received:) fields is forbidden and
certain headers are required to be prepended, but aside from that pretty much
anything goes. We conform to all this but I don't think the RFCs are stringent
enough in this area. Accordingly, changes have been made for JES 5 that will
result in our preserving header order by default. (Obviously this all goes
out the window if you explicit request header reordering of some sort.)
One final point. Much of the behavior he doesn't like can easily be disabled in
iMS. If all this stuff is really so abhorrent, you'd think we'd see the
majority of sites turning it off. But what we see in practice is exactly the
opposite: Not only do sites not disable this stuff, they spend a considerable
amount of time yoeling and howling about we don't do enough of these things.
The addition of disclaimers is an excellent example of this: We don't think
this is a good idea and try to discourage it, but our customers seem not to
agree...

Program making a RFC call to Function Module not working in background

Hi All,
I have an ABAP Program which is used to do a reconciliation check between the R/3 and BI system for Invoice Data. Please find below the details of the program flow:
1.     Program counts the number of records in the DSO table and aggregates the Net_Value based on the date range (passed as parameters)
2.     Program calls a Function Module (RFC Call) which counts the number of records in the R/3 table and aggregates the Net_Value for the same date range
3.     Function Module Passes back the count values and aggregated Net_Value to the program
4.     Program compares the count and aggregated Net_Value from EDWH and MSP systems and sends an email mentioning whether the counts match or not
However we are facing an issue.
Whenever, we execute the program in dialog mode, it works fine and fetches results within 5-6 minutes. However if we schedule the program to run in background (parameters through a variant), it gives no results even after running for over 3-4 hours. We tried figuring it out yesterday but could not come to any conclusion. Since there is a RFC call being to the function module, we were wondering if we need to specify some other parameter as well.
Thanks & Regards
Dharmendra

RFC Call is a procedure for executing remote enables function modules. It is done via the 'Remote Enabled' radio button on the function module's attribute screen.

LUW implementation between RFC calls

Similar Messages

Maybe you are looking for