on 02-28-2011 4:14 PM
Hi all-
I am thinking about creative ways to do offline processing... Our MII app loads a list of current orders for the user's browser. The user selects an order and requests back to MII for running the SAP transactions. Then their browser is reloaded with the up to date list again. When SAP is down they cannot process.
Certainly a traditional store and forward where all data is loaded to MII and transaction requests are queued up to be processed by MII/SAP in the background is possible. Con: Data synch issues are very complex however. Pro: It does provide excellent response time to the user.
I am just noodling about options...
>>Is there a way to start a thread that could take the XML output going to the web page and store that in the database in the background? I.E. release the data to the irpt and terminate the user's BLS while a background BLS is saving a copy of the XML/orders to the database.
Then when offline, the user can work from the last current list of orders they had. When SAP comes back up the system goes back to online operation. Thus the data sync would only be temporary. It does not have the response time benefit however. Maybe some more thinking, ...But I really want to know if there is a way to multi-thread this app.
Thanks,
--Amy Smith
--Haworth
I assume you're still running 12.0? 12.1 introduces a new action block for transaction calls, which allows for async threads to nested transaction calls.
I don't know how using query caching would work on the XacuteQuery template for your list of orders - especially when it would attempt to renew the cache when SAP was unavailable.
An XML file periodically saved to the web tab of your project would also provide you with a cache approach to servicing the user screen - a simple point of abstraction.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank Jeremy,
Another reason to upgrade from 12.0!
>> An XML file periodically saved to the web tab of your project would also provide you with a cache approach to servicing the user screen - a simple point of abstraction.
Yep, I agree and I won't have the make the user wait for the write.
--Amy
User | Count |
---|---|
10 | |
5 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.