CL_DOCUMENT_BCS - DOCNO protected or public

Hi,
SAP Version : mySAP ERP 2005 - SAP ECC 6.0
In class CL_DOCUMENT_BCS it says DOCNO is PUBLIC - READONLY - PERSISTENT - INSTANCE ATTRIBUTE.
Visibility for DOCNO is <i>public</i> but when I try to debug it says visibility is <i>protected</i>. SO strange.
However, when I try to access docno after I instantiate an object, it says DOCNO is protected. Has anyone faced this issue ?
data: lv_subject type SO_OBJ_DES.
data: lv_document TYPE REF TO cl_document_bcs.
lv_subject = 'Hello World'.
*Create the document here
      lv_document = cl_document_bcs=>create_document(
                          i_type    = 'RAW'
                          i_subject = lv_subject ).
write : lv_document->docno.
Regards,
Subramanian V.
Message was edited by:
        Subramanian Venkateswaran

Hi ,
Try Using GET_DOCNO method.
Attributes can be read using Get Methods only in Persistence Classes I Hope.

Similar Messages

Making specific folders password protected in Public folder

If I have two subfolders in the Public folder of my iDisk - each containing images for a different person - can I specify a different password for each folder?
Thanks

You cannot password protect an ordinary folder. A "disk image" is a special kind of folder that you CAN password protect; on the desktop that 'folder' has the icon of a volume because it actually is a temporary volume. Use Disk Utility to create as many such disk images as you need, each with its own password, and each with a meaningful name ("JonsPics", "stuffforMary", whatever) so that you don't get confused. Put the appropriate files into each disk image and give the appropriate people the password they will need.
Where you then put those disk images (files with suffix .dmg or .sparseimage), on an iDisk or anywhere else, is immaterial.
Try an experiment. Use Disk Utility to create a disk image (with encryption) on, say, your desktop. Drag some files into the temporary volume that has appeared (the 'folder'). Now unmount the temporary volume via a Finder window's sidebar 'eject' symbol or by dragging the volume to the trash - (which is equivalent to closing the folder). You will have a xxx.dmg or a xxx.sparseimage file on your desktop: it contains your files, but hidden from prying eyes - double-click it - it will ask for a password... Those .dmg (or .sparseimage) files are what you will upload to your iDisk.
You can mount a volume from a .dmg or .sparseimage file as often as you like - just as you can open a folder as often as you like -- but with these kind of "folders", once you have closed/unmounted them, you will only be able to remount/reopen them with the correct password.
Don't lose a password - Disk Utility warns you that without it you will be unable to access your files... which is exactly what you have been asking how to do!
Do try it -- you will find it a lot simpler than trying to follow my explanation!
Andreas

Protected and public access modifier - exact difference

Hi everybody,
Please help me to give an exact difference between protected access modifier and public
Protected: Classes with in the same package as well as subclasses can access.
Public : Classes outside the current class can access while declaring public.
My doubt is that what is the practical difference between public and protected.
I searched the net , but the information was not satisfactory to solve my confusion.
Thanks & regards
Parvathy

Obviously doubt = lacks the ability to think for
oneself.When one person raises a doubt, that does n't mean that he lacks the ability to think . He/She might have thought about it and if he didnt get a proper clarification then it will be posted in the forum.
In such cases please dont discourage others who are ready to answer the subject.Without knowing the actual intention , i request you please dont reply like this

IPad protection on public wireless network?

Is there any protection on iPad to prevent someone from accessing my data on a public wireless network? I know not to enter a credit card number in public, but what about the email password that is already saved there?

On an open wireless network, anyone on that network can capture the network traffic and see any clear-text data. Your e-mail password is safe IF you've got things set up to connect via SSL. Go to Settings -> Mail, Contacts, Calendars, then select the account. Edit the account, tap the Advanced button, and make sure Use SSL is turned on.
That protects your password, but note that the contents of any messages you send and receive are, and always have been, plain text send in the clear. So don't send anything sensitive via e-mail. That's good advice in general, but especially relevant on an open wireless network.
Beyond that, nobody can remotely hack your iPad and get access to the data on it. It's just the data you're sending and receiving you've got to worry about it.

Exchange Online Protection and Public Folders

Hi,
We have just been migrated to Exchange Online Protection from FOPE and although users can now manage their own quarantines, they cannot do this for Mail Enabled Public Folders. Is this possible?
Many Thanks

Hi Paul,
I replied to a post from you in another thread. It's easy to miss though, so here's what I said:
"You should tell mail2web that there is an option in Exchange to hide public folders from IMAP clients. I'm an IT manager at a large software company with 50% of our users on Macs. We turned on the option to hide public folders from IMAP clients a while ago, long before the iPhone. It's worked very well and continues to work for iPhone people (like me!).
There was no reason for us to make public folders viewable via IMAP, so hopefully the same will be true for mail2web."
I'm actually really glad that Apple made this change. I want to see most of the folders at the inbox level in Exchange and with the Exchange switch turned on to hide public folders, there's no downside.
Regards,
fh

What is the difference between Public and Protected Attributes

hi ppl,
         what is the difference if i declare attributes under public or protected to access the private method.for both (public or private) section iam getting the same result.
CLASS CL DEFINITION.
*protected section.
public section.
DATA: M TYPE I VALUE 100.
private SECTION.
METHODS: FREE.
ENDCLASS.
CLASS CL IMPLEMENTATION.
   METHOD: FREE.
     WRITE:/ M.
     ENDMETHOD.
ENDCLASS.
CLASS CL1 DEFINITION INHERITING FROM CL.
public section.
METHODS: FREE1.
ENDCLASS.
CLASS CL1 IMPLEMENTATION.
     METHOD: FREE1.
     WRITE:/ M.
     ENDMETHOD.
ENDCLASS.
DATA: OBJ TYPE REF TO CL1.
START-OF-SELECTION.
CREATE OBJECT : OBJ.
END-OF-SELECTION.
CALL METHOD: OBJ->FREE1.
Please use meaningful subject in future questions and Post in correct forum*
Please learn to use tags around your ABAP
Edited by: Vijay Babu Dudla on Dec 1, 2008 12:37 AM
Edited by: Matt on Dec 1, 2008 4:16 PM

hi,
    Iam really soory people..It wont repeat again.pls guide me in this regard
hi ppl,
what is the difference if i declare attributes under public or protected to access the private method.for both (public or private) section iam getting the same result.
CLASS CL DEFINITION.
*protected section.
public section.
DATA: M TYPE I VALUE 100.
private SECTION.
METHODS: FREE.
ENDCLASS.
CLASS CL IMPLEMENTATION.
METHOD: FREE.
WRITE:/ M.
ENDMETHOD.
ENDCLASS.
CLASS CL1 DEFINITION INHERITING FROM CL.
public section.
METHODS: FREE1.
ENDCLASS.
CLASS CL1 IMPLEMENTATION.
METHOD: FREE1.
WRITE:/ M.
ENDMETHOD.
ENDCLASS.
DATA: OBJ TYPE REF TO CL1.
START-OF-SELECTION.
CREATE OBJECT : OBJ.
END-OF-SELECTION.
CALL METHOD: OBJ->FREE1.
Edited by: Matt on Dec 1, 2008 4:18 PM

Override protected method as public

I am new to Java.
My doubt is :
I have a class named Base having one protected method(let's say x()) and another class named Derived which extends Base.
Now i want to override method x() of the Base class. Here I have 2 option either use access modifier as protected or public.
As per my understanding, i can override this method only with exact signature. But I can use Public as well. And here i am getting confused why we can.
Eg. In Object class we have method clone() which is protected, and to get cloned object of my class i need to override this method either with protected modifier or as public.
If I override as public then whats the use of protected method, why its not defined as public.
Please clear me the concept.

cool_kkin wrote:
As per my understanding, i can override this method only with exact signature. But I can use Public as well. And here i am getting confused why we can.Yes widening the scope is fine because the method still exists in the same nature as the method in the superclass. However narrowing the scope will hide for instance throw able exceptions from the caller, break polymorphism, conflict with the intension's of the class from the author and a whole wealth of other problems.
If I override as public then whats the use of protected method, why its not defined as public. Not every class is sub classed, therefore the protected declaration acts as it should. The final declaration can also be used in conjunction with protected, making subclasses unable to widen the scope of protected, or even override the method to begin with.
Mel

Public and protected properties

Hi, I would like to know if it is possible to dynamically
list the protected and public properties and methods of a class
during runtime. Any help would be greatly appreciated

Well, I'm not really sure if describeType() shows protected
properties but public properties for sure:
http://livedocs.adobe.com/flex/3/html/help.html?content=usingas_8.html
http://blog.flexexamples.com/2007/12/09/debugging-flex-applications-using-the-describetype -method-and-the-objectutil-class/

Users could not open Public Folders in Outlook 2007 SP3.

Is anybody had this issue or probably know how to fix it?
We have Exchange 2013 server and users workstations with XP SP3 and Office 2007 SP3 installed. Exchange has users’ mailboxes and public folders. Public folders work OK until last week. Issue probably happened after latest CU update for Exchange 2013 installation.
Now users could not open Public Folders in their Outlook. The error is:
"Cannot expand the folder. Your profile is not configured. (/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=[email protected])"
And this "[email protected]" is public folder ContentMailboxGuid.
And this error message appears when user click on Public Folders \All Public Folders in Outlook. So company public folders do not even appear in All Public Folders folder. Users have Owner permissions for all Public Folders and Root Public folders.
Also one more error in Outlook about it:
“Cannot display the folder. Microsoft Office Outlook cannot access the specified folder location.”
One more issue is that previous Exchange 2007 server died (RAID died) so we had to delete it from AD and clean its records in ADSIEdit (CN=configuration,DC=.domainname,DC=.COM > CN=Services > CN=Microsoft Exchange > CN=Organization > CN= Administrative
Groups > CN=(Groupname) > CN=Servers >) and install new server with Exchange 2013, and import all users mailboxes from backup. Public folders were not migrated from the old server because of its death. We create new public folders in Exchange and
then manually import all folders from latest .pst backup using user Outlook.
And it work OK more than a month till last week.
Thanks,
Andrey

Hi Mavis,
Thank you for your answer.
I check permissions couple of times for both public folder and its root and both are granted for users as “Owner” and applied to public folder and its subfolders.
This server has 2 mailbox stores and both are currently mounted.
[PS] C:\Windows\system32>Get-MailboxDatabase -Status |fl name,mounted
Name    : Mailbox Database 2104233799
Mounted : True
Name    : MBDB1
Mounted : True
But when I check homeMDB property for Microsoft System Attendant in ADSIEdit I found that it is empty.
And it looks like System Attendant mailbox & service have been removed from Exchange 2013.
http://howexchangeworks.com/2013/05/cannot-open-microsoft-system-attendant-mailbox-error-during-exchange-2013-mailbox-move.html
and even from Exchange 2010.
http://blogs.msdn.com/b/dvespa/archive/2009/10/06/say-so-long-to-the-system-attendant-mailbox.aspx
Also I check arbitration mailboxes and all are looks to be in default database “Mailbox Database 2104233799” which is currently mounted.
[PS] C:\Windows\system32>Get-Mailbox -Arbitration |fl name,data*
Name     : FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042
Database : Mailbox Database 2104233799
Name     : SystemMailbox{1f05a927-77cc-4f5d-b5ca-667ea4256ff9}
Database : Mailbox Database 2104233799
Name     : SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}
Database : Mailbox Database 2104233799
Name     : SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}
Database : Mailbox Database 2104233799
Name     : Migration.8f3e7716-2011-43e4-96b1-aba62d229136
Database : Mailbox Database 2104233799
Thanks,
Andrey

Inheritance and access control - "private protected"

I'm reopening an old topic, seems to have been last discussed here 2-3 years ago.
It concerns the concept of restricting access to class members to itself, and its subclasses. This is what "protected" does in C++ and "private protected" did in early versions of the Java language. This feature was removed from Java with a motivation along the lines of not being "simple", and "linear" (in line with the other access modes, each being a true subset of the next). Unfortunately, the article which explained Sun's position on this keyword combination seems to have been removed from the site, so I haven't been able to read its original text.
But regardless of simplicity of implementation or explaining Java's access modifiers to newbies, I believe it is a fundamental part of OO programming for such an access mode to exist. The arguments for having the standard "private" mode in fact also apply for having a C++-style "protected" mode. (Arguing that classes within a package are related and it therefore doesn't hurt to also give them access to Java's "protected" members, is equally arguing that "private" is unneccessary, which noone of course believes.)
The whole concept of inheritance and polymorphism and encapsulation builds on the access modes private, protected, and public (in the C++ senses). In Java the "package" concept was added - a nice feature! But I see no justification for it to negate the proper encapsulation of a class and its specializations.

What effect upon inheritance other than hiding members
from subclasses is there?
None. And I cant think of another declaration that prevents members from being inherited but private.
Of course the onus comes on the programmer with Java's
definition of "protected" - but
1) there is rarely a single programmer working within
a package
The point was the package is a unit which does not hide from itself. Just like all methods within a class can see each other, all classes within a package can, and all packages within a program can.
2) it muddies the encapsulation in the design - when
you see a "protected" method someone else, or yourself
some time ago - wrote, how do you know if the design
intention is to have it accessed solely by the class
and its subclasses, or if it is indeed intended to be
shared with the whole package? The only way to do
this today is to always explicitly specify this in the
comments, which may be lacking, inconsistent, and
abused (since it isn't enforced).Encapsulation would be implementation hiding. Not method hiding. The only thing you should probably allow out of your package is an interface and a factory anyway.
I understand where you are coming from, but I really have not had occasion to take issue with it. I can't think of a real codeing situation where this is required. OTOH, I can't think of a coding situation where I need to access a protected method from another class either.

Private vs. protected, naming conventions etc.

I've been grappling with a couple of frustrations with Forte, and I'm
interested in feedback from others on this list regarding approaches
they may have adopted to address these.
One is that in the Forte workshops there is no way to view only the
public methods and attributes of a class (we're still using V2 here; I'm
assuming that V3 has not changed this). While referring to appropriate
technical documentation for a class is obviously important, I still find
myself opening up classes in the workshops to inspect the methods and
attributes available. (What I really want to see is an integrated class
browser. I sure hope Forte is working on something like this, or will
open up their development environment to support third-party extensions.
But that's an aside.)
A convention I just recently adopted in my work is to name private
methods and attributes with a beginning underscore ("_"). That way the
private elements are sorted to the top of the list and can be easily
differentiated from public elements. I'm curious, though, whether others
have adopted similar or different approaches.
I've also felt a bit frustrated over the lack of support for protected
attributes/methods for TOOL classes. This strikes me as a rather
bothersome shortcoming. The only approach I can think of is to make such
elements public, but adopt the same or similar naming conventions as a
strong hint to developers to avoid using these in clients of these
classes. Again, I'd be very interested in hearing how others have dealt
with this issue.
Thanks.
Michael Brennan
Programmer/Analyst
Amgen Inc.

I sent this once before, but the list seemed to be having trouble late last
week. If you get two copies of it... my apologies.
OK, I couldn't resist joining the fray...
At 10:56 AM 11/6/97 -0800, Michael Brennan wrote:
>
A convention I just recently adopted in my work is to name private
methods and attributes with a beginning underscore ("_"). That way the
private elements are sorted to the top of the list and can be easily
differentiated from public elements. I'm curious, though, whether others
have adopted similar or different approaches.You might even designate a single character before the underscore to denote
that, just in case some environment (CORBA) doesn't like the "_". You could
make it something like "Q" or "Z" or something that wouldn't normally be
used alone at the start of a name.
>
I've also felt a bit frustrated over the lack of support for protected
attributes/methods for TOOL classes. This strikes me as a rather
bothersome shortcoming. The only approach I can think of is to make such
elements public, but adopt the same or similar naming conventions as a
strong hint to developers to avoid using these in clients of these
classes. I share your desire for protected methods, but I have to disagree about
protected attributes. Philosophically speaking, protected and public
attributes are EVIL!! (I say "philosophically speaking" because, in the
Forte environment, there are some valid reasons for using them based upon
the visibility constraints of the language. In other languages, C++ and
Java, for example, it's not even philosophically speaking - they're just
evil!!)
One of the principal reasons for adopting the object paradigm is to
tightly control the impact of change - to provide good boundaries of
encapsulation that change does not ripple beyond. If you think about it,
one of the measures of the success of a superclass is the number of
subclasses that it has (especially for a good dabstract interface). This
says you have very nicely captured the semantics of the application domain
in the interface of the superclass. So, let's imagine a superclass with
protected attributes that are used by each of its 100 subclasses (probably
more than you would have, but I'm illustrating my point - incidentally, I'm
not talking about a hierarchy 100 deep; I'm talking about 100 subclasses
that are all direct decendants of the superclass). Now you go and change
one of the attributes. You must go look at all 100 subclasses to determine
the impact of change. This is exactly the kind of thing the object paradigm
was designed to eliminate.
Protected methods, on the other hand, would be nice.
And At 12:06 PM 11/6/97 -0800, Mark S. Potts wrote:
>
Forte inherits in a strange way when attributes are private. A
superclass attribute that is made private is not accessible from any of
its subclasses - this means that many of what you would consider private
attributes in fact have to be public. Well, the definition of private means "not visible outside of the class
where it is defined". I find it useful to think of the level of visibility
the same as secrets. There are things that are not really secrets at all -
it's ok if anyone knows them ("My name is Stephen"). These are public.
Then, there are things that it's ok if my family knows, but I don't want
the world to know - familial secrets, if you will ("I belch at the dinner
table when I'm at home"). These are visible to descendant classes and we
call them protected. Finally, there are things we don't want anyone else
to know, no matter who they are ("I poisoned my mother-in-law"). These are
private. We don't want anyone outside of ourselves to know these things.
These are the classic definitions of public, protected and private (perhaps
classic only because C++ defined them that way and everyone else just
copied what it meant).
Private attributes are not meant to be inherited by their subclasses.
That's why they're private. And, yes, I would argue that that is completely
correct. What you want, if you want them to be visible to subclasses, is
"protected". Now, Forte doesn't support protected, but that's a different
arguement - perhaps even an enhancement request.
We also should not confuse what we need to do in a language/environment
with what good OO principles are. For example, good OO design principles
state that you do not have public or protected attributes. Period! You
access them via accessors and mutators defined on the appropriate class.
Now, in some environments, this will not give you the performance you need,
so you open things up a bit. But, you shouldn't convince yourself that
doing this is the ideal design, just that it was necessary for performance.
The real problem here is that the performance of accessor and mutator
functions is not fast enough. That's why we open it up. Not because it is
good design. The proper way to fix the problem is to make accessors and
mutators fast enough so that they can be used (C++, for example, does this
with "inline" - not that C++ is my favorite language, it's not. But they
have fixed this one area nicely.)
Some would argue that this is correct and that inheritance does break thepure rules
of encapsulation I don't think inheritance, properly handled (and Forte does properly
handle it) breaks any rules of encapsulation. I would argure that the way
they treat private attributes is quite correct.
- but these people dont build applications!Hmmm... let's see... started building OO applications in 1985 (and building
them ever since) in complex application domains like CAD/CAM/CAE, Air
Traffic Control, Graphics/Imaging, Telecommunications, e-commerce,
entertainment,... ...wrote (and teach) the Forte OO Analysis and Design
course.
I guess you're right. I don't build applications. I build robust,
maintainable, extendable applications. ( ;-) ...nudge, nudge!)
Stephen

Protected methods not so protected

Hi,
I thought that a protected method could be called only by the methods of
the same class or the methods of a descendant class.
So I have been a bit surprised when I constated that a class
of a given package can access the protected method of all the classes in the same package !! I thought that this behaviour was reserved to the method with no access modifiers.
Example :
package mypackage;
* A first class with a protected method
public class HasProtectedMethod {
protected void iAmProtected() {
System.out.print("I am protected");
* Another class in the same package trying to access the protected
* method of the first class
package com.akazi.flowmind.modeling.gui;
import com.akazi.flowmind.modeling.gui.dialog.HasProtectedMethod;
public class Test {
static public void main(String[] args) {
new Test().callProtected();
public void callProtected() {
HasProtectedMethod method = new HasProtectedMethod();
method.iAmProtected();
This code is perfectly compiling and running under JBuilder6 and I wonder if this is correct...

This is very odd to me.
In my application, I've got a bunch of classes with subclasses, and I want the protected methods to be accessible only to the subclasses, not to the rest of the stuff in the package.
Is there no way to keep these protected methods and member variables safe, other than to make a package for each superclass? That means that the client application I am writing will baloon from one package to around 46. Ugh.
So should I just give up on data hiding for now? Did I design this thing all wrong? Maybe we're supposed to use lots and lots of packages. What do people do?
--- Eric

A keyword for marking default protection

Today java is missing a keywork for marking default (package) protection. This is marked just by not using private, protected or public.
To me code with a explicit defined protection is easier to read than code where protection is defined by not using any keyword.
I think java should have a keyword for explicitly declaring the protection level.
I have searched bugs.sun.com for an issue about this, but didn't find any.
Does anybody here has any thoughts about this topic?
-Kaj :)
Edited by: kajh on Apr 19, 2008 12:50 PM

DrClap wrote:
An optional package-private keyword would be just another source of confusionThen don't tell anyone about it :). Those who wanted it will find out, one way or another.
I agree that I wish package-private had its own keyword, as I think it would make code more readable (a compiler preprocessor instruction forcing yourself to specify access level might be nice too). Personally, because there was no keyword for package-private, I spent the majority of my Java life thinking that the default (no keyword) was the same as "protected", because I assumed it had to be one of the three (public, protected or private). So from my experience anyway, not having a keyword is introducing a lot more confusion than adding one late in the game.
The biggest problem I'd see with the addition would be that they haven't reserved a suitable keyword, and introducing a new keyword will either 1. run the risk of breaking existing code (identifiers using keywords added late) or 2. increase parser complexity.
Could always use the default keyword in a separate context though:
public class Clazz {
default int myData;
}Or change the grammar rules for declarations:
public class Clazz {
package private int myData;
}

IDisk Public folder access

I'm attempting to give others browser access to my public folder. Everything works per the directions below except that the public folder password doesn't work. It's necessary to use my dot-Mac password to reach my public folder! Has anyone else seen this?
"Mac or Windows users who are not MobileMe members can access your iDisk by opening a web browser and entering: public.me.com/[YourMemberName], and if necessary, entering your Public folder password."

I have the exact problem mentioned above.
I have changed my System Preferences — MobileMe — iDisk — Your iDisk Public Folder — Password-protect your public folder PASSWORD to a NEW PASSWORD that is not my ACCOUNT PASSWORD and it won't take.
I have tried to access my public folder with the NEW PASSWORD but it only responds to my ACCOUNT PASSWORD.
I've reset it the password many times, restarted many times and have tried accessing the public folder through Safari and Firefox.
I'd prefer to have a separate password for my public folder.
Any suggestions?
Thanks.

Internal setter & public getter

Hi all,
I have two classes, both in the same package, one of which parses xml and adds a value to the second via an internal set method. This initially works fine but as soon as add a public get method to the second class I get an error (1059: Property is read-only).
The problem goes away if I make both methods public or internal but in this situation I would like to have one of each. Is this possible? I thought I had done this in the past without any problems but maybe not.
Cheers for any advice

Since there is no overloading in AS3, one cannot have any ambiguity in terms of name spaces. Accessors are treated as properties, so, as any property, it cannot be both protected and public. In your case solution, perhaps, is to make the variable accessors designed to handle protected (or internal), while getter - public (and no setter).

CL_DOCUMENT_BCS - DOCNO protected or public

Similar Messages

Maybe you are looking for