SAPscript SMARTFORMs

[Former Member]

Pls Explain...

How SAPscript is client dependent ??

and

How SMARTFORMS are client independent.??

How to prove it ???

Thanks

Raj

[Former Member]

Hi Raj,

Sap script was developed a long back.

Ssmartform is developed to avoid these type of some restrictions like client dependancy.

Client dependent means if you create that data in one client is limited to that client only and it is not accessable in other clientsLike SAP SCRIPTS and STD texts data

Where as Client Independent means the data if you create in one client that is available in that as well as in other clientsLike SMARTFORMS, All dictionary Objects data and Repository objects data like Programs, Fun modules, tables etc..

As for SAP -- Scripts are called client dependent because if you create client in say,200 it would be available in that only.If you want to test the script in client 300 then it won't be there,you will have to go to transaction se71 in 300 .Then Utilities-> Copy from client.Give the source as 200 & form name(i.e. script name) & copy.

SAPscript technology is based on a mainframe product from the 1980s.SAPscript forms have always been -- under the hood -- relatively passive objects, with minimal embedded logic. These forms were designed to be driven and controlled by ABAP programs, much in the way ABAP programs read in database tables to produce reports;

if you ever download a SAPscript form (e.g., via utility program RSTXSCRP), and look at the portable text file it produces you'll see what I mean.

Many text objects (e.g., invoice header texts) are bound directly to documents which are client-dependent, so it makes sense for these text objects to also be client-dependent. From a complexity standpoint, SAPscript forms are close enough to these text objects where I can see how it made sense at the time to make them client-dependent

SmartForms are Client Independent because when you activate them you are actually generating a Function Module. This means that the Print Programs actually call a FM instead of using the "OPEN_FORM", "WRITE_FORM" etc FM's that SAPscript use.

B'coz if we develop SAP Script in one client say for example in 100, & if we want to access it in other ciient say 110 , it won't be available . This is CLIENT DEPENDANT.

In case of smartforms, if we develop it in 100 client & if I want 2 access the same smartform in 110 , it wil be available. This is CLIENT INDEPENDANT.

Rewars points if helpfull.

Regards,

Kashyap

[Former Member]

SAPscript has always been with minimal embedded logic. These forms were designed to be driven and controlled by ABAP programs, much in the way ABAP programs read in database tables to produce reports; if you ever download a SAPscript form (e.g., via utility program RSTXSCRP), and look at the portable text file it produces you'll see what I mean. Many text objects (e.g., invoice header texts) are bound directly to documents which are client-dependent, so it makes sense for these text objects to also be client-dependent. From a complexity standpoint, SAPscript forms are close enough to these text objects where I can see how it made sense at the time to make them client-dependent too.

Smart Form is significantly more robust and complex. For instance, it can contain program nodes and nested tables with patterns. When a Smart Form is compiled, it generates an ABAP function module – and these are always client-independent. This is appropriate, given that this form has more in common with an ABAP program than its predecessor. For instance, when a print program calls a Smart Form, the form itself takes over to produce output, without any further direction from the print program. In fact, the join is so seamless that we often find using a Smart Form's Initialization section for logic to handle any data gathering not handled by the print program. I would never even think to attempt this with SAPscript.

Several factors figured into SAP's decision to make Smart Forms client-independent, including customer feedback. There are significant advantages to client-independence. For instance, a change made in one development client happens immediately across all development clients. Among other things, this means we don't have to waste time figuring which client contains the most recent version -- they all do! In addition, transporting Smart Forms is easier, since we can safely bundle them together in the same transport as their client-independent print programs (no worry about mixing client-dependent and independent objects).

Hope this Helps.

Vinodh Balakrishnan