Interface Pattern "Stateful"

Hi,
I was wondering about the interface pattern "stateful" that is available in ESR of PI 7.1. I already read all the information in [this|Re: Query in PI7.1 Service Interface] post but still don't know when to use it? Can anyone maybe give an example on when to use this interface pattern instead of for example the TU&C/C pattern?
In all the information given it always says that stateful can either be provided by the messaging runtime or not. Which runtimes do support this? Integration Engine, local WS-Runtime? And if so starting with which version are they supported?
Thanks a lot,
Manfred

Very good description was found here: https://ecohub.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/b0f371e9-18d0-2b10-bbb4-ecc935ddb732.

Similar Messages

Static Interface Pattern

Summary
=======
Define an interface which declares static methods.
The essence of what I mean by this is: define a number of classes which contain/provide access to common methods to which we can make static calls.
Details
=======
What we are trying to achieve here is effectively an interface which garuantees us that the classes of a particular type (with a common parent class/interface) will all contain a specific method to which we have static access.
Simple example
==============
Here we have two classes that implement the Animal interface (Dog and Cat). Each class supplies a static method getType() which returns some non-instance-specific information (this method is static because the type is the same for all instances of the given class. E.g. ALL Dogs are of type 'Doggy').
interface Animal
class Dog implements Animal
    public static String getType()
        return "Doggy";
class Cat implements Animal
    public static String getType()
        return "Kitty";
}The problem is: How can we garuantee a client application that all Animals will supply (in some way) this static method.
[In this particular example the methods differ only in the information they return, but the solution should allow the implementation of these methods to differ too].
Thanks for your thoughts.
JohnSenford [@hotmail.com]

interface Animal
class Dog implements Animal
     public static final String getType = "Doggy";
//    public static String getType()
//        return "Doggy";
class Cat implements Animal
      public static final String getType = "Kitty";
//    public static String getType()
//        return "Kitty";
or maybe an abstract base class;

Stateful message processing for async scenario

Dear all,
my async scenarios:
1. RFC -> PI -> File
2. File -> PI -> RFC
Following facts:
- The second message is a response to the first one. Both message are separted and async.
- Scenario 2 can be send some hours after Scenario1.
- A response should only be send if a specified field in the message of first scenario is filled.
For example: Message in scenario has a field <ResponseNeeded>YES</ResponseNeeded>
This field does only exist in message of scenario 1.
- Both message have an ID field (e.g. <ID>4711</ID>) which can be used to identified the
corresponding message.
Questions:
- Is it possible to use stateful message processing for this scenario? Or do I need BMP + Correlation?
- A service interface with pattern "stateful" can only be used synchronously. So is it
possible to use this stateful for async message processing at least?
I would assume that I will need a BPM that sends the messsage and keep alive until a
response will be sends with same ID. After this I would check message of scenario1 and
send (or even not) the message of scenario2 to receiver depending on <ResponseNeeded>.
Thanks in advanced.
Chris

Hi Chris,
Although BPM is possible here, I would not recommend you to use one here for the reason,
>>Scenario 2 can be send some hours after Scenario1.
This means you are keeping a process alive for so long which is not a good thing to do.
You could end up with a lot of open/live process instances.
Having said that, if you still wish to go ahead with BPM, the steps would be
1. Receive async (RFC req) - start process, correlation based on ID.
2. Switch step (Evaluate ResponseNeeded)
branch 1(True): a. Send asynch step - File
b. Receive async - File correlation - ID.
c. Send async - RFC call.
branch 2(false) a. Send async -File
3. Stop process.
Regards
Jai

When do remote interface get invaliated? Can I cache them?

Hello,
I am designing an application, and considering using the "Service Locator" pattern, acting as a singleton that will cache jndi context, and bean home and remote interfaces. However I am unsure whether caching of remote interface is a problem or not:
1) Under what circumstances will the cached remote interface for a stateless session bean be invalidated?
2) Under what circumstances will the cached remote interface for an Entity Bean be invalidated?
3) Assuming that I cache Stateful session bean remote interfaces in a Servlet HTTPSESSION, under what circumstances will the cached remote interface for Stateful session bean be invalidated?
4) Finally, do I have to utilise home handles instead of remote interfaces for any of these situations? If so, why?
Thanks

I understand that caching the Home Interface or HomeHandle of this, is the solution for
reconnection to EJB's problems.
But I do not succeed in getting a working solution for handling the reconnection
to a restarted EJB server after some downtime.
First the HomeHandle of the Home Interface is successfully saved with:
"myHomeHandle = myHome.getHomeHandle();"
Later the HomeHandle is used to restore the Home Interface with:
"MyHome myHome = (MyHome) myHomeHandle.getEJBHome();"
But this gives an Exception like
Caused by: javax.naming.NoInitialContextException: Need to specify class name in environment or system property,
or as an applet parameter, or in an application resource file: java.naming.factory.initial
I have followed the recommandations in this postings, but in some way I lack a bit information.
Has somebody a code example in Java of how to do this?
Here is my code which throws the exception
InitialContext context = new InitialContext( properties );
Object obj = context.Lookup( "My" );
MyHome myHome = (MyHome) PortableRemoteObject.narrow( obj, MyHome.class );
myBean = myHome.create();
myHomeHandle = myHome.getHomeHandle();
// At this point everything fine, and a myBean is created.
// Now I try to recreate the myHome Interface
MyHome myHome = (MyHome) myHomeHandle.getEJBHome();
// In order to (re)create the myBean EJB.
myBean = myHome.create();
// But the second create is never executed, as the method call "...myHomeHandle.getEJBHome();"
throws the above Exception.
So, any help I will Appreciate.

Right way of defining constants - Interfaces or Classes?

Two widely used ways to define constants in java projects are:
1. Interfaces - Define constants in interfaces, they automatically become static, final and then implement the interface in concrete classes that need those constants.
2. Classes - Use normal classes and define explicitly as static, final. Use CLASS_NAME.CONSTANT_NAME to access the constant in concrete classes.
I have gone through the web on Best-practices for defining constants and its strongly recommended for not using Interfaces for defining constants.
"The constant interface pattern is a poor use of interfaces. That a class uses some constants internally is an implementation detail. Implementing a constant interface causes this implementation detail to leak into the class's exported API. It is of no consequence to the users of a class that the class implements a constant interface. In fact, it may even confuse them. Worse, it represents a commitment: if in a future release the class is modified so that it no longer needs to use the constants, it still must implement the interface to ensure binary compatibility. If a nonfinal class implements a constant interface, all of its subclasses will have their namespaces polluted by the constants in the interface. " from Effective Java, Joshua Bloch
What is your take on this?
Rgds

I have gone through the web on Best-practices for defining constants and its strongly recommended for not using Interfaces for defining constants.
"The constant interface pattern is a poor use of interfaces. That a class uses some constants internally is an implementation detail. Implementing a constant interface causes this implementation detail to leak into the class's exported API. It is of no consequence to the users of a class that the class implements a constant interface. In fact, it may even confuse them. Worse, it represents a commitment: if in a future release the class is modified so that it no longer needs to use the constants, it still must implement the interface to ensure binary compatibility. If a nonfinal class implements a constant interface, all of its subclasses will have their namespaces polluted by the constants in the interface. " from Effective Java, Joshua Bloch
I don't like grouping constants into an interface. I prefer keeping them closer to the classes that use them.
%

PI 7.1 "stateless" service interfaces prerequisites and limitations

are there any prerequisites and limitations for "stateless" Service interfaces.
We are directly implementing PI 7.1, (i.e not upgrading form 7.0 or 3.0).
so for all our service interfaces, shall we safely use tne interface pattern "statelss" instead of "Stateless(xi 3.0 compatible)".
if use the "stateless", are there any addition prerequisites or constraints/limitations.
can we use abap proxies, java proxies, providing webservices via xi, and consuming other webserivces in xi, all adapters, asynch, synch scenarios with "stateless" interface patterns.
In short, are there any things that can be done using "Stateless(xi 3.0 compatible)" and cannot be done using "stateless" interface
are there any specific requirements for using "Stateless(xi 3.0 compatible)" even in newly implemented PI 7.1
thanks in advance,
Madhu.

When it is an upgrade from 7.0 to 7.1 the default Interface pattern is Stateless (XI 30 Compatible)
Using Stateless Interface Patterns wont cause any harm/ restriction on any of the development.
The only twist will be in the way a condition is specified in the Receiver Determination.
For any Interface pattern (other than Stateless(XI30 Compatible)) you wont be able to see the message structure in the Condition Editor of Receiver Determination. All other functionality (Async, Sync, Proxy) will be available.
In such a case Condition should be specified as shown in this blog: /people/abhishek.salvi/blog/2009/07/15/sap-pi71-receiver-determination-xpath-and-you
Regards,
Abhishek.

In PI 7.1, condition editor does not show the outbound interface structure

Hello,
I am using PI 7.1, I need to use condition whild determing receivers. So I opened the condition editor, then open the expression editor, select XPath instead of Context object. I would expect that the outbound interface structure appears in the box underneath the XPath, so that I can navigate the structure to choose the field I want to use. However nothing appears here. Do you knwo why is that? Or do I need to do anything to bring up the outbound interface structure in the expression editor?
Thanks
Jayson

Hi Jayson,
I had the same problem
the use of context objects and the value help for xpath is available for XI3.0 interfaces in PI 7.10 only. The functionality for "new" interfaces has been implemented in 7.11 only.
you have to use xpath w/o value help.
I have created a context object in one of our 7.10 test systems, and indeed I was unable to use it in a receiver determination unless the service interface pattern is "Stateles (XI 3.0 compatible)". If you were to change the service interface to that pattern, you have to change the operation name unless it is already identical to the interface name. So that may not be an option for you.
It was possible to use the context object in a receiver rule but then I could not activate the receiver determination because the software component version was supposedly unknown. I will check with my PI contacts - please let me know if the change to "XI 3.0" interface would be a possible workaround for you.
Try the steps which I am giving below, although it's a workaround and don't know the exact reason why it is failing.
1. Open your Outbound Message Interface (which you are using in your Receiver Determination) in IR, edit it and change the Interface pattern (which is there just below the category "Outbound") to "Stateless (XI30 - Compatible)" , save it activate it.
2. Follow the same step for your Inbound Message Interface. Change the Interface Pattern from "Sateless" to "Stateless (XI30 - Compatible)" .
3. Go to ID. Remove your Outbound and Inbound Message Interface from their respective Business Service/Comp and add it again.
4. Create your your receiver determination again using the Outbound and Inbound MI you have changed.
5. Open condition editor of your receiver determination.You should be able to see your Message Interface and can choose the XPath.
Thanks,
Raj
Edited by: raj reddy on Jan 21, 2009 5:41 PM

SOAP Sender with additional header: Interface determination error

Hello Experts,
I need to implement a scenario where in sender will add custom header fields and in PI, the values needs to captured. Second step: Based on the custom header value, the receiver needs to be determined.
Scenario: SOAP Sender -> PI -> SOAP Receiver
Request Message:
<RequestMsg>
     <request>
          <Field 1>...</Field 1>
          <Field 2>...</Field 2>
          <Field 3>...</Field 3>
     </request>
</RequestMsg>
Without any custom SOAP header, I have created Request / Response Message, Message Mapping, Service Interfaces (Inbound & Outbound) and Operation Mapping and tested the scenario by triggering call through SOAP UI, it works fine. SOAP Request XML looks like below:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:v1="http://www.test.abc.com/v1">
    <soapenv:Header />
    <soapenv:Body>
      <v1:RequestMsg>
         <request>
              <Field 1>1</Field 1>
               <Field 2>2</Field 2>
               <Field 3>3</Field 3>
         </request>
      </v1:RequestMsg>
   </soapenv:Body>
</soapenv:Envelope>
To use customer fields in SOAP Header, I have checked the option "Do Not Use SOAP Envelope" in the SOAP Sender CC and added "&nosoap=true" to url. SOAP Request XML looks like below:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:v1="http://www.test.abc.com/v1">
    <soapenv:Header >
          <id>REC1</id>
     </soapenv:Header >
    <soapenv:Body>
      <v1:RequestMsg>
         <request>
              <Field 1>1</Field 1>
               <Field 2>2</Field 2>
               <Field 3>3</Field 3>
         </request>
      </v1:RequestMsg>
   </soapenv:Body>
</soapenv:Envelope>
Now, when I invoke the url, I see that the message reaches PI but it throws error: RoutingException: InterfaceDetermination did not yield any actual interface
Please note that I have added a Java Mapping before main message mapping to read the soap header and pass only the request message to the next message mapping.
I am sure, I am missing important steps in the configuration. Please help me in reolving the issue.
Thanks & Regards,
Ankit Srivastava

Hello Hareesh,
Bingo! The second option suggested by Nicolas worked like a charm. I am just copying the same here:
-----In ESR, you set the attribute "Interface Pattern" of the outbound service interface as "Stateless (XI30-compatible)", which does not use operations.----
Thanks a lot. Now, I will be able to concentrate on the next steps.
Regards,
Ankit Srivastava

Share stateful session bean in JSF managed beans with different scope

Hi,
I have a JSF application and I want to try to use of stateful session beans.
So I created a new stateful session bean and its local interface.
@Stateful
public class StatefulSessionBean implements StatefulSessionBeanLocalInterface{
private String name;
@Local
public interface StatefulSessionBeanLocalInterface {
...In my JSF application I have a mananed bean with session context which registers the new interface by
this annotation
@EJB(name="sessionbeanref", beanInterface=StatefulSessionBeanLocalInterface.class) and set the name to something.
Now I want to fetch this name in another managed bean with request scope. So I looked up the bean and tried to get the name.
StatefulSessionBeanLocalInterface = (StatefulSessionBeanLocalInterface) new InitialContext().lookup("java:comp/env/sessionbeanref");
System.out.println(currentmailingbean.getName());but the name is null.
Why?

The xsd was created via the netbeans J2EE enterprise application dialog and I think its the most recent.
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">All other annotations seem to work.
Wouldnt the lookup completely fail if the deployment process thought that it is version 1.4 ?

Regarding Message Interface , Service Interface

Hi All
My scenario is File to File from 1 application server to another application server ,without any transformation in PI 7.1 for service interface to be involved for Interface Pattern Stateless and Stateless (XI 3.0) compatible can only be used with Category Abstract
only abstract catgory is possible , can'nt i make 1 outbound & another inbound for this ?
Regards
Abhishek
Edited by: Abhishek Agrahari on Feb 9, 2009 11:08 AM

Search SDN for this there is Blog for this i dont have info on this
Need to do follwoing in the ID
1. Sender and receiver Business system/services
2. respective File communication channels
3. Receiver Agreement
4. interface determination
5. Finally receiver agreement and sender agreement
Rajesh

Multiple Operation in Service Interface

Hi Experts,
Here is the problem -
Scenario: SOAP Adapter-> PI (7.1) -> XI Adapter -> ERP Proxy
We have defined multiple operation in Service Interface using Interface pattern "Stateless".
Message posted using SOAP adapter goes through PI alright. But on ERP is throws the error saying "No implementing class registered for the interface"
Well the checklist-
1. Proxy class generated/re-generated. Class/Interface/Methods all activated.
2. If I remove all the operation from Service interface and just have one with the same name as Service Interface (which is also default when you create new service interface) it works fine.
Any idea guys ?
Regards.

Hi Sreenivas,
I appreciate your promptness in answering the query.
1. And I know that if you select Stateless (XI 3.0), in the service interface you just can't have multiple operations.
2. ID contents are generated fine (I dont do it manually. I just import the scenario from ESR).
Please, first test yourself and let me know if you succeed or point me to some document explaining that.
Regards.

Several inbound interfaces in intagrated configuration

Hi all,
I want to use an intagrated cnfiguration object for scenario with several inbound interfaces on a receiver side. As for now, I have a usual condition-based interface determination for my receiver system. I've studied all features of "Revceiver Interfaces" tab in IC object as well as corresponding documentation, but found no way to use 2-3 inbound interfaces with conditions for same receiver.
So the question is: how can we use IC object to have several interfaces on receiver system? I'm talking not about message split, since it's impossible for IC, but about interface determination based on message content.
Thanks!
Dmitriy

Hello
So the question is: how can we use IC object to have several interfaces on receiver system? I'm talking not about message split, since it's impossible for IC, but about interface determination based on message content.
Yes, it is possible to use several interfaces on a receiver system. The key here is to group your message types/ed/wsdl under a single outbound interface. You can do this by:
1.) In your outbound service interface, use Stateless as your interface pattern
2.) Then under the operations tab, add as many operations as you need. For example, operation1 uses mestype, operation2 uses xsd, and operation 3 uses wsdl and so on...
3.) Configure your inbound service interface, you can separate them or group them as you like (it depends if they will be using different comm channels) For example, operation 1 can use inbound service interface 1, operations 2 and 3 can use inbound service interface 2
4.) Configure operation mappings (per operation).
5.) After cofiguring your comm channels, create the integrated configuration
6.) Make sure you have a value under the Select Component Version of Sender Interface.
7.) Your created operation mappings will appear under the receiver interfaces
8.) And under outbound processing, there will appear the inbound service interfaces
I hope I have explained this clearly.
Regards,
Mark
Edited by: Mark Dihiansan on Aug 23, 2011 9:15 AM

MARKER INTERFACE WHY?

hello i madhav new to this forum , i have doubt on marker interface . as it doesnot have any body why we r using that one instead of skipping.Is there any concept behind is there.More about my doubt is Take Example Cloneable Interface it Doesn't Have any Method In it,Clone() method is from Object class,then what is the necessity of implementing the interface .Why it should not be like that.
what is real technolgy behind MarkerInteface and Why we r going to be used in what situations it will needed.And Lastly is there any method related to Serailizable interface if not what it do .
marker interface can also called as Tag interface what is tag mean here just saying combing derived classes . i didn't get that one and how it will be .
if u could explain with example or real time project it would be better for me
thanks in advance

What is a "marker" interface?
Marker Interface pattern
c2.com - Marker Interface
experts.about.com - Marker Interfaces
The Purpose of the Marker Interface
Maximize your Design ROI with Marker Interfaces and JavaDoc

Problem in Interface

Hi,
I doubt in Interface.
Interface means : Only Method declaration & static final variable, there is no implementation of the methods. When we use it in the class, then we have to implement that method in our class, insted of that we can directly write that method.
Regards
DRA

Interfaces are also commonly used to holdconstants.
This is a bad idea.Here's one explanation why:
Effective Java - Joshua Bloch, Chapter 4, Item #17: Use interfaces only to define types.
The constant interface pattern is a poor use of interfaces. That a class uses some constants internally is an implementation detail. Implementing a constant interface causes this implementation detail to leak into the class's exported API. It is of no consequence to the users of a class that the class implements a constant interface. In fact, it may even confuse them. Worse, it represents a commitment: if in a future release the class is modified so that it no longer needs to use the constants, it still must implement the interface to ensure binary compatibility. If a nonfinal class implements a constant interface, all of its subclasses will have their namespaces polluted by the constants in the interface.

The interface .... cannot define an initializer

Why I can't do it:
public interface Constants
   java.util.HashMap BASE_HOLDERS = new java.util.HashMap();
   static
      BASE_HOLDERS.put("key1", "value2");
      BASE_HOLDERS.put("key2", "value3");
and receive: The interface Constants cannot define an initializer?
I don't want to have class (only interface). May you give me and advice?

That said, interface constants are an anti-pattern, if that's the route the OP is heading...
Effective Java - Joshua Bloch, Chapter 4, Item #17: Use interfaces only to define types.
The constant interface pattern is a poor use of interfaces. That a class uses some constants internally is an implementation detail. Implementing a constant interface causes this implementation detail to leak into the class's exported API. It is of no consequence to the users of a class that the class implements a constant interface. In fact, it may even confuse them. Worse, it represents a commitment: if in a future release the class is modified so that it no longer needs to use the constants, it still must implement the interface to ensure binary compatibility. If a nonfinal class implements a constant interface, all of its subclasses will have their namespaces polluted by the constants in the interface.
In summary, interfaces should only be used to define types. They should not be used to export constants.
~

Interface Pattern "Stateful"

Similar Messages

Maybe you are looking for