Extending @interface
hi, first time posting...
I'm more of a hobbyist java programmer, so i can jump in to 1.5 faster than my friends who have to continue to use 1.3 or whatever because of what their company uses. the only downside to this is that I don't have anyone to ask! ok, so here goes
I was seeing if I could write some kind of Annotation, and then have another Annotation that extends it, inheriting its super's properties, etc, adding others, you know the deal. I have seen no documentation on this, but here's some code that I wrote that compiles (it's a lot like what Hibernate or OJB would do, but i was just testing so no code critique unless it's for Annotations :) )
//field.java
import java.lang.annotation.*;
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
public @interface field {
String columnName();
Class type();
}i used lowercase but eventually when i really start writing stuff, I'll fix it (and rename it to Column or something). Anyway, then I tried to write a "primary key" annotation, which is a field, so naturally, i wanted to extend from field
//primaryKey.java
import java.lang.annotation.*;
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
public @interface primaryKey extends field {
boolean autoIncrement();
}but i get "primaryKey.java:5: extends not allowed for @interfaces"
so i try "extends @field" out of desperation, but that's a syntax error. next i try
public interface primaryKey extends fieldbut since the @retention and @target annotations are there, this doesn't compile either. i'm lost! can you not derive an annotation from another? my last option, which works, is to include "field" as a parameter for "@primaryKey"
import java.lang.annotation.*;
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
public @interface primaryKey {
field column();
boolean autoIncrement();
}which would be used like so
@primaryKey(column=@field(columnName="id",type=java.lang.Integer.class),autoIncrement=true)
public Integer id;any ideas or anyone just up for talking about this? i love talking java :-D
I'm going to guess that the way they were designed to be used is like this
define the @field Annotation and the @primaryKey annotation, then a field "id" has both Annotations on it, like so
@field(columnName="id",type=java.lang.Integer.class)
@primaryKey(autoIncrement=true)
public Integer id;anybody? actually, that seems fine.
Similar Messages
-
Extended Receiver & Extended Interface Determination
Hi Experts,
Can any tell me what is Extended Receiver & Extended Interface Determination.
And the Difference between Standard Receiver & Standard Interface Determination.
were to use Extended Receiver & Extended Interface Determination.
Thanks in advance
ShakifHi,
Standard Receiver Determination Features
Specifying Receivers
You can specify receiver parties and receiver services. To specify the receiver in more detail, you have the following options:
● Select the receiver from the Integration Directory
● Specify a constant value for the receiver
● Determine the receiver dynamically from the message content
To enter the necessary details, use the following:
● The party editor for specifying the receiver party
● The service editor for specifying the receiver service
To call the relevant editor, in the Display/Edit Receiver Determination editor in the Configured Receivers frame, call the Input Help ( ) in either the Party or Service column.
Defining Conditions
You also have the option of specifying the conditions to be applied when forwarding a message to the receiver(s) in a receiver determination.
Generally, a condition relates to the contents of a message; if a specified condition is fulfilled for a particular payload element (the corresponding element has a certain value, for example), then the message is forwarded to the specified receiver(s).
● If you want to specify a new condition for forwarding the message to a receiver, in the table in the Display/Edit Receiver Determination editor in the Configured Receivers frame, choose Insert New Condition () and call the condition editor by using the input help ().
● If you want to specify a new condition for forwarding the message to multiple receivers, in the table in the Display/Edit Receiver Determination editor in the Configured Receivers frame, choose Insert Line After Selection ( ) and call the condition editor by using the input help ().
In the condition editor, you can select an element from the message payload and specify a value with which the value of this element is to be compared at runtime.
Enhanced Receiver Determination
Use
You use an enhanced receiver determination to have a mapping program determine the receivers of the message dynamically at runtime. Instead of creating the receivers in the receiver determination manually, you assign a mapping to the receiver determination and this returns a list of receivers at runtime.
A typical usage case is if you do not yet know the names of the receivers at configuration time. In this case, you can define a mapping program, for example, which reads a list of receivers from a table or from the payload of the message at runtime.
You can of course formulate conditions in a standard receiver determination that relate to the content of the message. However, you have to specify the names of the receivers (to which the message is sent under the formulated condition) explicitly in the receiver determination. If you create an enhanced receiver determination, you do not have to specify receiver names at this stage.
Integration
During the definition of the interface mapping, you assign the abstract message interface ReceiverDetermination as the target interface. The message interface ReceiverDetermination is in the Integration Repository in the software component SAP BASIS (namespace http://sap.com/xi/XI/System).
The message interface uses the message type Receivers and the data type Receivers. The data type Receivers describes a list of receivers and has the following structure:
The following instance of the data type Receivers contains two receivers. The first receiver comprises a party and service and is identified by a DUNS number; the second receiver comprises a service without a party.
<Receivers>
<Receiver>
<Party agency=016 scheme=DUNS>123456789</Party>
<Service>MyService</Service>
</Receiver>
<Receiver>
<Party agency=http://sap.com/xi/XI scheme=XIParty></Party>
<Service>ABC_200</Service>
</Receiver>
</Receivers>
You can specify party and service for each receiver.
Activities
1. Integration Repository: Define the interface mapping. Assign the message interface ReceiverDetermination as the target interface (see above).
2. Integration Repository: Define the message mapping or mapping program that is to determine the receivers at runtime. Assign the message mapping or mapping program to the interface mapping.
3. Integration Directory: Define an (enhanced) receiver determination.
○ Enter the outbound interface of the interface mapping from step 1 in the key of the receiver determination as the outbound interface.
○ Assign the interface mapping created in step 1 to the receiver determination.
Standard Interface Determination
Use
You can specify to which inbound interfaces at the receiver the message is to be sent at runtime. You also have the option of specifying a mapping and (when multiple inbound interfaces are defined) a condition for each inbound interface.
Note the following fundamental cases when assigning multiple inbound interfaces:
Multiple Different Inbound Interfaces
Imagine you enter the following interface assignment.
Inbound Interface
Condition
Interface Mapping
IF_1
M_1
IF_2
M_2
After the interface determination is evaluated, this results in two messages with the same payload at runtime. A different mapping (either M1 or M_2) is executed for both messages and then they are forwarded to the two interfaces (either IF_1 or IF_2) at the receiver.
Multiple Identical Inbound Interfaces with Conditions
Imagine you enter the following interface assignment.
Inbound Interface
Condition
Interface Mapping
IF_1
B_1
M_1
IF_1
B_2
M_2
In this case, the conditions are evaluated during the interface determination step. If condition B_1 is true, then mapping M_1 is executed; if condition B_2 is true, then mapping M_2 is executed. The message is forwarded to the same inbound interface at the receiver in both cases. Unlike in the case described above, this does not result in multiple messages with the same payload because only one condition can ever be true at runtime.
Features
You enter the assignment between the outbound interface and the inbound interface(s) in a table. Each table line represents exactly one assignment between the outbound interface and an inbound interface. To insert or delete lines, choose Insert One Line After Selection () or Delete Selected Line ().
Enhanced (Mapping-Based) Interface Determination
Use
In an enhanced interface determination you do not enter the inbound interfaces manually, but instead first select a multi-mapping. You get the inbound interfaces from the target interfaces of the multi-mapping. The inbound interfaces are determined at runtime during the mapping step.
You typically use an enhanced interface determination if the source message has an element with occurrence 0 ... unbounded (for multiple items of a data record) and you want multiple messages (for the individual items) to be generated at runtime.
For example, you want to split an overall booking for a trip comprising connecting flights into individual booking orders (for each leg of the trip).
You cannot realize this usage case with a standard interface determination (without using an integration process). A standard interface determination does allow you to specify multiple (N) inbound interfaces (with different mapping). In this case, N messages with the same payload and different receiver interfaces are generated from the source message before the mapping step; these are then transformed differently depending on the receiver interface. Therefore it is conceivable to write the mappings in such a way that the first mapping from the source message generates a message that only contains the first item, the second mapping generates a messages that only contains the second item, and so on. However, this no longer works if the number of items can vary with each new source message.
You can use an enhanced interface determination to configure a mapping-based message split for this usage case. You assign the interface determination a multi-mapping that has a target interface with an element with occurrence 0...unbounded. At runtime, the individual messages (for the individual items) are calculated in the mapping step. First, the individual messages are grouped into a bulk message. Then, the bulk message is transferred to the Adapter Engine. The Adapter Engine then splits the bulk message up into the individual messages (see figure).
Procedure at Runtime During Message Split
Note that both the bulk message and all individual messages each have a message header with a receiver interface (see figure).
Receiver Interfaces of Bulk Messages and Individual Messages
The header of the individual messages contains the relevant receiver interface. It is based on the definition of the multi-mapping. Note that the receiver interfaces of the individual messages may be different. The receiver interface of the bulk message is always InterfaceCollection (namespace http://sap.com/xi/XI/System).
If the message split only results in one message, the original message structure remains the same. In this case, a bulk message containing just one individual message is not created.
You can also assign a multi-mapping with multiple different target interfaces to an enhanced interface determination (1:n transformation). Each target interface can contain elements with occurrence 0 ... unbounded.
Messages cannot be sent by using different Adapter Engines in a mapping-based message split. This affects configuration thus: All receiver agreements that have a receiver interface from the mapping entered in the key must only be assigned communication channels with the following adapter types:
- RFC Adapter
- SAP Business Connector Adapter
- File/FTP Adapter
- JDBC Adapter
- JMS Adapter
- SOAP adapter
- Marketplace adapter
- Mail Adapter
- RNIF adapter
- CIDX Adapter
The adapters also have to all run on the same Adapter Engine.
Adapters developed by partners also support a mapping-based message split if they run on the same Adapter Engine.
Attachments from the original message are not appended to the messages resulting from the message split.
Activities
To execute a mapping-based message split, perform the following steps:
1. Integration Repository: Define the multi-mapping (see Developing Multi-Mappings for Message Splits).
2. Integration Directory: Define the interface determination.
Note the following:
○ The outbound interface of the multi-mapping must be entered as the sender interface in the key of the interface determination.
○ The interface determination type must be set to Enhanced.
○ Select the multi-mapping you defined previously from the Integration Repository.
To do so, call input help ().
The target interfaces of the interface mapping are displayed in the Inbound Interfaces frame.
The number of messages (for an inbound interface) created in the mapping step is displayed in the Occurrence column.
Regards,
Phani
Reward points if Helpful -
Generics hierarchy in extending interfaces
Let's say I have an interface like this:
package source;
import java.util.List;
public interface ITest <GTest extends List> {
public void setList(GTest list);
}I extend that interface to have a new one whose generic is an implementation of the generic of the original interface:
package source;
import java.util.ArrayList;
public interface ITestEx extends ITest<ArrayList> {
}Then I write a class which inspects the extended interface to enumerate its methods with their parameters:
package source;
import java.lang.reflect.Method;
public class Test {
public static void main(String[] args) {
Method methods[] = ITestEx.class.getMethods();
for (int nMethod = 0; nMethod < methods.length; nMethod++) {
System.out.println("\nMethod #" + nMethod + ": " + methods[nMethod].getName());
Class<?>[] parameterTypes = methods[nMethod].getParameterTypes();
for (int nParameterType = 0; nParameterType < parameterTypes.length; nParameterType++) {
System.out.println("Parameter type #" + nParameterType + ": " + parameterTypes[nParameterType].getName());
}The output is:
Method #0: setList
Parameter type #0: java.util.List
That is, the argument of the setList(GTest) method is retrieved as List, which is the type GTest was declared to be in the base interface (ITest), even though getMethods() was called on its subinterface (ITestEx), which declares the generic as ArrayList.
Is it possible to use reflection in a way that in this case would retrieve the argument of setList(GTest) as ArrayList ?
P.S. We have been pointed to http://www.ibm.com/developerworks/library/j-cwt11085.html , but we couldn't understand whether it might help.
Edited by: SantiBailors on Sep 19, 2007 3:25 PMHi, I've altered your code by adding a helper method getTypes that maps formal type arguments to actual types. Now it prints the "real" type names. HTH
public static void main(String[] args) {
Map<TypeVariable<?>, Type> types = getTypes(ITestEx.class, ITest.class);
Method methods[] = ITestEx.class.getMethods();
for (int nMethod = 0; nMethod < methods.length; nMethod++) {
System.out.println("\nMethod #" + nMethod + ": " + methods[nMethod].getName());
Type[] parameterTypes = methods[nMethod].getGenericParameterTypes();
for (int nParameterType = 0; nParameterType < parameterTypes.length; nParameterType++) {
if (types.containsKey(parameterTypes[nParameterType]))
System.out.println("Parameter type #" + nParameterType + ": "
+ types.get(parameterTypes[nParameterType]));
else
System.out.println("Parameter type #" + nParameterType + ": " + parameterTypes[nParameterType]);
private static <T> Map<TypeVariable<?>, Type> getTypes(Class<? extends T> cl, Class<T> genericInterface) {
Map<TypeVariable<?>, Type> typeMapping = new HashMap<TypeVariable<?>, Type>();
for (Type t : cl.getGenericInterfaces()) {
if (t instanceof ParameterizedType) {
ParameterizedType pt = (ParameterizedType)t;
if (pt.getRawType().equals(genericInterface)) {
for (int i = 0; i < genericInterface.getTypeParameters().length; ++i)
typeMapping.put(genericInterface.getTypeParameters(), pt.getActualTypeArguments()[i]);
break;
return typeMapping;
Edited by: McNepp on Sep 20, 2007 12:14 PM -
Extended Interface determination
I have a outbound scenario
R/3 (PO from different vendors)--> Mapping A(or)Mapping B(or)Mapping C-->multiple Partners
when a puchase order comes to XI it should be able to recognise either of the mappingsA,B orC.
Can i use extended Interface determination in this case giving the vendor number(unique) so that the appropriate mapping is selected.
-SudhansuHi Sudhanshu,
As Mark says, YOu can use extended interface determination when you use multi mapping and no need to define BPM for the same.
But for your requirement, under Standard Interface determination , Give multiple Interface mapping and give Xpath conditions for Vendor number for every Mapping.
Let us know if you require more clarifications.
Best Regards,
Divyesh -
Interfaces Extending Interfaces Problem?
Hey everyone,
I have a problem that could effect anyone who is using interfaces that extends other interfaces.
Check this out:
If I have an interface IHuman that extends three interfaces IMortal, ILimbed and IHealth:
package
public interface IHuman extends IMortal, ILimbed, IHealth
Extends
package
public interface IMortal
function spawn():void;
function die():void;
package
public interface ILimbed
function sprint():void;
function walk():void;
function crouch():void;
package
public interface IHealth
function set health( value:Number ):void;
function get health():Number;
Now when the code is generated for the Human class when the IHuman interface is implimented, CHECK THIS OUT!
package
public class Human implements IHuman
public function Human()
public function spawn():void
public function sprint():void
public function set health(value:Number):void
public function die():void
public function walk():void
public function get health():Number
return 0;
public function crouch():void
The functions are all over the place, it becomes an interface pasta! Now, I dont know if there is a preference for this. But I have been looking all day, and I have found no solution to this code generation problem.
This is not helpful code generation, it simply throws the interfaced functions around in your class, and becomes a real hastle to re-organize.
Does anyone have a solution to this really odd code generation problem?
Cheers
NickMy question is not to inherit the interface or not. It is about the generation of code from an inherited interface. Why is it that when I inherit an interface that exdends other interfaces, that it does not generate the code in order of the extended interfaces.
My question is basicaly this, why does the inherited interface get interwoven with it self when I impliment it in a class.
package
public interface IMortal
function spawn():void;
function die():void; -
Standard Vs Extended Interface Determination
Can someone tell me what is the difference between extended and standard interface determination
Extended receiver determination is used when you want to decide which receiver's to send the message to based on the content of the input message or some other condition at runtime.
Here, first you define mapping to figure out the receivers of the msg and then you call this mapping in your receiver determination. the "receiver" message type which is present in sap basis -->... XI/system namespance i think.
The whole idea behind enhanced receiver determination is that during normal receiver determination the pipe line step for receiver determination is executed before the mapping step this resulted in a limitation in XI that you could not change your receivers based on the mesg content at runtime.
Now, in enhanced receiver determination XI will first execute this receiver determination mapping and figure out the receivers at runtime and then call the individual mappings.
Cheer's -
Implemenet/Extend interface/class in default package
Filename: DeaultInterface.java
public interface DefaultInterface {
// Abstract Methods...
Filename: ConcreteClass.java
package com.company;
import DefaultInterface;
public class ConcreteClass implements DefaultInterface {
// Implementation of Abstract Methods...
}When I compile above java code it gives error "cannot find symbol. symbol: class DefaultInterface".
Can anyone explain why can't we implement the interface/extend the class in default package(no package)?
Edited by: 974531 on Dec 2, 2012 11:07 PM>
When I compile above java code it gives error "cannot find symbol. symbol: class DefaultInterface".
Can anyone explain why can't we implement the interface/extend the class in default package(no package)?
>
You CAN implement the interface defined in the default package.
What you CANNOT do is import it. And that is because the Java Language Specification specifies that named types can only be referenced by their simple name if they are imported and must otherwise be referenced by their fully qualified name.
See the 7.5 Import Declarations in the Java Language Specification - http://docs.oracle.com/javase/specs/jls/se7/html/jls-7.html
>
An import declaration allows a named type or a static member to be referred to by a simple name (§6.2) that consists of a single identifier.
Without the use of an appropriate import declaration, the only way to refer to a type declared in another package, or a static member of another type, is to use a fully qualified name (§6.7).
A type in an unnamed package (§7.4.2) has no canonical name, so the requirement for a canonical name in every kind of import declaration implies that (a) types in an unnamed package cannot be imported, and (b) static members of types in an unnamed package cannot be imported. As such, §7.5.1, §7.5.2, §7.5.3, and §7.5.4 all require a compile-time error on any attempt to import a type (or static member thereof) in an unnamed package.
>
So you can't reference that type by importing it because you can't import a type that doesn't have a canonical nmae. And you can't just use the simple name because, as the first statement above says you have to import it to use the simple name.
When you use the simple name of that type without an import the simple name would refer to a class IN your 'com.company' named package. -
Workbench problem when interface extends interface
Hi,
I have a problem when importing an existing class into Toplink Workbench. This class has a getter/setter on a property, say getAccountType() where AccountType is an interface. This property is not persistent, only a string representation of its value stored in a private field. So as far as Toplink is concerned, the interface AccountType is not persistent.
When I try to import, I get an ExternalClassNotFoundException. We found that the interface AccountType extends another interface and this seems to be the problem. If we remove the inheritance, the import goes fine.
I don't know if this is related, but AccountType is in my project and the super-interface is in a dependency jar file (this jar file is specified in workbench's CLASSPATH).
workbench = 9.0.4.2
jdk = 1.4.2_07
Thanks for your help
Jean-Christian GagneUnfortunately in 9.0.4, the error message you are receiving is not very helpful or accurate. My guess is that something the super-interface is referencing is not on your classpath and that is why you are getting the exception. In 10.1.3 this will not be a problem because we have changed how we load classes. Your super-interface would not actually be loaded in to the workbench.
Karen -
Extending interfaces and xtending classes
Hello there,
I've extended an interface from two interfaces like this:
interface1 extends interface2, interface3
and although the compiler doesn't seem to mind, I'm not sure
whether this is really correct. With classes this is not possible
and I would need to implement multiple interfaces, but then how
would I deal with a collection of objects which I would like to
be of type interface1?
Many thanksHere's a link that explains it in more detail:
[url
http://forum.java.sun.com/post.jsp?forum=31&thread=3800
&message=1625659&reply=true&doPost=true&subject=April
Fools:)&body=Fooled You]Interfacesoopps, should be:
[url http://forum.java.sun.com/post.jsp?forum=31&thread=38004&message=1625659&reply=true&doPost=true&subject=YoGee Fooled You:)&body=Fooled You]Interfaces -
I have written an interface, InterfaceA, with the following declaration:
public interface InterfaceA {
public void test();
Now I need to write two classes, one is to be used locally and the other one will be acted as a remote object. Thus I add one more interface, InterfaceB, for the latter class.
public interface InterfaceB extends InterfaceA, Remote {
public void test() throws RemoteException;
public class ClassB extends UnicastRemoteObject implements InterfaceB {
However, when I compile the files, the following error is reported:
ClassB.java:4: test() in ClassB cannot implement test() in InterfaceA; overridden method does not throw java.rmi.RemoteException
public class ClassB extends UnicastRemoteObject implements InterfaceB {
Can anyone tell me how to solve this problem without sacrifying InterfaceA?
Thanks,
Fredthe reason you cant do this is as follows:
suppose you have a ref to a local classB instance and you cast down to interfaceA (which you could do if the compiler let you compile your code). Then you could call methods on interfaceA which have no throws clause, but could (in the hypothetical situation that this compiles) throw a RemoteException because all of classB's methods must throw RemoteExceptions.
generally, you have this problem any time that you make the contract of a method more restrictive thru inheritance. you can always catch some exceptions, but you cant throw any extras, because this would defeat any code that uses a reference to the base class or interface. similary you can give more access to a method (make it public, say) but you cant take it away (by making a public or protected method private).
Anyway, hope that was helpful
Alex -
Interfaces that extend other interfaces
I am trying to get a handle on the concept of interfaces extending other interfaces, and I just want to bounce my thoughts off the board and see where it goes. The Sun tutorial doesn't provide a lot of detail that I can see.
Suppose we have interface A which has 3 methods (signatures), and interface B which extends interface A and adds two methods of its own. Suppose also we have a class C which can implement A or B or both.
1. Having B extend A provides a heirarchy of types, with A above B
2. If class C implements interface B, then the extends relationship B has with A forces C to provide implementations for the methods of A as well as B. On this point I am not certain.
3. Having B extend A allows us to essentially add methods to the interface defined by A without forcing those changes on owners of the classes that already extend A.
Sound OK? Anywone have anything to add?
Edited by: Fguy on Aug 27, 2009 7:07 PMjverd wrote:
Fguy wrote:
>
3. Having B extend A allows us to essentially add methods to the interface defined by A without forcing those >>changes on owners of the classes that already extend A.Huh? Not sure what you're saying, here, but extending A means we're defining a type that's a specialized or >enhanced type of A. Implementors can implement A if all they need is a run of the mill A, or B if they need the >specialized/enhanced version.Thanks.
What I meant was that class C implements interface A, and interface B is not a part of the picture yet. Then, by creating a new interface B that extends A, rather than just adding the new methods to A, then you are not forced to add new method implementation to class C right away.That would be one situation in which one might do that. Of course, it's also not uncommon to design the two distinct interfaces from the start
Ok I'll pick up on that, the situation that led to this thread was me trying to understand why the List interface extends the Collection interface, and why the ArrayList class implements both interfaces. And I eventually decided that designing kind of an arrangement makes sense from the start as you say, because there are probably reasons why you'd want that type heirarchy, or higher level abstraction. with different levels of functionality in the respective implementations. I can't really think of any other reason. -
When we will go for Ectended Interface Determination
extended interface determination example give me any one...
Regards,
VinayEnhanced (Mapping-Based) Interface Determination
Use
In an enhanced interface determination, you do not enter the inbound interfaces manually, but first select a multi-mapping. You get the inbound interfaces from the target interfaces of the multi-mapping. The inbound interfaces are determined at runtime during the mapping step.
You typically use an enhanced interface determination if the source message has an element with occurrence 0 ... unbounded (for multiple items of a data record) and you want multiple messages (for the individual items) to be generated at runtime.
For example, you want to split an overall booking for a trip comprising connecting flights into individual booking orders (for each leg of the trip).
You cannot realize this usage case with a standard interface determination (without using an integration process). A standard interface determination does allow you to specify multiple (N) inbound interfaces (with different mapping). In this case, N messages with the same payload and different receiver interfaces are generated from the source message before the mapping step; these are then transformed differently depending on the receiver interface. Therefore it is conceivable to write the mappings in such a way that the first mapping from the source message generates a message that only contains the first item, the second mapping generates a messages that only contains the second item, and so on. However, this no longer works if the number of items can vary with each new source message.
You can use an enhanced interface determination to configure a mapping-based message split for this usage case. You assign the interface determination a multi-mapping that has a target interface with an element with occurrence 0...unbounded. At runtime, the individual messages (for the individual items) are calculated in the mapping step. First, the individual messages are grouped into a bulk message. Then, the bulk message is transferred to the Adapter Engine. The Adapter Engine then splits the bulk message up into the individual messages (see figure).
Procedure at Runtime During Message Split
Note that both the bulk message and all individual messages each have a message header with a receiver interface (see figure).
Receiver Interfaces of Bulk Messages and Individual Messages
The header of the individual messages contains the relevant receiver interface. It is based on the definition of the multi-mapping. Note that the receiver interfaces of the individual messages may be different. The receiver interface of the bulk message is always InterfaceCollection (namespace http://sap.com/xi/XI/System).
If the message split only results in one message, the original message structure remains the same. In this case, a bulk message containing just one individual message is not created.
You can also assign a multi-mapping with multiple different target interfaces to an enhanced interface determination (1:n transformation). Each target interface can contain elements with occurrence 0 ... unbounded.
Messages cannot be sent by using different Adapter Engines in a mapping-based message split. This affects configuration thus: All receiver agreements that have a receiver interface from the mapping entered in the key must only be assigned communication channels with the following adapter types:
- RFC adapter
- SAP Business Connector adapter
- File/FTP adapter
- JDBC adapter
- JMS adapter
- SOAP adapter
- Marketplace adapter
- Mail adapter
- RNIF adapter
- CIDX adapter
The adapters also have to all run on the same Adapter Engine.
Adapters developed by partners also support a mapping-based message split if they run on the same Adapter Engine.
Attachments from the original message are not appended to the messages resulting from the message split.
Activities
To execute a mapping-based message split, perform the following steps:
1. Integration Repository: Define the multi-mapping (see Developing Multi-Mappings for Message Splits).
2. Integration Directory: Define the interface determination.
Note the following:
○ The outbound interface of the multi-mapping must be entered as the sender interface in the key of the interface determination.
○ The interface determination type must be set to Enhanced.
○ Select the multi-mapping you defined previously from the Integration Repository.
To select the interface mapping, use the input help ( ).
The target interfaces of the interface mapping are displayed in the Inbound Interfaces frame.
The number of messages (for an inbound interface) created in the mapping step is displayed in the Occurrence column.
regards,
Raj -
Interface mapping in Interface Determination??
Hi friends..
iam doing IDOC to File..
in message mapping ,i changed the occurance of IDOC to unbounded and did the same in interface mapping also..
but in intrerface determination i am not getting Interface mapping ,i tried Extended interface mapping also..
please suggest me..
thanks and regards
RamHi,
MultiMapping will not work for IDoc's.You need to use Idoc packaging for this,
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/877c0d53-0801-0010-3bb0-e38d5ecd352c
Is this what you have done?
Regards
Bhavesh -
How to add Two Interface Mappings to One Receiver(BPM) Help needed urgently
I have a requirement where i get a flat file and split into multiple files and send to BPM.
For each split file I created Interface Mapping using Java Mapping Program.
In the Configuration how to add more Interface Mappings?
Thanks for your help in advance.
Regards
SudhaYou can use Enhanced Interface Determination to split one message to Multiple hence to multiple Interfaces.
You have to change the Occurance of Messages in Message Mapping and their Corresponding Interfaces in Interface Mapping. That would create Multiple Files with Multiple Interfaces to Receiver (BPM)
1) You need not to use Multilpe Interface Mapping
2) You will use Extended Interface Determination for this.
regards.
Jeet. -
Generic classes with parameterized super class and interface
Hello.
I'm trying to write a generic class that looks like the following pseudo-code.
public interface Interface {
public Interface getSibling(...);
public class Klass {...}
public class MyKlass<T extends Klass, T2 extends Interface>
extends T implements T2 {
public T2 getSibling(...) {
return this;
}where Interface and Klass each have various extensions.
I came across this problem, or challenge, while writing classes for testing my EJBs. I tried and failed various attempts.
Is it possible to write generic classes of this nature in Java?
If so, please tell me and others who are like me.
Thanks in advance.No. That would not work.
Beside being forbidden by the compiler, to my understanding, it cannot be done in theory either, as the parameterized types get bound at instantiation time and are not available for static reference, which both extends and implements require.
Maybe you are looking for
-
Step 5. 5. We need additional time to process your transaction You should get an email from us by next business day. If you don't hear back from us, you can check your order status on your account page or call us at +1 800-585-0774. If you're not in
-
Can I access WorkFlow Container Data After Archiving?
Hello ..... I am tasked to Archive thousands of old WorkFlows that are cluttering up our system and are beginning to cause performance issues. I have managed to Archive some WorkFlows in our DEV system with Tcode SARA. My question is .... Can I still
-
Call a adf form from oracle forms 11g
Hallo, I want to call a form developed in ADF from my existing oracle forms mask and then back from ADF form to the oracle forms mask. It this possible? Have everyone a how to for this problem? Thanks for your help Ines
-
Convert Windows license to Mac
I purchased Adobe X Windows last June. but just converted to a MAC. Can I use the same license?
-
10.4.9 and FireWire instability
After updating (DiskPermissions, ComboUpdater, DiskPermissions), I have notized both FireWire and Finder instability. FireWire loses mounted volumes/printers and after that the Finder doesnt response forcing me to use the PowerButton powe-off. Has an