cancel
Showing results for 
Search instead for 
Did you mean: 

Agentry - using oData to send a batch of transactions in one service call

former_member231132
Participant
0 Kudos

I'm sending my transactions to the backend via an oData web service.  It appears that out of the box Agentry will send one transaction per oData web service call.  For my app this will potentially require many calls to the web service each time the user transmits data to the backend, causing a long wait time.  Does Agentry support batching up the transactions (of one transaction type) and sending them all in one call to an oData service?  And it would be even better if they could be sent as JSON instead of XML if possible?

Thanks

Tim

Accepted Solutions (0)

Answers (1)

Answers (1)

mark_pe
Active Contributor
0 Kudos

Hi Tim,

We will try to ping our colleague to see if they have an example on batching transactions during transmit and to see if it will work with your case. Let me see if we can email them and hopefully they respond.

Best Regards,

SAP Mobile Support Team

former_member231132
Participant
0 Kudos

Thanks Mark

mark_pe
Active Contributor
0 Kudos

Tim,

Okay I sat down with all the chief architects or product owners for the future of Work Manager or Agentry mobility applications during lunch.  They gave me the best answer to this.

In Agentry (advantages), in most of our products that we designed nowadays, we use the concept of Transaction Bundling (Let Java handle all the properties). For 1 transaction you do, you will have an update to the backend, this update will comprise of all the transaction properties in one shot updating the backend ERP in one transmit (in Java).

Instead of doing multiple transactions, you will do transaction bundling in one update.

This is the comparison to the oDATA batch feature in Agentry.

So in your case you may need to have some Java that either takes/sends the data of your oData and use the concept of transaction bundling in Agentry.

There are trade off between oData versus Agentry transactions but in general the transaction bundling is how those chief architects explained why they are using it in most of the products in SAP as there are some advantages to it.

Best Regards,

Mark Pe
SAP Platinum Support Engineer

former_member231132
Participant
0 Kudos

Mark,  Thanks very much for spending extra effort on this.

I'm a little confused when you talk about oData transactions versus Agentry transactions.  It was my understanding that all transactions are Agentry transactions, and oData is just the backend connection type that is used to send them to the backend, no different than say an SQL connection as far as the transaction is concerned.

I've not used Java and Agentry together in  one application yet so possibly this is the piece I'm missing in understanding what you're talking about.  Are you saying that during the transmit I could use Java to gather all of my Agentry transactions and then call the oData service from Java? If so, is there a way to communicate back to the Agentry client that the transaction(s) should be deleted on the client after successful processing on the backend, or is the transaction update step's "response to client" property still used for that?

Thanks very much

Tim

mark_pe
Active Contributor
0 Kudos

Tim,

Yes to this : "Are you saying that during the transmit I could use Java to gather all of my Agentry transactions and then call the oData service from Java? "

For this "or is the transaction update step's "response to client" property still used for that?"

This step is done to remove the Object (with keyID) on the device.

In Work Manager the main object really is the Workorder object. If you did your transactions and this Workorder needs to be removed then on the response to client (check all the options in the editor on response to client) the steps will be done accordingly (like Delete and others) - see pic.


Another option in Agentry is when do you want to run it.  You can start using the feature Data states. Data states if true can run the step.  If not true the step can be ignored and go to the next steps.  IN my picture above, the Runs For "All Data State" is just a setting that this step always run.  In some of our out of the box system, some of our prouducts check the backend to see if this step needs to be run or not (for collision handling).


Regards,

Mark Pe
SAP Platinum Support Engineer