Agentry 7.x and SMP 3.0 SP04 - Deploy Java without refreshing client data

[Marçal_Oliveras]

Hi,

In Agentry, every time I want to deploy changes to the Java layer, I must create a new ZIP file containing not only the .jar but also an Agentry application.

After doing that I have to restart the Agentry server instance in the SMP Cockpit to apply the Java changes. Finally, when I start the transmit in my client, all the Agentry project definitions will be downloaded again and together with that, all the complex tables data... This is slowing me down a lot when I'm making changes to the Java. Is there a way to avoid this behavior?

Thank you in advance,

Marçal

[Former Member · Accepted solution]

Hi Marçal,

there should be a secon connection type that is called Angel Lite. You can use this that not all DT and CT are fetched again. You can also play with the switches in the global settings of the Application.

But you won't avoid to get always the latest object (workorders/notifs). I guess you are also working in a dev environment. One "hack" could be to reduce the filters that always only one specific record is fetched...I also switch off the CT/DT.

But honestly I would code my stuff in Java and after a major changes in the J-middleware I would have a look via debug mode....

Kind regards,

Mike

[Marçal_Oliveras · Accepted solution]

Hi Michael,

Thanks for your answer.

I understand your approach but all the changes you mention can affect other users (configuration) or have to be undone before merging (if I use lite connection type for instance). I know it is a work around but I was expecting something easier.

The other problem I face is that I don't know why but debugger doesn't allow me to implement hot fixes now in order to correct small issues I did before I deployed. I don't know why, because in the past I could do all the hot fixes I needed and once everything tested properly, deploy the jar again.

[Former Member · Accepted solution]

Hey Marçal,

therefore I would recommend you are copying the mobile app, which is excluesivly for you for debugging / development purposes. Ok if you have after DEV an additional mapping you have to do the same again in the other config. But you are not stepping on the toe of the users. There you can do the mentioned above approach by siwtching off the CT/DT etc. .

Kind regards,

Mike

[Marçal_Oliveras · Accepted solution]

OK thanks.

To me, copying the app in the configuration portal is not really an option. We are multiple developers working in the same app. If for instance one creates a new Complex Table then my copy will not have the correct configuration and there is no way to "transport changes" between applications.

The same kind of issues will happen in the backend. We have BADI implementations that are enabled only for certain configuration portal apps. If I do a copy I would have to go through all this.

But it's fine, I accept that there is not a simple way to do what I wanted: just publish the .jar and expect the client to don't refresh anything unless I clear the data or reset the application.

[Former Member · Accepted solution]

No, problem.

Please do not shoot the messenger!

In that case I'm sitting in the same boat....I also have do do this kind of things.

Sorry that I didn't have better news.

Well one thing could propably help you in that case. You could point in the JavaBE.ini wether to use sap as the source of config mappings or the ini file itself. There is a scn article that describes that.

Perhaps this helps you:

http://scn.sap.com/docs/DOC-56473

http://scn.sap.com/thread/3583211

Kind regards,

Mike

[Marçal_Oliveras · Accepted solution]

Hi Mike,

Sorry if I seemed impolite! I know you tried to give me solutions to my problem, I just wanted to explain why were not good enough for me

But of course I'm aware it is due to a product limitation, I'm not blaming anybody!

And thank you for the link, I'm already using the local JavaBE.ini very often, it helps a lot to not interfere with other developers when working in parallel. Actually I work in the same company than the SCN document author

Kind Regards,

Marçal

[Former Member · Accepted solution]

If you use development logic you only need to restart the SMP Server after deploying the new Java Changes and you wouldn't need to deploy a new application.

Stephen

[Former Member · Accepted solution]

Hi Marçal,

no worries, you haven't been imploite. It could always be a miscommunication from my side as well! To be honest I'm struggeling with these things as well....

Ok I didn't know that you colleague created that document. SCN is a village...

I understand your point regarding copying the config. You are absolutly right it is a double effort, but sometimes it could be needed or just be helpful. I also prefer the J*.ini solution.

Back to the J thing. Well Java is always loaded/processed (and also put into mem thanks to the runtime) during server start/restart. Therefore it is necessary that it is deployed via SCC otherwise the Java is not recognized.

As Stephen said if you only have changes in the UI you can directly publish to the server folder.

Mostly you got a combination of both J* and A*Y App changes therefore you always need to republish/redeploy the whole package.

You are right it would be really nice if there would be a hotreplace functionality but as far as I know and tried there is no chance.

Kind regards and a nice WE,

Mike

[Marçal_Oliveras · Accepted solution]

Hi Stephen,

Do you mean that I can just copy the new .jar file to the Development Server folder and after restarting the server, this latest version will be loaded to the runtime? So there is no need to use SMP cockpit to deploy .jar changes in a development server?

[Marçal_Oliveras · Accepted solution]

Hi Mike,

Thanks for all the inputs, now I'm aware of all the workarounds and limitations.

I will try Stephen proposal to see if after restarting the Agentry server with a new Jar I can avoid the complex table data to be fetched again.

- Marçal