OMBPLUS: retrieve type of operator?

Hello,
i have to determine via ombplus, if an operator is a table, aggregator, filter and so on.
For this, I'm looking for the key of that property. "OPERATOR_TYPE" is not the correct key and I don't know how to get a list of possible keys.
OMBRETRIEVE MAPPING '$vmapping_src' OPERATOR '$voperator' GET PROPERTIES (OPERATOR_TYPE)
OMB02918: Property...does not exist: MMM1034: Property OPERATOR_TYPE does not exist.
Tobias

I don't think you can do it like that. If you don't know the type of an operator he only way to determine this is to get the mapping operators by type and check if your operator is in the list for a specific type.
Jaap.

Similar Messages

RE: Polymorphism - retrieving type information from thedatabase or how

Don,
Ok but if I was to model a real restaurant, I would then have a head chef
that can then delegate to other chefs. This head chef would have the
additional task of coordinating the completion of subservient chefs. This
does not and would not mean that the head chef is stuck (or partitioned) in
one part of the kitchen. Further a head chef would most likely also be a
chef so that he would be running around the kitchen using and interacting
with different objects to get his part of the recipe completed. Then once
all chefs have completed their part of the recipe the head chef could return
the meal.
I would also point out that it does not make sense to me to be talking about
the chef and its ability to scale. I would look that the resource limited
devices that must be used to prepare meals to see scalability. In this case
the grill, the stove and the microwave. Scalability of the restaurant is a
function of the amount of resource limited devices versus the number of
process (i.e. chefs) that need to use those devices concurrently and the
amount of time they require access to those devices. By talking about chefs
as if they are the scalability limiting factor seems to bring us back to the
notion that the chef is a manager object that is shared. And again I come
back to the question, why?
You may now think that in a real restaurant, there are only so many chefs so
why not make it a shared service? Well in a real restaurant there are only
so many of any object, but this is not a consideration in our restaurant
model. In our "virtual" restaurant hiring a chef is as easy as:
Chef = new;
And of course chefs are of zero mass so there can be a whole lot in the
kitchen. Now assuming the Grill, Stove and Microwave map to physical
objects in our computing environment, then that is the limiting factor and
are therefore partitioned. Whenever communication has to go through a
single source, then scalability breaks down. I fear that too many people
make shared objects and create communication bottlenecks where they simply
don't exist. The only place your scalability bottlenecks should exist is in
the actual resource limited objects of your computing environment. Simply
said, if something isn't a resource limited object, then why is it shared?
If anyone is not clear how to architect an application independently of the
business model, then I would suggest looking at various framework products
and reading some technical architecture white papers to get a different, and
possibly enlightening, point of view.
Mark Perreira
Sage IT Partners.
-----Original Message-----
From: Don Nelson [mailto:[email protected]]
Sent: Wednesday, June 17, 1998 9:04 AM
To: Mark Perreira
Cc: [email protected]
Subject: RE: Polymorphism - retrieving type information from the
database
Mark,
First, I completely agree about the naming. I purposely used rather
euphamistic names for these "managers", since I see many convoluted names
for common things in various applications. But that is a topic for another
thread...
Simply because there is a "manager" of some type, does not imply that it is
chained to a particular duty. However, let's look at a real life case. In
a large restaurant, you would rarely see a chef chopping carrots or serving
dishes to customers. Those are the responsibilities of the sous-chef and
the waiter. So, we see that the chef does not really follow the food
around. Why not? Because it simply doesn't scale. When scalability isn't
a problem, (the restaurant isn't that popular, for example) the chef has
some lattitude to accept more responsibility, and might even get involved
with purchasing, etc.
In the real world, the more scalable something has to be, the narrower the
responsibilities are for each of the participating members.
Don
At 12:59 AM 6/17/98 -0700, Mark Perreira wrote:
Don,
One thing that always baffles me is when should an Object get the moniker
"Manager." This practice seems to tell me a couple of things about these
objects. In general when someone makes reference to a "Manager" objectthat
it is probably a service object and probably contains no or very little
attribution. The question is why? If I am developing an object model why
am I thinking about such implementation issues.
Surely if you are trying to model cooking an egg I would not see
"SustenancePreparationManager" in your model. Using a more common term I
would still be alarmed to see "CookManager" in your model. What does the
CookManager manage? Does it manage other cooks or eggs. Maybe it shouldbe
called an EggManager, but that doesn't make sense. How about just Cook.
There that seems like the real world. And this brings me to a problem in
the analogy. Conjuring up managers in a model can sometimes make you missa
container. For example, I would say that if we wanted to model the real
world, then eggs is a specialization of ingredient that is contained by
recipe that can be given to a cook to be prepared.
I may have many cooks (objects) that can prepare recipes and my application
architecture not the object model needs to deal with how to best let those
cooks utilize the grill, stove and microwave that sits on different
partitions on my server. My cooks can move around and when they do they
take their ability to know how to cook with them. In the real world Iwould
expect a cook to use the right appliance to prepare the recipe based on its
contents. I would not chain every cook to its appliance and them make me
responsible for giving the right cook the right recipe. This is what
managers can cause. They cause the consumer of cooks to know which cookcan
prepare what recipes based on where they are chained. This then makes me
know something about cooking. And if I don't know anything about cooking I
can only image what my egg would look like if I accidentally gave therecipe
to the cook stationed at the microwave.
Ok Ok, I have seen many architectures use facades to hide the fact that I
like to chain my cooks to their appliance. But what is that. I have gone
to restaurants and I don't know what a cook facade is. If I ask themanager
to present the cook facade manager employee I would probably be met by the
bouncer employee.
So what is the answer? Well for a start keep the application architecture
out of the model. The model should stand alone in describing the
interactions required to satisfy use cases. Second find an architecture
that describes a more responsibility driven design and how that design and
can map your business object behavior to a physical implementation with
appliances and cooking rules. And lastly, don't be so quick to chain your
cooks to their appliances. Give them some control over where they cook
their recipes, after all that is what they do.
Mark Perreira
Sage IT Partners.
-----Original Message-----
From: [email protected]
[<a href="mailto:[email protected]">mailto:[email protected]]On</a> Behalf Of Don Nelson
Sent: Tuesday, June 16, 1998 2:07 PM
To: Nick Willson
Cc: [email protected]
Subject: Re: Polymorphism - retrieving type information from the
database
This thread is switching context a bit, but I would add one thought tothe
idea of encapsulating behavior. One of the advantages to OO is that it
helps us model real world behavior. In the real world, I would not askan
invoice to stuff itself into an envelope and mail itself to its
customer; I
would not ask my vehicle to fuel itself or change its own oil; I wouldnot
tell an egg carton to ask one of its eggs to fry itself. Even if these
things were physically feasible, I could list a number of reasons why I
still wouldn't want to do them. That is why we haveVehicleRepairManagers
and SustenancePreparationManagers (aka, "Mechanics" and "Cooks").
Don
At 11:28 PM 6/15/98 -0700, Nick Willson wrote:
Tim,
You've had lots of good suggestions so I hope you won't mind an attempt
at another one. The consensus seems to be for your option (1) for the
Vehicle table, and Steve's example of a GenericConstraint (taking the
place of your Vehicle) is probably how most people would go about
answering your question. I don't have much to add to that, just wanted
to offer something about where the persistence mechanism lives and how
things look to clients that depend on it.
Suppose for a moment you think about the Vehicle classes' persistence as
being just one aspect of their behavior. In addition to persistence,
you might have to implement security, or locking for concurrent access,
or caching of vehicle objects to improve performance, and of course you
want to calculate the vehicle tax and probably do other things with
Vehicles too.
You can put the persistence aspect of Vehicles into a
PersistenceObjectManager, but then the others need somewhere too. If
you use a bunch of Managers (one for security, one for locking...) then
each class's behavior is scattered across these various Manager classes,
each of which has to know about many classes. Or if you use one Manager
class, it's going to know still more, plus you are forced to implement
all the behavior in (or at least via) that manager's partition.
An alternative would be to keep all the Vehicle classes' behavior
encapsulated together, so a client always makes requests to a Vehicle,
and the Vehicle delegates the implementation of requests to a chain of
handler objects that hang off the vehicle object (a handler for
security, another for persistence, and so on).
One of the nice things about this is, the handlers can be responsible
for going to another partition (if necessary), e.g. to perform
persistence operations, or for more business-specific operations like
tax calculations. And because the handlers are smart, you don't have to
put a lot of code into service objects, the SOs can stay pretty simple.
This isn't an approach you'll see in Express, so I hope of it's of some
interest.
General wrote:
Part 1.1 Type: Plain Text (text/plain)
Encoding: quoted-printable--
Nick Willson
SCAFFOLDS Consultant,
Sage IT Partners, Inc.
(415) 392 7243 x 373
[email protected]
The Leaders in Internet Enabled Enterprise Computing
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:<a href=
"http://pinehurst.sageit.com/listarchive/">http://pinehurst.sageit.com/listarchive/</a>>
>>>
>>>
>>
>>
============================================
Don Nelson
Regional Consulting Manager - Rocky Mountain Region
Forte Software, Inc.
Denver, CO
Phone: 303-265-7709
Corporate voice mail: 510-986-3810
aka: [email protected]
============================================
"When you deal with higher numbers, you need higher math." - Hobbes
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:<a href=
"http://pinehurst.sageit.com/listarchive/">http://pinehurst.sageit.com/listarchive/</a>>
>>
>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:<a href=
"http://pinehurst.sageit.com/listarchive/">http://pinehurst.sageit.com/listarchive/</a>>
>
>
============================================
Don Nelson
Regional Consulting Manager - Rocky Mountain Region
Forte Software, Inc.
Denver, CO
Phone: 303-265-7709
Corporate voice mail: 510-986-3810
aka: [email protected]
============================================
"When you deal with higher numbers, you need higher math." - Hobbes
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:<a href=
"http://pinehurst.sageit.com/listarchive/">http://pinehurst.sageit.com/listarchive/</a>>

Don,
You are absolutely correct. But this is where I honestly think you are
missing the point. While the mail program sends the mail, my mail message
has an interface (i.e. send button) which can delegate that to the mail
program. This makes it nice and simple for me the consumer of the mail
program. It also means I can think of mailing by focusing on the interface
(i.e. the button). It would suck if every time I wanted to mail something I
had to identify the correct pop server to send it to (i.e the MailManager).
Mailing something is the collaboration of the setup information of the mail
program and my mail message. If I were to model this my mail object would
indeed have a send method that could delegate to the correct mail servers.
This is just simplicity of interface and it is a good practice in UI
development just as it is in business model development. A simpler
interface, I think we can all agree, provides for a better and quicker
understanding.
Mark Perreira
Sage IT Partners.
-----Original Message-----
From: [email protected]
[<a href="mailto:[email protected]">mailto:[email protected]]On</a> Behalf Of Don Nelson
Sent: Thursday, June 18, 1998 9:22 AM
To: Nick Willson
Cc: [email protected]
Subject: Re: Polymorphism - retrieving type information from the
database
Nick,
It turns out that your message does not, indeed send itself. Your mailing
program does that.
Don
At 11:54 PM 6/17/98 -0700, Nick Willson wrote:
Hey Don,
In the real world, no, you can't tell an invoice to put itself into anenvelope
and mail itself. You have to know about stamps and post boxes and wherethey
are located. But isn't it nice that in software you don't have to followthe
real world very closely if you don't want to?
Above the top left hand corner of this message I'm typing right now, thereis a
send button which lets me tell the message to 'stuff itself into anenvelope
and mail itself'. Why wouldn't you want to do that?
Don Nelson wrote:
This thread is switching context a bit, but I would add one thought to
the
idea of encapsulating behavior. One of the advantages to OO is that it
helps us model real world behavior. In the real world, I would not askan
invoice to stuff itself into an envelope and mail itself to its customer;I
would not ask my vehicle to fuel itself or change its own oil; I wouldnot
tell an egg carton to ask one of its eggs to fry itself. Even if these
things were physically feasible, I could list a number of reasons why I
still wouldn't want to do them. That is why we haveVehicleRepairManagers
and SustenancePreparationManagers (aka, "Mechanics" and "Cooks").
Don
At 11:28 PM 6/15/98 -0700, Nick Willson wrote:
Tim,
You've had lots of good suggestions so I hope you won't mind an attempt
at another one. The consensus seems to be for your option (1) for the
Vehicle table, and Steve's example of a GenericConstraint (taking the
place of your Vehicle) is probably how most people would go about
answering your question. I don't have much to add to that, just wanted
to offer something about where the persistence mechanism lives and how
things look to clients that depend on it.
Suppose for a moment you think about the Vehicle classes' persistence as
being just one aspect of their behavior. In addition to persistence,
you might have to implement security, or locking for concurrent access,
or caching of vehicle objects to improve performance, and of course you
want to calculate the vehicle tax and probably do other things with
Vehicles too.
You can put the persistence aspect of Vehicles into a
PersistenceObjectManager, but then the others need somewhere too. If
you use a bunch of Managers (one for security, one for locking...) then
each class's behavior is scattered across these various Manager classes,
each of which has to know about many classes. Or if you use one Manager
class, it's going to know still more, plus you are forced to implement
all the behavior in (or at least via) that manager's partition.
An alternative would be to keep all the Vehicle classes' behavior
encapsulated together, so a client always makes requests to a Vehicle,
and the Vehicle delegates the implementation of requests to a chain of
handler objects that hang off the vehicle object (a handler for
security, another for persistence, and so on).
One of the nice things about this is, the handlers can be responsible
for going to another partition (if necessary), e.g. to perform
persistence operations, or for more business-specific operations like
tax calculations. And because the handlers are smart, you don't have to
put a lot of code into service objects, the SOs can stay pretty simple.
This isn't an approach you'll see in Express, so I hope of it's of some
interest.
General wrote:
Part 1.1 Type: Plain Text (text/plain)
Encoding: quoted-printable--
Nick Willson
SCAFFOLDS Consultant,
Sage IT Partners, Inc.
(415) 392 7243 x 373
[email protected]
The Leaders in Internet Enabled Enterprise Computing
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:<a href=
"http://pinehurst.sageit.com/listarchive/">http://pinehurst.sageit.com/listarchive/</a>>
>>>
>>>
>>
============================================
Don Nelson
Regional Consulting Manager - Rocky Mountain Region
Forte Software, Inc.
Denver, CO
Phone: 303-265-7709
Corporate voice mail: 510-986-3810
aka: [email protected]
============================================
"When you deal with higher numbers, you need higher math." - Hobbes--
Nick
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:<a href="http://pinehurst.sageit.com/listarchive/">http://pinehurst.sageit.com/listarchive/</a>>
>
>
============================================
Don Nelson
Regional Consulting Manager - Rocky Mountain Region
Forte Software, Inc.
Denver, CO
Phone: 303-265-7709
Corporate voice mail: 510-986-3810
aka: [email protected]
============================================
"When you deal with higher numbers, you need higher math." - Hobbes
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:<a href=
"http://pinehurst.sageit.com/listarchive/">http://pinehurst.sageit.com/listarchive/</a>>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:<a href=
"http://pinehurst.sageit.com/listarchive/">http://pinehurst.sageit.com/listarchive/</a>>

Polymorphism - retrieving type information from thedatabase

Daniel,
Yes I have always thought, that modeling the real world can lead to objects
that are unnecessary or overly complex relationships that do exist in the
real world but may not have to in a computing environment. Many times,
business models could be greatly simplified if the modelers factored out
interfaces from objects so that these interfaces could be applied based on
need of behavior without having to always construct class hierarchies in a
particular behavioral structure. Or they could benefit greatly by applying
design patterns to enhance delegation. But the problem with both of these
pieces of advice is that they assume the modeler is well versed and
understands how to apply these concepts. Many application developments I
come across are being done by a group of people that have never used an OO
tool before. With an audience such as this, how are they supposed to get
started?
Usually they will look and analyze the real-world. This will give them a
starting point in which to conduct dialog for building an object model. I
think I do know how these advanced strategies I described above are applied,
yet I always ask a customer to explain the real-world example of something
before I attempt at understanding their model and make any attempts at
advising changes. This assures that I and they have a better physical
understanding of an interaction before we attempt to describe an abstract
model of the same interaction.
As far as sharing of business objects, it is quite routine for a company to
have one group of IT application developers create a subsystem with business
objects that must be SHARED by another group of IT application developers.
The different subsystems have points of interconnect. These points can be
at the architectural level or business object level. So I don't think this
situation is as rare as you state. Further, I can see that the marketplace
is pushing more for run-time object sharing and collaboration so that this
will be the norm and not the exception.
I agree on the importance of custom routing for performance. I think it is
complex enough that I would stop short of telling people to spend time
building such a scheme. I would hate to see an application miss delivery
because the developers got too entangled in technical problems like custom
routing. But I do happen to know of a Framework product that has this as
one of its features. :)
I agree 100% with you the complexity of Forte is the marrying of object and
distributed technologies. I don't agree that frameworks cannot provide the
answer. I look at a framework as more than just a technical solution. We
use our framework to help divide the responsibilities between Business
Analyst, GUI Architect, Back-end Architect, GUI Developers and Back-End
developers. At many customers, some people play all of these roles. At
some customers, a developer may play just the GUI Developer role until he
can come up to speed on how to build simple views that are used to build
more complex windows. In this way, a large problem can be broken down into
a set of much smaller problems to help the architects manage work load and
education of the team. Without a framework that supports this sort of
approach, the architects of the application would have to delay development
until boundaries could be put in place. This can be very time consuming and
cause application rewrites if the boundaries were guessed wrong. In the
Forte marketplace today, there are products to help people set up those
architectural boundaries. It simply is more cost effective to buy one of
these solutions then it is to have your team spend time on this and add risk
to your project. In other words, architecture for a Forte development can
be bought much more cheaply than it can be created.
Mark Perreira
Sage IT Partners.
-----Original Message-----
From: Daniel Nguyen [mailto:[email protected]]
Sent: Sunday, June 21, 1998 7:35 AM
To: Mark Perreira
Cc: [email protected]
Subject: Re: Polymorphism - retrieving type information from the
database
Mark,
The battle question was only a little provocation : it seems that Forte
people and yours don't have exactly the same point of view about the way
that distribution should be made.
The problem I see on modeling the real world is that the hypothesis
seems to
be wrong : the world will never be as static as the modeling in my point
of
view. The fact is that when you try to model real world you will add
many
concepts you don't really need for the application. Those concepts may
change
with time. In my own experience I have seen that if you don't have a
real
concrete objective, it is very easy to imagine many things which won't
be
usefull when the real aim will come. That's why I think that in a
pragmatic
point of view it is better (in a cost view that's right) to focus on a
good
modeling of the system you have to build. For instance, in an exotic
currencies options system, you can imagine modeling for the Front a
system
without the product concepts, but only rules, because it is the real
world.
But when you come to the Back Office, you realize that all is managed
through
product concept. Then you come back to the Front modeling and break a
lot
of work. In the real world, the product concept does not exist, that's
right.
But it is a way to manage operations.
We all speak about Business Objects (and rules) share and re-use. I
imagine
that it is only applicable on some specific domains where the concepts
are
already shared as Insurance, Banking or Risk management on shares. This
is
because we have common rules for all companies : some financial markets
are
organized with public rules and constraints for instance. So the
difference
between companies is only on the service and not really in the business
foundations. But, in most cases, the differences between competitors are
on their business, their know how.
I have some difficulties to imagine companies with specific know how
sharing
it with competitors! So I imagine that shared business objects will be
very poor.
The problem may be that Business components will be provided by editors
like
Microsoft or may be Forte (with Express evolutions may be). But, the
business of their clients is not in the job of those providers : they
may
have a wrong view of the business of their customers, because they don't
have their know how.
On routage capabilities of manager, I agree on the technical point of
view.
This should be inherited from a service definition from Forte or a
technical
component. But, I have seen (on financial markets) that you also need
business
routage for scalability and performance. This is unfortunatly not in
Forte and
may be not really in technical frameworks on the market. Just an example
You have a financial market which is managed on several physical sites
(let's
take 2 sites). When everything is ok, you have one instance of a service
on each
site, first one managing some kind of instances (futures for instance)
and the
second one managing other kinds of instances (options for instance). But
when the
first site falls, you need (at run-time and if possible without stopping
the market)
to reconfigure the second service to manage all the instances (futures
and options).
So this is linked to business really. That's right, I base the
reflection on a very
specific (and experienced) case where the cost of the IT system is very
low compared
to the money exchanged on the system : you can imagine very specific
solutions.
The main problem I see today is that people have real difficulties to
integrate
object and distribution concepts and that Forte is to hard for Cobol or
Visual
Basic developpers. So those kinds of product should be more encapsulated
and
packaged on a push button way. The solution of making frameworks may be
very
short term solution, because of the cost and limitations about coverage
of the
clients specific objectives. Those problems come from Client/server
architectures
and needs, in my opinion, and NOT specifically from Forte or other
competitors.
Daniel Nguyen
Freelance Forte Consultant
Mark Perreira wrote:
Daniel,
I hope not. For SCAFFOLDS works only because of Forte and when I make
someone a happy SCAFFOLDS customer then they are also a happy Forte
customer. So if we sell more SCAFFOLDS, Forte sells moreForte. If there
is a battle between us, I certainly don't understand why,because we are on
the same team with the same goal.
I have always found customer have a different role than you have pointed
out. While I agree with the objectives, I have found most clients do
actually try to model the real world. They do it because it is an easy
starting point. They also do it because most OO books on the subject of
modeling point people in that direction. So they do indeedplay the role of
God with the business object model. But I have found thesesame customers
unwilling to play the role of God with the architecture. Theyare either
new to Forte and distributed object systems or they feelcomfortable with
the architecture to be documented and supported beyond thetenure of a set
of consultants that could come in and build such a system. In this case
they buy a pre-defined and built architecture.
I also agree that a Forte Service Object in and of itself can be
problematic. But I depart where you say a manager can dothings like custom
routing. This is exactly why I think Forte can be too difficult for too
many people. Any custom routing scheme is not to be takenlightly in its
impact of the overall performance and makeup of a running system. The
manager pattern does not describe a run-time environment withthe checks and
balances needed to make sure a custom router can perform. I have talked
with you Daniel and have complete faith in your ability todevelop such a
system. I would be very concerned in having just anyone try toimplement
custom routing in manager objects without a run-time environment that
simplifies and protects the participants from the mountain of technical
problems that would follow.
Mark Perreira
Sage IT Partners.
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Which Java API could check the type of Operating System the JVM is running?

Does anyone know which Java API could check the type of Operating System the JVM is running?
thanks a lot!

check out System class.
regards
shyamAnd specifically, the getProperty() method.
- K

Report to get PO from type of operation WE

Hi all
I need a standard report to get all the purchase orders from type of operation WE (Goods Receipt).
Do you know any?
Thanks in advance

Hi,
You can get the list of POs with GR in ME 2L/M etc with selection parameters WE102 .Also in SE16N browse the table EKBE with Trans./ev. type as 1(Goods Receipt) and give a date range as per requirement.This will generate the list of POs with GR .
Dhruba

Polymorphism - retrieving type informati[Ref:C520982]

Hi Tim.
Just a few thoughts on your question, based on some of the work we've done here.
We use your solution (1) to deal with this type of problem. As an example we
deal with it:
We have class called Constraint, with several subclasses (eg. Permanent,
TimeBased, ) requiring different attributes.
They are all stored in the database table Constraint, with an additional column
for the class of constraint - we call this ConstraintType.
On reading from the database, we have a class called GenericConstraint which
contains all the attributes from all the subclasses and the ConstraintType
column. We read from the database into an array of GenericConstraint.
To convert GenericConstraint into the proper subclass, we instantiate the
correct class, determined by looking at the ConstraintType attribute, and then
calling it's create method, which takes a Generic Constraint parameter. (An
alternative would be to call a method on GenericConstraint which did something
similar and returned the correct class).
This works very well for us, as the GenericConstraint class and methods which
use it provide a nice interface between the class structure we use and the
database structure in the database, and therefore flexibility.
Looking at the pattern of nulls to determine which class to instantiate may be
much more restrictive. The separate table idea that you mentioned sounds like a
one-to-one relationship - is there much benefit in implementing this separately
and then having to join the additional table ?
Hope this helps.
Steve Elvin
Frontline Ltd.
UK.
-----Original Message-----
From: INTERNET [email protected]
Sent: Monday, June 15, 1998 12:29 PM
To: Stephanie Mahay; Steve Elvin; X400
p=NET;a=CWMAIL;c=GB;DDA:RFC-822=forte-users(a)sagesoln.com;
Subject: Polymorphism - retrieving type informati [Ref:C520982]
Suppose I have a class structure containing one base class with several speciali
sations. Say, "Vehicle", with specialisations of "Car", "Van" and "Truck". All v
ehicles are persisted in the database, in a rolled-up table, and I want a generi
c retrieval mechanism, which fetches a vehicle based on the license plate number
. (It will probably be a service object, which I will call a Persistent Object M
anager).
I wish to retrieve ALL vehicles, and calculate the road tax for each. However, c
ars, vans and trucks are all subject to different tax rules, and require a diffe
rent method to calculate their road tax. To put it another way, there is a polym
orphic method 'CalculateRoadTax' on the "Vehicle" class.
Q: As each vehicle is extracted from the database, how does the rest of the Fort
e application know what type of vehicle it is?
I am sure that others must have solved this problem before, but it is new to us.
We have come up with the following solutions:
(1) Add a "sub-type" column to the "Vehicle" table. Use the type information to
instantiate a Forte object of the correct type
(2) Maintain a completely separate table linking the vehicle licence plate to i
ts sub-type.
(3) Deduce the type of the object from the pattern of null columns in the row.
I think (1) is the best solution, but I'm interested to know what the experts sa
y!
Incidentally, if Express can help or hinder in this situation, I would be intere
sted in that as well.
regards,
Tim Kimber
EDS (UK)
<< File: untitled.dat >>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

RE: Polymorphism - retrieving type information from thedatabase

I would disagree with your statement that either the object or data model
must be wrong. The problem is more fundamental-trying to store objects in a
relational database. The object and relational paradigms can be made to
work together, but usually only by compromising tenets of one or the other
(or both). Now granted, there are many ways of making them work
together-and some are definitely better than others.
CJ
Chris Johnson
612-594-2535 (direct)
612-510-4077 (pager)
-----Original Message-----
From: Rottier, Pascal [SMTP:[email protected]]
Sent: Monday, June 15, 1998 8:17 AM
To: Forte Users Mailing list
Subject: RE: Polymorphism - retrieving type information from
the database
> ----------
> From: Rottier, Pascal[SMTP:[email protected]]
> Sent: Monday, June 15, 1998 8:17:16 AM
> To: Forte Users Mailing list
> Subject: RE: Polymorphism - retrieving type information from
the database
> Auto forwarded by a Rule
>
This issue has already passed this mailing list a couple of
times in the past. To put it in more general terms, you have
different classes which you store in the same DB table.
This is always tricky. Nine out of ten times, this means
either your Object model or your DataBase model is wrong.
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

This issue has already passed this mailing list a couple of
times in the past. To put it in more general terms, you have
different classes which you store in the same DB table.
This is always tricky. Nine out of ten times, this means
either your Object model or your DataBase model is wrong.
If you can differentiate between different classes, this
means you're dealing with different entities, which should
be stored in different tables. What if one class has an
attribute the other one doesn't. This would mean you have
to add a column to the database which is filled it the row
represends one class and is NULL if the row represends
another class. This is not good database practice!
Differentiating between different classes by means of
a "type" attribute is the classic procedural approach.
The OO approach would be to create subclasses. How-
ever, a relational database doesn't support subclasses.
The best way, would be to have a different table for
each subclass. If this gives you problems with norma-
lizing your database, you can create a table with all
the attributes generic to vehicle, and a table for each
subclass with only the attributes relevant to this sub-
class and a foreign key relation to the main table. If all
of this is not feasable, you're left with the need to find
some mechanism to identify what kind of class a cer-
tain row represends and then instantiate this class. The
tree solutions you suggested all work. It doesn't really
matter which one you chose, they're all equally dirty.
Hope this helps,
Pascal.
-----Original Message-----
From: General [SMTP:[email protected]]
Sent: Monday 15 June 1998 12:20
To: [email protected]
Subject: Polymorphism - retrieving type information from the
database
Suppose I have a class structure containing one base class with
several specialisations. Say, "Vehicle", with specialisations of
"Car", "Van" and "Truck". All vehicles are persisted in the database,
in a rolled-up table, and I want a generic retrieval mechanism, which
fetches a vehicle based on the license plate number. (It will probably
be a service object, which I will call a Persistent Object Manager).
I wish to retrieve ALL vehicles, and calculate the road tax for each.
However, cars, vans and trucks are all subject to different tax rules,
and require a different method to calculate their road tax. To put it
another way, there is a polymorphic method 'CalculateRoadTax' on the
"Vehicle" class.
Q: As each vehicle is extracted from the database, how does the rest
of the Forte application know what type of vehicle it is?
I am sure that others must have solved this problem before, but it is
new to us. We have come up with the following solutions:
(1) Add a "sub-type" column to the "Vehicle" table. Use the type
information to instantiate a Forte object of the correct type
(2) Maintain a completely separate table linking the vehicle licence
plate to its sub-type.
(3) Deduce the type of the object from the pattern of null columns in
the row.
I think (1) is the best solution, but I'm interested to know what the
experts say!
Incidentally, if Express can help or hinder in this situation, I would
be interested in that as well.
regards,
Tim Kimber
EDS (UK)
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Block create type of operation more than one time

Hello SAP CRM Experts!
I have a question.
How do I get block the user create a type of operation more than one time?
For example, I have a kind of opportunity that can be created only once for each client. How can I do this using the customizing?
Best Regards!
Tks!

Hi,
you could only limit the assigned internal number range to one object, which would allow only one document to be saved. The next creation would then fail since there is no number available.
This is the only solution I can think of, otherwise you need to program a BADI.
Regards, Kai

Complex return type for operations in Application Services

Hi all,
I am trying to create a complex return type for one of operation in CAF Application service.I have created a complex dataStructure named productList and added product bussiness object as its attribute with cardinality 0--n. And used product dataType as my return type.
But I am not getting any output but its work fine with cardinality 0--1.
I am using CE 7.1 SP5 trial version.......
Can anyone

Hi,
And used product dataType as my return type.
Are you sure you did not forgot to change you operations return type to "productList"?
Best regards
Philipp

Change of activity type of operation overview through object dependency

Hi,
I am working on variant configuration project and I am using the global object dependencies (procedures) to change the BOM item quantities, Operation standatd values and activity types in super bom and super routings. When I use these dependencies BOM quantities and routing standard values are changed but activity types are not updated.
If anybody have any idea about this, how to use the dependency to update the activity type? or any prgram error / any OSS note for this?
We are working on ECC6.0.
Advanced thanks...
B Venkat

Hi Venkat,
As you may be having idea of usage of reference characteristics usage in changing the fields because you are already told that you are able to change the Qty field, same like this you need to have the reference char relevant to this field and table .
Now the activity type comes from the work center. so you need to change actvity type in work center or you have to change the workcenter ( expected workcenter should have your required activity type) by the object dependency. It's looking a bit thoghtful one. Just think in your functionality it will work.
Thanks
Ankaiah

Transaktion type of operations

Hello,
first of all I'm using SAP NetWeaver CE.
My scenario:
I have created a CAF-Project where I import RFC Modules as External Services. Then I created an Application Service (AS_1) in the same CAF-Project where I created Application Service Operations (Implemented not enabled). Then I map the external service operations to application service operations. The external service operations read from and write to the R/3 backend system. I set the Transaction Type of the Application Service Operations to Supports because if I create Automatic Mappings for Application Services as described [here|http://help.sap.com/saphelp_nwce10/helpdata/en/ad/b88de027c34daf96db9ac3d8a92194/frameset.htm] (Creating Automatic Mappings for Application Services) the Transaction Type is automatically set to Supports.
Now my first question: Why do I have to associate operations with transactions? What's the background in conjunction with RFCs?
My second question: If in the middle of the execution of an RFC module is an interruption and not all data, the RFC module have to write, is actually write, is there a rollback on the R/3 backend like described [here|http://java.sun.com/javaee/5/docs/tutorial/backup/doc/Transaction2.html]?
My third question: Can somebody give me a detailed description why I have to set the Transaction Type to Supports in this scenario?
After I do the mapping I created a second Application Service(AS_2). I created operations(Implemented enabled) where I use the operations of the AS_1. There I set the Transaction Type to Required because in the SAP NetWeaver CE Library is an example where one also use operations of an other Application Service and the Transaction Type is also set to Required.
Now my fourth question: Is this the right way to set the Transaction Type of the AS_2 to Required? And Why?
Fifth question: Is it the right way to the setting of the Transaction Type of AS_1 and AS_2? and Why?
Regards,
Armin

Hi Armin,
Please see below my answers to your questions:
1st question:
As you probably know in JEE there are two ways of dealing with transactions - programming and declarative. In the programming style, the developer defines the transactions boundaries by invoking the transaction begin(), commit() and rollback() methods. In the declarative style, each operation is assigned a transaction attribute (required, mandatory, supports ...). CAF uses the declarative approach and therefore each operation is assigned a transaction attribute. This style is not specific for RFCs, it is a standard JEE approach.
2nd question:
It depends on the backend RFC function implementation. Usually BAPIs support this and if something fails, everything is rollbacked.
3rd quesiton:
It is not mandatory to set the transaction type to 'Supports'. 'Supports' is the default value and you can change it afterwards if you like.
4th and 5th questions:
There's no general rule of thumb how to set operations Transaction Types. It depends on your concrete operations, on the business logic you want to achieve and so on.
Regards,
Trendafil

DB2 Log file retrieval during normal operation

Hi,
We recently upgraded our databases to DB2 v9.7 FP1 and started noticing entries in the db2diag.log that state a log file is being retrieved (after it was archived). We are not performing a restore, although this only seems to be happening during the time our online backup is running.
This is one example of an entry in the db2diag.log:
2010-08-18-21.52.43.687630-300 I46847828A425      LEVEL: Warning
PID     : 27014                TID : 19          PROC : db2sysc 0
INSTANCE: db2qas               NODE : 000
EDUID   : 19                   EDUNAME: db2logmgr (QAS) 0
FUNCTION: DB2 UDB, data protection services, sqlpgArchiveLogFile, probe:3180
MESSAGE : Completed archive for log file S0052437.LOG to VENDOR chain 1 from
          /db2/QAS/log_dir/NODE0000/.
.<other messages>
2010-08-19-03.13.37.185763-300 I46895785A364      LEVEL: Warning
PID     : 27014                TID : 19          PROC : db2sysc 0
INSTANCE: db2qas               NODE : 000
EDUID   : 19                   EDUNAME: db2logmgr (QAS) 0
FUNCTION: DB2 UDB, data protection services, sqlpgRetrieveLogFile, probe:4130
MESSAGE : Started retrieve for log file S0052437.LOG.
2010-08-19-03.14.38.221285-300 I46896150A418      LEVEL: Warning
PID     : 27014                TID : 19          PROC : db2sysc 0
INSTANCE: db2qas               NODE : 000
EDUID   : 19                   EDUNAME: db2logmgr (QAS) 0
FUNCTION: DB2 UDB, data protection services, sqlpgRetrieveLogFile, probe:4148
MESSAGE : Completed retrieve for log file S0052437.LOG on chain 1 to
          /db2/QAS/log_dir/NODE0000/.
It doesn't appear to be causing any harm, but can someone please explain why DB2 would need to retrieve an already archived log file?
Thanks,
Setu

Hi,
The online backup by default invokes the option "include logs". And that is why you see the required archived logs being retrieved.
Benny

Re[2]: Polymorphism - retrieving type information from thed

To add to Inderjyot's comments there is an excellent white paper at
Scott Ambler's web site on mapping objects to relational databases.
The web site is: www.ambysoft.com. This white paper is at
www.ambysoft.com/mappingObjects.pdf
/\/\ark /\/ichols
Technical Consultant
AiC
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

To add to Inderjyot's comments there is an excellent white paper at
Scott Ambler's web site on mapping objects to relational databases.
The web site is: www.ambysoft.com. This white paper is at
www.ambysoft.com/mappingObjects.pdf
/\/\ark /\/ichols
Technical Consultant
AiC
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

How to distinguish the type of trigger DML operation?

I want to log all changes to some table (inserts, updates and deletes). Before every change I want to insert the values to the log table along with operation type and sysdate.
I want to do it in one trigger, but I don't know how to read the type of operation? I could do it with three triggers, each for insert, update and delete, but this would be easier.
create trigger emp_trig after insert or update or delete on emp
for each row
begin
insert into emp_log values(
:new.empno, :new.ename,
__operation__, sysdate);
end;Thanks in advance
Viliam

In case you had an ID, which is assigned automagically on emp, this could also be written like this:
create trigger emp_trig
after insert or update or delete on emp
for each row
begin
insert into emp_log values(
:new.empno, :new.ename,
decode(nvl(:old.id,-1),-1,'Insert',decode(nvl(:new.id,-1),-1,'Delete','Update')), sysdate);
end;
..where -1 is a value you do not expect to be propagated ever in id column. Also, :new.empno and :new.enmae will be null if the dml being executed is a delete statement.

Operation Pull supply type at Item/BOM level is defaulted to Assembly Pull in WIP

Hi All,
I have an Item for which supply type is operation pull at item and BOM level, However when I create a WIP job and use this item its supply type is defaulting as Assembly Pull.
Could you please helpe me on this.
Regards,

Sandeep Gandhi, Independent Consultant wrote:
It takes the supply type from the org item record.
Can you double check the supply type on org item?I am also seeing the same behaviour..
I did check at item level too..
Please advise
Thanks
Mahendra

OMBPLUS: retrieve type of operator?

Similar Messages

Maybe you are looking for