Acknowledgement vs Durable

Could someone help me understand the difference between Acknowledgement modes and Durable subscripton. Below is what I understand and my questions are:
Say, I use auto_acknowledge then what happens if I dont get any acknowldgement? Yes, the msg is resent but what if acknt is never received even after resent? How long is the wait untill the msg is resent? Is the msg removed from server after some time? Is durable subscription a solution for this?

Durable subscriptions don't have different acknowledge behavior than non-durable subscriptions.
          To get started with JMS, I suggest reading through the BEA JMS developer documentation, and also the JMS info in one of the books listed here:
          http://dev2dev.bea.com/jms/index.html
          Also start here for the various options available for controlling redelivery:
          http://edocs.bea.com/wls/docs92/jms/manage_apps.html#ManagingRolledBackRecoveredRedeliveredorExpiredMessages

Similar Messages

JDBC, JMS and EJB transactions - possible problem?

Hello,
          I am using Oracle 9, Weblogic 8.1 SP 4, MyEclipse and
          XDoclet.
          In my current project I have the following piece of code
          in one of my message driven beans (code cited as pseudocode
          without unnecessary details):
          * @ejb.bean name="MyMessageProcessor"
          * display-name="Display name for a MyMessageProcessor"
          * jndi-name="ejb/MyMessageProcessor"
          * description="Bean MyMessageProcessor"
          * destination-type="javax.jms.Queue"
          * transaction-type="Container"
          * acknowledge-mode="Auto-acknowledge"
          * subscription-durability="Durable"
          * generate="false"
          * @ejb.transaction type="Required"
          public class MyMessageProcessor implements MessageDrivenBean, MessageListener {
          public void onMessage(Message msg) {
               try {
                    //obtaining connections to two different databases via JNDi
                    java.sql.Connection connOne =
                    ((DataSource)ctx.lookup("DataSourceOne")).getConnection();
                    java.sql.Connection connTwo =
                         ((DataSource)ctx.lookup("DataSourceTwo")).getConnection();
                    // performing some UPDATEs and INSERTs on connOne and connTwo
                    // calling some other methods of this bean
                    //creating the reply JMS message and sending it to another JMS queue
                    Message msgTwo = this.createReplyMessage(msg)
                    this.queueSender.send(msgTwo);
                    //commiting everything
                    this.queueSession.commit();
               } catch (Exception ex) {
               try {
                    if (this.queueSession!=null) this.queueSession.rollback();
               } catch (JMSException JMSEx) {};
               this.context.setRollbackOnly();
          Some days ago (before the final remarks from my client) there used to be only one DataSource configurated on the basis of the
          connection pool with non-XA jdbc driver. Everything worked fine
          including the transactions (if anything wrong happend not only wasn't the replymessage sent, but also no changes were written
          to database and the incomming message was thrown back to the my bean's
          queue).
          When I deployed the second DataSource I was informed by an error message, that only one non-transactional resource may
          participate in a global transaction. When I changed both datasources
          to depend on underlying datasources with transatcional (XA) jdbc drivers, everything stopped working. Even if
          EJB transaction was theoretically successfully rolledbacked, the changed were written to the database
          and the JMS message wasn't resent to the JMS queue.
          So here are my questions:
               1. How to configure connection pools to work in such situations? What JDBC drivers should I choose?
               Are there any global server configurations, which may influence this situation?
               2. Which jdbc drivers should I choose so that the container was able to rollback the database transactions
               (of course, if necessary)?
               3. Are there any JMS Queue settings, which would disable the container to send message back to the
               queue in case of setRollbackOnly()? How should be the Queue configurated?
          As I am new to the topic and the deadline for the project seems to be too close I would be grateful
          for any help.
          This message was sent to EJB list and JDBC list.
          Sincerely yours,
          Marcin Zakidalski

Hi,
          I found these information extremely useful and helpful.
          The seperate transaction for sending messages was, of course, unintentional. Thanks a lot.
          Anyway, I still have some problems. I have made some changes to the
          code cited in my previous mail. These changes included changing QueueSessions
          to non-transactional. I also set the "Honorate global transactions" to true.
          I am using XA JDBC driver. After setting "Enable local transactions" to false
          (I did it, because I assume that JDBC transactions should be part on the global
          EJB transaction) I got the following error:
          java.sql.SQLException: SQL operations are not allowed with no global transaction by default for XA drivers. If the XA
          driver supports performing SQL operations with no global transaction, explicitly allow it by setting
          "SupportsLocalTransaction" JDBC connection pool property to true. In this case, also remember to complete the local
          transaction before using the connection again for global transaction, else a XAER_OUTSIDE XAException may result. To
          complete a local transaction, you can either set auto commit to true or call Connection.commit() or Connection.rollback().
          I have also inspected the calls of methods of bean inside of onMessage() method just to check, whether
          the transactions are correctly initialized (using the weblogic.transaction.Transaction class).
          My questions are as follows:
          1. Any suggestions how to solve it? I have gone through the google answers on that problem and only
          thing I managed to realize that JDBC must start its own transaction. Is there any way to prohibit it
          from doing that? Can using setAutocommit(true/false) change the situation for better?
          2. How to encourage the JDBC driver to be a part of EJB transaction?
          3. As I have noticed each of ejb method has its own transactions (transactions have different
          Xid). Each method of the bean has "required" transaction attribute. Shouldn't it work in such
          way that if already started transaction exists it is used by the called method?
          4. The DataSources are obtained in my application via JNDI and in the destination environment I will have slight
          impact on the configuration of WebLogic. What is least problematic and most common WebLogic configuration which would
          enable JDBC driver to participate in the EJB transaction? Is it the WebLogic configuration problem or can it be
          solved programmically?
          Currently my module works quite fine when "enable local transactions" for DataSources is set to true, but this way
          I am loosing the ability to perform all actions in one transaction.
          Any suggestions / hints are more than welcomed. This message was posted to jdbc list and ejb list.
          Marcin

Do I really need two connection pools when using two durable subscriptions?

I have a Spring daemon which takes messages from two different topics and stores them in a database.
What irritates me is that I can't get it to work with a single connection pool. I get a message that I can't create durable subscriptions without a unique client id on the connection. It's not enough that the client id be set on the listener container, I have to set it on the underlying ConnectionFactory. I though this was some kind of glitch with openMQ but activeMQ gives me exactly the same behaviour.
This is the important part of the config
    <bean id="realCon" class="org.apache.activemq.ActiveMQConnectionFactory" p:brokerURL="discovery:(multicast://default?group=live)"
    p:clientID="DB_RECORD_CLIENT"/>
    <bean id="realCon2" class="org.apache.activemq.ActiveMQConnectionFactory" p:brokerURL="discovery:(multicast://default?group=live)"
    p:clientID="DB_LOG_CLIENT"/>
    <bean id="jmsConnectionFactory" class="org.springframework.jms.connection.CachingConnectionFactory"
    p:targetConnectionFactory-ref="realCon"/>
    <bean id="jmsConnectionFactory2" class="org.springframework.jms.connection.CachingConnectionFactory"
    p:targetConnectionFactory-ref="realCon2"/>
    <bean id="ocsMessageListener" class="com.cc.mer.ordercatcher.MessageReceived"/>
    <bean id="logMessageListener" class="com.cc.mer.ordercatcher.LogMessageReceived"/>
    <jms:listener-container
        connection-factory="jmsConnectionFactory"
        destination-type="durableTopic"
        transaction-manager="transactionManager"
        acknowledge="transacted"
        >
        <jms:listener ref="ocsMessageListener" destination="OCS_RELAYED"
                      subscription="ocs.db.recording" />
    </jms:listener-container>
    <jms:listener-container
        connection-factory="jmsConnectionFactory2"
        destination-type="durableTopic"
        transaction-manager="transactionManager"
        acknowledge="transacted"
        >
        <jms:listener ref="logMessageListener" destination="OCS_LOG"
                      subscription="ocs.log.recording" />
    </jms:listener-container>

Thank you all for your replies.
Yesterday, I went back to BestBuy and returned the Gigabit Ethernet Switch and exchanged it for a Belkin Share Max N300 router. I chose this one because I want to use the router in WIRED mode and this had a 10/100/1000Mbps Gigabit Ethernet capability. Most other routers that I looked at only had 10/100Mbps. I also liked that it had two USB ports.
I had to call Belkin tech support because the installer from the included CD would not install the software. Nor would the installer that I downloaded from their web site. I ended up actually having to be taken to the IP address' web site and from there I was able to configure everything.
Although it took me a few hours to get all my other wireless devices onto my wireless network (I have a couple of Airport Express(es) for running "Airplay," and a wifi dongle on my TV), things now seem to be working fine.

JMS Message Acknowledgement

Hi,
In my application I am using a Pub/Subscribe mode for JMS. I am using a durable subscriber. In the Subscriber side, I am opening a non-transacted TopicSession with Acknowledgement mode CLIENT_ACKNOWLEDGEMENT.
I have a Message listener which processes the message.
In my Message listener, I want to achieve the following...
Process the message, if processing succeeds, acknowledge the message. I am not acknowledging messages if the processing fails due to any reason..
Once, all the messages have been consumed, the program exits. While exiting the program, I am calling Message.recover() to put back unacknowledged messages back into the Topic...But I have observed the following problem...Say I receive the messages in the following order Message1, Message2, Message3.
Now if i don't acknowledge the Message3, and acknowledge the Message1 and 2...and the program exits...Then when the subscriber starts again, Message3 is still there in the Topic as it was not acknowledged...This is all goo...
Where is creates a problem is, say if I don't acknowledge the Message1 and acknowledge Message2 and 3 and the program exits...Now when the program exits, Message1 which was not acknowledged it also not present in the Topic...So acknowledging a message basically works like acknowledging all messages received prior to the particular message?? Is there a way to get around this problems? When I consume the messages in the Listener, can I put the messages that I don't want to acknowledge in a group or something like that? What I want to achieve is any message that is unacknowledged should be redelivered...How to achive that?
Thanks
surajit

As you assert, when you acknowledge Message2, you are also acknowledging all messages not previously acknowledged on the given session (I.E. Message1). That is, per the JMS Specification, how message acknowledgement works. There is no workaround as this is how it is designed.

Durable subscribers questions

Hello,
          I am building an application that has two WebLogic servers
          communicating certain information between them using JMS. I am using
          WebLogics implementation of JMS including destinations and messaging
          bridges.
          I am experiencing some problems.
          Server 1 takes files and puts them in a Stream Message and publishes
          them to a topic as shown here:
          Context context = new InitialContext();
          TopicConnectionFactory topicFactory = (TopicConnectionFactory)
          context.lookup(sourceDescriptor.getConnectionFactory());
          connection = topicFactory.createTopicConnection();
          session = connection.createTopicSession(false,
          Session.CLIENT_ACKNOWLEDGE);
          Topic topic = (Topic)
          context.lookup(sourceDescriptor.getTopicJNDIName());
          TopicPublisher publisher = session.createPublisher(topic);
          publisher.setDeliveryMode(DeliveryMode.PERSISTENT);
          StreamMessage message = session.createStreamMessage();
          for (int i = 0; i < files.length; i++)
          Loop through reading a set of files into the StreamMessage publishing
          each.
          publisher.publish(message);
          Topic config.xml
          <JMSTopic JNDIName="topic/topicName"
          Name="Topic Name" StoreEnabled="default"/>
          Destination config.xml
          <JMSBridgeDestination
          AdapterJNDIName="eis.jms.WLSConnectionFactoryJNDINoTX"
          ConnectionFactoryJNDIName="ConnectionFactory"
          ConnectionURL="t3://localhost:7001"
          DestinationJNDIName="queue/queueName" Name="Queue Destination
          Name"/>
          <JMSBridgeDestination
          AdapterJNDIName="eis.jms.WLSConnectionFactoryJNDINoTX"
          ConnectionFactoryJNDIName="ConnectionFactory"
          ConnectionURL="t3://machinename:8001"
          DestinationJNDIName="topic/topicName"
          DestinationType="Topic" Name="Topic Source Name"/>
          Messaging Bridge config.xml
          <MessagingBridge
          Name="The Bridge"
          QOSDegradationAllowed="true" QualityOfService="Duplicate-okay"
          SourceDestination="Topic Source Name"
          TargetDestination="Queue Destination Name" Targets="server1"/>
          Connection Factory
          <JMSConnectionFactory JNDIName="ConnectionFactory"
          Name="Server1 Connection Factory" Targets="server1"/>
          All settings in WebLogic are default for the configuration of this as
          far as I know.
          The bridge is using Duplicate Ok QOS at this point.
          This works like a charm as long as server which has the destination
          queue is up and running and has received messages in the past.
          The first problem is the first set of messesages are sent to the Queue
          on Server 2 but the MDB does not pick them up. I have left it running
          for an hour and these messages sit in the pending state for the
          monitoring of the Queue. In order to get this first set of messages
          to be processed I have to restart Server 2 at which point the initial
          messages are processed. Any subsequent messages are processed by the
          MDB immediately upon delivery. What is the cause of this and is there
          any way around having to restart after the first messages are received
          creating the file in the message store? Does this have anything to do
          with the fact that there is no file in the message store until the
          first messages are received and thus the MDB is not looking since
          there was nothing there on start up? This seems very odd....
          The second problem has to do with durability. I start Server 1 and it
          waits for a finish file and when it sees it it takes the files and
          puts them on the topic as described. As long as Server 2 is up and
          running at that time everything is fine. If However Server 2 is not
          running at that moment and is started at a later time then the
          messages seem to be lost. What could cause this? Is there any way I
          can visually see that the message is being held on Server 1? The
          bridge from this topic on Server 1 to the queue on Server 2 is
          configured on Sever 1 and you can see that it is working when Server 2
          is not running due to the connection refused messages the bridge
          throws. Is the bridge accepting the messages from the topic enough
          for the topic to decide it is done with them and delete them? Could
          the acknowledgement from the queue on another bridge for the same
          topic be confusing the topic and deleteing the message before all
          subscribers get it? This is a big issue since it seems that durabilty
          is only guarenteed when both servers are running and a message is
          created.
          Any help on this would be appreciated...If you wouldn't mind cutting
          and pasting any responses to my email as well it would be appreciated
          as I use google for groups and it has a long turn around.
          TIA...


Hi Kartheek,
Once we create a TOPIC in NWA.In durable subscribers tab subscription ID and Subscription name will be automatically created once you publish the message in to TOPIC.
check in NWA-->jms server configuration-->durable subscribers.
thanks
Purna

JMS Messages keep on growing for a Topic with non-durable consumers

I have a JMS Server whose "Messages Current" keeps on growing after every message send to the topic. All the consumers are non-durable. The session is a non-transacted session with Auto Accknowledge parameter. My client does recieve the message, but it does not go down from the "Messages Current" in the WLS console. Also once the server is restarted, the messages go down to 0.
I am using 9.2 SP2 on a Solaris environment.
Any insight would be helpful

It's possible that one or more the subscribers is stalled for some reason and so is not actually receiving and processing messages. This would cause messages to accumulate. You can examine statistics for individual consumers on the console to see if this is an issue.
Also, there could be a durable subscription on the topic left over from some previous application you used with the topic. There are statistics for these as well.
Yet another possibility is that the clients are receiving the messages but are failing to acknowledge/commit them. You wrote that the sessions are "auto-acknowledge" but they could accidentally be "transacted". Check to make sure that the first parameter passed to "createSession" is true (it should be false), and that the second parameter is set to auto-acknowledge.
Finally, if you happen to be using a distributed topic, keep in mind that if one of the topic members is unavailable/crashed/down messages will accumulate on the other distributed topic members until the unavailable member is restarted (at which point they will be forwarded to the restarted member).
Tom

Using MDBs for durable subscriptions

I need to be able to deploy my MDB as a durable subscriber i.e I have my MDB ubscribing to a Topic. For some reason if the application hosting the MDB(message driven bean) fails, I would like the JMS provider to republish all the messages that were already in the Topic in addition to those messages which might have been published when the MDB application was down.
I am trying to achieve this using Weblogic 7.0. The weblogic documentation says that messages will not be accumulated if the MDB using durable subscriptions is not deployed(which would be the case when the MDB application failed).
Any ideas on how I could design around this shortcoming within WLS?
Thanks
Ramdas

The WLS documentation for MDBs says :
"If your bean will demarcate its own transaction
boundaries, set the acknowledge-mode sub-element to
specify the JMS acknowledgment semantics to use. This
element has two possible values: AUTO_ACKNOWLEDGE (the
default) or DUPS_OK_ACKNOWLEDGE."Okay, I missed the part where you were specifying WLS. In the case quoted above, you will have to explicitly rollback the transaction and make sure that your MDB is set to transaction "Required" (or "RequiresNew").
I am not sure what you meant by "concurrency issues"
when using MDBs.
Please could you clarify.Sure, if your BMP, as called from the MDB, blows up, you rollback the transaction. Which means the EXACT SAME message that caused the error will get redelivered, based upon your server settings: either immediately or within the delay period.
This means that while your first MDB is (potentially) still dealing with whatever problems the message caused in the BMP, a second invocation of the MDB can be starting, albeit in another transaction. The state of your BMP could be undefined in this situation - which could cause an entirely different set of problems.
Even though you program EJBs as "single-threaded," you still have to consider the likelyhood of multiple invocations accessing/changing the same "piece" of data. Yes, that's what transactions are for - but there can be programmatic holes where this kind of situation can arise. You just have to be careful about what you're doing.

Acknowledge a sent message?

Hy,
I'am sending messages between servers. I know that when the message is received at the destination, the container acknowledges the producer telling him that the message has been received correctly. But is there a way for the programmer to know that when he send a msg from server A to server B, server B acknowledges server A after having received and processed the message?
When using MDB for sending & receiving messages in a Queue, is there a guarantee that when a message is sent, that same message will be delivered to its required destination?
thanks in advance

hi gulshan,
as you say, delivery guarantees in JMS only apply to the JMS server. i.e., a producer gets an acknowledgement, once the message has been successfully delivered to the server. since the server is using persistence, no messages can get lost and eventually a consumer can pick up the message.
if you want to be informed of this situation, where the ultimate receiver gets the message, you have two options (all this relies on persistent messages & durable subscribers):
1) use the JMS_ReplyTo header so that the consumer can acknowledge the original message at the JMS level with the producer. the consumer could produce the ACk once it has done all the necessary processing for the received message (ie., update of a database, etc)
2) check the JMS destination from the consumer for the disappearance of the just produced messages. this could then be interpreted to indicate successful pickup by a consumer. you wouldn't know whether the consumer has actually performed the necessary operations required by the message stimulus.
3) the arjunaMS provides an optional notification, when ALL durable subscribers on a topic have received a given message. a notification is then produced on a special destination to which the producer can be listening. again, this doens't give you control over whether the consumer has actually performed any necesssary actions. however, the advantage is that you know when all the subscribers listening to a topic have received a message.
hope that helps.
regards, thomas
www.arjuna.com

Commited transaction durability and DB_REP_HANDLE_DEAD

From the BDB 4.8 manual "Dead replication handles happen whenever a replication election results in a previously committed transaction becoming invalid. This is an error scenario caused by a new master having a slightly older version of the data than the original master and so all replicas must modify their database(s) to reflect that of the new master. In this situation, some number of previously committed transactions may have to be unrolled."
In the application I am working on, I can't afford to have committed transactions "unrolled". Suppose I set my application to commit transactions only when a majority of electable peers acknowledges the transaction and stop the application on a DB_EVENT_REP_PERM_FAILED event. Will that guarantee the durability of committed transactions and (equivalently) guarantee that no replica will ever see DB_REP_HANDLE_DEAD error (assuming absence of bugs)?
Also as I understand it DB_REP_HANDLE_DEAD errors should never be seen on the current the master, is this correct? Is there a way to register a callback with the Replication Manager
-Sanjit

I think it is important to separate the txn commit guarantees from the
HANDLE_DEAD error return. What you are describing mitigates the
chance of getting that error, but you can never eliminate it 100%.
Your app description for your group (all electable, quorum ACKs)
uses the best scenario for providing the guarantees for txn commit.
Of course the cavaets still remain that you run risk if you use TXN_NOSYNC
and if you have total group failure and things in memory are lost.
Also, it is important to separate making a txn guarantee at the master site
with getting the HANDLE_DEAD return value at a client site. The
client can get that error even with all these safeguards in place.
But, let's assume you have a running group, as you described, and
you have only the occasional failure of a single site. I will describe
at least 2 ways a client can get HANDLE_DEAD while your txn integrity
is still maintained.
Both examples assume a group of 5 sites, call them A, B, C, D, E
and site A is the master. You have all sites electable and quorum
policy.
In the first example, site E is slower and more remote than the other 4
sites. So, when A commits a txn, sites B, C, and D quickly apply that
txn and send an ack. They meet the quorum policy and processing
on A continues. Meanwhile, E is slow and slowly gets further and
further behind the rest of the group. At some point, the master runs
log_archive and removes most of its log files because it has sufficient
checkpoint history. Then, site E requests a log record from the master
that is now archived. The master sends a message to E saying it has
to perform an internal initialization because it is impossible to
provide that old log record. Site E performs this initialization (under the
covers and not directly involving the application) but any
DB handles that were open prior to the initialization will now get
HANDLE_DEAD because the state of the world has changed and
they need to be closed and reopened.
Technically, no txns were lost, the group has still maintained its
txn integrity because all the other sites have all the txns. But E cannot
know what may or may not exist as a result of this initialization so
it must return HANDLE_DEAD.
In the second example, consider that a network partition has happened
that leaves A and B running on one side, and C, D, and E on the other.
A commits a txn. B receives the txn and applies it, and sends an ack.
Site A never hears from C, D, E and quorum is not met and PERM_FAILED
is returned. In the meantime, C, D, and E notice that they no longer can
communicate with the master and hold an election. Since they have a
majority of the sites, they elect one, say C to be a new master. Now,
since A received PERM_FAILED, it stops. If the network partition
is resolved, B will find the new master C. However, B still has the
txn that was not sufficiently ack'ed. So, when B sync's up with C, it
will unroll that txn. And then HANDLE_DEAD will be returned on B.
In this case, the unrolled txn was never confirmed as durable by A to
any application, but B can get the HANDLE_DEAD return. Again, B
should close and reopen the database.
I think what you are describing provides the best guarantees,
but I don't think you can eliminate the possibility of getting that error
return on a client. But you can know about your txn durability on the
master.
You might also consider master leases. You can find a description of
them in the Reference Guide. Leases provide additional guarantees
for replication.
Sue LoVerso
Oracle

Persisted messages without durable subscriptions

Does weblogic JMS support PERSISTED MESSAGES without durable subscriptions. As per jms spec message persistence does make sense even without durable subscriptions in case when the JMS server fails before a message is sent and acknowledged.
          "A JMS provider must deliver a PERSISTENT message once-and-only-once. This means a JMS provider failure must not cause it to be lost and it must not deliver it twice."
          This implies that a persisted message will be persisted before sending and if JMS server fails, it resends the message to available consumers when server is back up and has nothing to do with durable/non-durable subscriptions.
          Please let me know what you guys think and if it is supported in weblogic JMS.
          Thanks,
          -Raj

- Topics require durable subcriptions to persist messages. This is a standard part of the JMS API. Nondurable subscribers have absolutely no need for persistence by definition - as such subscriptions exist solely for the life of the client's connection.
          - And yes, queues support persistence. This is required by the JMS spec, which BEA fully implements.
          - True "exactly-once" behavior usually requires the use of transactions in conjunction with JMS. This ensures that the message being processed and any related application work either atomically all fails or all succeeds.
          The above applies to all JMS vendors.
          Tom, BEA

I received the error (in iCal on my iMac): "The server responded with an error". The error message is very large, and if there is a way to acknowledge and close it I can't find it. Because this error message is open, I can't do anything in iCal. Any sugge

I received the error (in iCal on my iMac): "The server responded with an error". The error message is very large, and if there is a way to acknowledge and close it I can't find it. Because this error message is open, I can't do anything in iCal. Any suggestions on how I could kill this error message? Thanks.
iMac, Mac OS X (10.7.2)
Basically i tried to enter too much information into my calendar and it has crashed now i can not get rid of the error message or use the calendar can anyone help please

did you find ou how to get rid of it i can't

Logical system name for acknowledgement in BPM

Hi,
I have a szenario:
IDOC --> BPM --> MAIL
Inside BPM I check the message and depending on an xml-element I stop the process or I send the message by mail.
When I stop the process the BPM sends back an acknowledgement and in SXMB_MONI I can see an error of the acknowledgement:
"Sender Test_BPM_IDOC_TO_MAIL kann nicht in ein ALE Logisches System umgeschlüsselt werden" (Sender can not convert in a ALE logical system)
What can I do?
Possible Solution 1:
I can define my BPM "Test_BPM_IDOC_TO_MAIL" as a logical system (including WE20 for ALEAUD).
Possible Solution 2:
I can enter an existing logical system name in the "adapter specific attributes".
BUT it is not use the same logical system name twice (BAD ... or is there a workaround?
Is Solution 1) a common way?
Thanx
Regards
Wolfgang Hummel

Hi,
there are many ways:
some for aleaud are described in my book:
<a href="/people/michal.krawczyk2/blog/2006/10/11/xi-new-book-mastering-idoc-business-scenarios-with-sap-xi"><b>Mastering IDoc Business Scenarios with SAP XI</b></a>
>>>>Is Solution 1) a common way?
no this is not good a good idea
BTW
you can also supress aleaud raport IDX_NOALE
Regards,
michal
<a href="/people/michal.krawczyk2/blog/2005/06/28/xipi-faq-frequently-asked-questions"><b>XI / PI FAQ - Frequently Asked Questions</b></a>

Sender Mail Adapter, technical Acknowledgement

Hi all,
I have a SMTP --> XI --> Proxy Scenario. For the inbound message I get via SMTP, I'd like to send a technical acknowledgement back to the Sender (via SMTP, too). The acknowledgement has a specific message structure, for example it contains the DocumentID of the inbound message I get via SMTP.
My idea now is: Within ReceiverDetermination, I configure two receivers:
1. Backend system for the Inbound Proxy
2. original Sender System
Within Interface Determination, I'll do 2 mappings:
1. Mapping from source message to ABAP proxy interface
2. Mapping from source message to technical acknowledgement structure
Then, receiver agreements / receiver communication channels for both interfaces.
My question now is: is there a more elegant solution then doing the scenario like described above? Maybe something I can do in the Sender Mail Adapter to create the specific technical acknowledgement and sent it back to the sending application?
Best regards
Holger

Hi Holger !
XI supported acks are not available for your scenariom because the smtp/mail sender cannot request it.
http://help.sap.com/saphelp_nw04s/helpdata/en/f4/8620c6b58c422c960c53f3ed71b432/frameset.htm
You should create some kind of artificial ack, that should be part of your own protocol. What I meant with the SYNC proxy, is to use its response message as your own defined ack, because it is not supported as is.
If you call your proxy async, then you will not receive any feedback to use it as ack info.
Another idea could be to forget the ack per se, and just use define an alert in case of problems with the scenario to send a mail to the specified users.
Regards,
Matias

How to get Acknowledgement from legacy system in an Asynchronous scenario?

Hello Experts,
My current scenario is to send an invoice from ECC --> ABAP proxy --> PI --> webservice --> Legacy system & I need acknowledgement back to ECC system from legacy system. How SAP XI acknowledgements work in asynchronous scenarios?
Please guide.
Thanks & Regards,
Nidhi Kukreja

Hi nidhi,
please check following link
http://help.sap.com/saphelp_nw04/helpdata/EN/44/932e8896b610bbe10000000a422035/frameset.htm
Also check this one.
http://help.sap.com/saphelp_nw04/helpdata/EN/f4/8620c6b58c422c960c53f3ed71b432/frameset.htm
hope this helps..
- Deepak.

Logical system for IDoc acknowledgment?

Hi,
HTTP --> XI --> IDOC (with acknowledgment) is my scenario
whether the inbound and outbound parameters should be configured in the same logical system or in a different one (in transaction we20)
Thanks,
RPN

For IDOC acknowledgement ,go thru this and do the settings :
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f6d2d790-0201-0010-9382-b50b499b3fbe
This will help u :
Configuration Tips for a Business Service/Integration Process to send back ALE audit IDOC

Acknowledgement vs Durable

Similar Messages

Maybe you are looking for