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
    Shakif

    Hi,
    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.
    &#9675;     Enter the outbound interface of the interface mapping from step 1 in the key of the receiver determination as the outbound interface.
    &#9675;     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:
    &#9675;     The outbound interface of the multi-mapping must be entered as the sender interface in the key of the interface determination.
    &#9675;     The interface determination type must be set to Enhanced.
    &#9675;     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 PM

    Hi, 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.
    -Sudhansu

    Hi 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
    Nick

    My 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 Gagne

    Unfortunately 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 thanks

    Here'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

  • Interface extending Remote

    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,
    Fred

    the 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 PM

    jverd 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,
    Vinay

    Enhanced (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
    Ram

    Hi,
    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
    Sudha

    You 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