| Author |
Message
|
| msantos007 |
 Posted: Thu Aug 13, 2009 7:12 am Post subject: RFC Caching Data |
 |
|
Voyager
Joined: 20 Dec 2004
Posts: 78
|
Hi everyone,
I got a problem using WMB 6.1.0.3 and Websphere Adapter For SAP (shipped with WMB).
I need to call an RFC into SAP in this RFC to retrieve the weight of a material type. The RFC works fine, and WMB has no problems executing it.
The only thing that is causing some trouble is that, even if some user updates the data in SAP table, I got the old weight. And, if I execute the same RFC connected as a dialog user, the value returned is the same on the table. If I restart WMB, or redeploy the .outadapter component, then, WMB gets the new weight, updated in the table.
It seems that or the adapter or SAP is somehow caching data for a connection.
Did anyone get this behavior?
Is it a problem with SAP or with the adapter? Is there any configuration I can do in the adapter to solve this?
Thanks
Max
_________________
Maximiliano R. A. Santos
IBM Websphere MQ V6.0 Certified System Administrator
IBM Websphere MQ V5.3 Certified Solution Developer |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu Aug 13, 2009 2:58 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| msantos007 wrote: |
| The only thing that is causing some trouble is that, even if some user updates the data in SAP table, I got the old weight. And, if I execute the same RFC connected as a dialog user, the value returned is the same on the table. If I restart WMB, or redeploy the .outadapter component, then, WMB gets the new weight, updated in the table. |
Not sure I understand you correctly. How is "some user" updating the data in the SAP table? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| msantos007 |
| Posted: Thu Aug 13, 2009 5:47 pm Post subject: |
|
|
Voyager
Joined: 20 Dec 2004
Posts: 78
|
A simple dialog user, someone who logs into SAP and changes the value
_________________
Maximiliano R. A. Santos
IBM Websphere MQ V6.0 Certified System Administrator
IBM Websphere MQ V5.3 Certified Solution Developer |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Aug 13, 2009 7:51 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| msantos007 wrote: |
| A simple dialog user, someone who logs into SAP and changes the value |
You do realize of course that SAP does their updates to the physical layer, once, twice and even thrice removed? Like updating data happens in a special deferred update task, and finally you have 2 special deferred update tasks for statistics and other non essential stuff.
So a Dialog user having changed and saved a value does not mean it will update the DB immediately, only that it has been queued for update.
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| msantos007 |
| Posted: Fri Aug 14, 2009 4:56 am Post subject: |
|
|
Voyager
Joined: 20 Dec 2004
Posts: 78
|
yeah I'm sure about that but I'm pretty sure SAP doesn't take more than an hour or a day to commit it to database.
_________________
Maximiliano R. A. Santos
IBM Websphere MQ V6.0 Certified System Administrator
IBM Websphere MQ V5.3 Certified Solution Developer |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Aug 14, 2009 1:53 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| msantos007 wrote: |
| yeah I'm sure about that but I'm pretty sure SAP doesn't take more than an hour or a day to commit it to database. |
In general I would expect it to be committed quasi immediately.
In particular I have seen systems where there was an update problem and the update did get deferred to up to one day while they were fixing what was wrong.... Talk to your SAP Team to find out what is wrong. Could as well be that your RFC function is being kept in SAP memory and is caching the value there...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Qadeer_824 |
| Posted: Sat Feb 26, 2011 10:40 am Post subject: |
|
|
Acolyte
Joined: 04 Oct 2007
Posts: 59
|
Hi,
I am facing the same problem in my project using IBM WebSphere Message Broker 6.1 and SAP Adapter nodes 6.1.0.6 IF05.
Can you please let me know if you found a solution/workaround for this? Your help is highly appreciated.
Thanks,
Qadeer |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sat Feb 26, 2011 11:41 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
This is a standard problem with SAP.
This is how I've solved it in the past.
If you update the data is SAP you need to force SAP to refresh it's CACHE. You do this by reading the same data that you wrote.
I did this by using a FlowOrder node. The first branch is where the succes/faile etc is returned to the caller.
The second branch does the read on SAP.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| fatherjack |
| Posted: Sat Feb 26, 2011 3:57 pm Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| smdavies99 wrote: |
This is a standard problem with SAP.
This is how I've solved it in the past.
If you update the data is SAP you need to force SAP to refresh it's CACHE. You do this by reading the same data that you wrote.
I did this by using a FlowOrder node. The first branch is where the succes/faile etc is returned to the caller.
The second branch does the read on SAP. |
I'm sure this works fine for you but it's a nonsense having to code a solution to read something twice just in case somethings been cached.
The real answer is to get SAP to stop the caching. I'm not a SAP expert but have seen this problem before and it's a SAP config thing. Get your SAP admin to fix it.
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Feb 26, 2011 9:32 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If you are looking to read a value after a BAPI create or update call the value will not be there until after you have done a BAPI commit call.
So you need to do your read after the BAPI commit call.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sat Feb 26, 2011 11:37 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| fjb_saper wrote: |
If you are looking to read a value after a BAPI create or update call the value will not be there until after you have done a BAPI commit call.
So you need to do your read after the BAPI commit call.
|
Might doing this in the middle of the flow remove the transactionality of the whole thing?
If this is true and you don't care then fine, either get your BAPI to do the commit automaticaly or add a separate call to SAP to force it.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Feb 27, 2011 10:42 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The reason for this, is that as long as the bapi commit has not been called, the data only lives in the appserver's memory.
Don't know how the SAPAdapter handles the call and transactionality. That might be for a PMR to explore... From what I remember though, SAP would not allow you a 2 phase commit. Either the Bapi commit is successful or it fails. No equivalent to the prepare commit of XA.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
