on 01-11-2015 6:45 PM
All.
I have previously posted a question and a document regarding this issue:
Previously I have only used this technique in development Agentry instances, but now I am trying to extend the use to production Agentry instances.
And this is where all the troubles start.
If I change JavaBE.ini to use source=INI in a production Agentry instance, then after I restart the instance it will be erroneous.
The Back End configuration of the Agentry Application will be gone, and I get runtime errors when I try to perform a transmit from the client.
Error will be something like: No Backends loaded.
Question:
Does anybody know if source=INI is (still) offically supported ?
And if Yes, is it only supported for development instances of Agentry ?
Thanks.
Søren Hansen
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Soren,
1) Most of the production instance that has ini file as source was based on the standalone Agentry servers. This ini source was the very first setup on how to configure SAP Work Manager back a few years ago. Since then they created the source to be the SAP Configpanel to align all the setup with the SAP basis or admin team. Due to the people in SAP backend normally want to configure everything in ECC/ERP. They do not need to go down to the installer or server level to setup the ini file.
Most of our products nowadays use the configpanel. What complicates this is the add on of SMP 3.0 which has some special rulings about starting or creating the production Agentry node. The key is the term "Production". I guess the main suggestion in production is to use the configpanel as the ini may only work on development.
2) Another thing I could think off is the official application zip file you use to load to SMP 3.0. Did you include the javaBE.ini in the zip file you initially load or created in SMP 3.0? This is just an idea. Most of our QA use the configpanel. We never use the ini on any newer products in QA or test or deployment.
My reference below can be used to relate what was done for the agentry.ini and hopefully you may see how this may also affect the javaBE.ini.
Hope this helps.
Mark Pe
SAP Senior Support Engineer
Hello Mark.
I understand and agree, that it is better to use source=SAP for normal production use.
And I understand, that you (SAP) will use this for future releases.
The setting source=INI, is very valuable for development instances, and I hope that this keeps being supported. When doing development with multiple developers, it is crucial, that each indivual developer can change the configuration locally only, when introducing new Java classes. Otherwise new Java Classes must be synchronized to all development instances to ensure that they function.
I thoght about using source=INI for production use, to enable ABAP (customizing) transports to be imported independtly of Agentry, and only as part of the import procedure. Once ABAP customizing and Agentry (Java part) are aligned I would switch back to source=SAP.
When introducing new Java Classes in your Agentry environment, you can have situations where you must import ABAP customizing and Agentry simultaneously, otherwise users will get runtime errors.
In our organization, we are not allowed to perform the actual import to production and therefore may need to perform imports independently.
Do you have some guidelines for achieving this ?
Thanks,
Søren
Soren,
We do not support javaBE.ini on mobile parameters on some setup. Everything is in configPanel as this is what is required to be used. (Verified statement today from our product team). In short, move away from the ini and use the configpanel. Similar to my description above about consolidating all the changes in the ECC/CRM area (for simplicity).
Hope this answers your question.
Regards,
Mark Pe
SAP Senior Support Engineer
User | Count |
---|---|
93 | |
10 | |
10 | |
9 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.