Package properties - Run Best practice

Hi,
What is best during distribution run minimize or hidden? when would you choose one instead the other one?
Thanks,
François

http://blogs.msdn.com/b/scstr/archive/2012/05/31/how_2d00_to_2d00_create_2d00_an_2d00_application_2d00_in_2d00_configuration_2d00_manager_2d00_2012.aspx
Minimized – The deployment type runs minimized on client devices. Users might see installation activity in the notification area or taskbar.
Hidden – The deployment type runs hidden on client devices and users will see no installation activity.
So whichever best fits your situation / requirement.
If you don't want the user seeing anything then make it hidden.

Similar Messages

Business Package for SAP Best Practices for Enterprise Portal

Hi,
We are implementing EP for ECC 5.0 and we have to web enable some FI transactions like FB50/fb60 etc. We want to use standard business package for this. The only business package that caters this requirement is "Business Package for SAP Best Practices for Enterprise Portal 60.1". When i checked the data source for this business package, the specification is for "SAP R/3 4.6B and above". Does this work for ECC 5.0 as well? In general does the R/3 specific business packages work for ECC versions? Please let me know. Thanks for the help. I promise rewards.
Regards
Hari

Hari,
When you download the BPO via Portal Content Portfolio,
each bpo has additional information on the release.
For example for the one you are inquiring about - Business Package for SAP Best Practices for Enterprise Portal, the additional release information is provided on the following links;
https://www2.iviewstudio.com/sdn/info/index.cfm?action=faqs&part=#QSR03
https://www2.iviewstudio.com/sdn/detail_view/index.cfm?action=package_information&CatalogSet=SAP%20Content&ItemID=17212&CFID=7544845&CFTOKEN=99283970
Regards,
James

Running Best Practice Analyzer on remote 2008 R2 domain controllers

Hello Powershell World,
I'll start out by first mentioning that I am a powershell rookie so I gladly welcome any input to help me improve or work more efficiently. Anyway, I recently used powershell to run the best practice analyzer for DNS on all of our domain controllers.
The way I went about was pretty tedious and inefficient but still got the job done through a series of one-liners and exported the report to a UNC path as follows:
Enable-PSremoting -Force (I logged into all of the domain controllers individually and ran this before running the one-liners below from my workstation)
New-PSSession -Name <Session Name> -ComputerName <Hostname>
Enter-PSSession -Name <Session Name>
Import-Module bestpractices
Invoke-BPAModel Microsoft/Windows/DNSServer
Get-BPAResult Microsoft/Windows/DNSServer | Select ModelId,Severity,Category,Title,Problem,Impact,Resolution,Compliance,Help | Sort Category | Export-CSV \\server\share\BPA_DNS_SERVERNAME.csv
I'm looking to do this again but for the Directory Services best practice analyzer without having to individually enable remoting on the domain controllers and also provide a lsit of servers for the script to run against.
Thanks in advance for all your help!

What do you mean by "without having to individually enable remoting "?
You cannot remote without enabling remoting. You only need to enable remoting once. It is a configuraiton change. If you have done it once you do not need to do it again.
Here is how to runfrom a list of DCs.
$sb={
Import-Module bestpractices
Invoke-BPAModel Microsoft/Windows/DNSServer
Get-BPAResult Microsoft/Windows/DNSServer |
Select ModelId,Severity,Category,Title,Problem,Impact,Resolution,Compliance,Help |
Sort Category |
Export-CSV "\\server\share\BPA_DNS_$env:COMPUTERNAME.csv"
Invoke-BPAModel Microsoft/Windows/DirectoryServices
# etc...
ForEach($dc in $listofDCs){
Invoke-Command -ScriptBlock $sb -Computer $dc
¯\_(ツ)_/¯

Constants or properties file - best practice question

Hi,
My application has a number of values that will be used in different classes throughout my project. For example, I perform a check against the max allowed length of an ID in numerous places in my code.
Therefore, it makes sense to set this value in a central location, and refer to it as a variable where it is required in my code.
I see in other projects that using a public static final member in a Constants class is used to set these types of values. Is this recommended or best practice?
The only alternative I can think of would be to use a properties file, and inject the value using Spring etc.
What is considered best practice or the neatest way for doing this?
Thanks

user10340197 wrote:
Thanks. I'm using Spring anyways, so it would provide me with the PropertyPlaceHolderConfigurer for injecting these.And the name of that class provides a clue. As Kayaman said, constants are constants. Math.PI does not and will not change, EVER. Neither will Integer.MAX_VALUE.
Configuration parameters, on the other hand, might change. If your MAX_ID_LENGTH is ever likely to change, and could do so without causing widespread chaos, then it probably should be a property (ie, a configuration) value.
If not, it should probably be a constant (with appropriate 60-point documentation warning people what might happen if they DO change it).
Winston
PS: There is nothing particularly terrible about having a Properties class (except that you'll want to call it something different) that initializes its values from configuration files; except that if there are gazillions of them, you might want to:
(a) Split them up into "themes".
(b) Re-think your design.
Winston

Diff Between Best Practices & Business Packages

Dear Master
Can u give a brief difference between
Best Practices & Business Packages?
thankx

Hi,
Best Practices : SAP Best Practices provide a toolset that helps IT and functional project team members to quickly deploy functionality in SAP solutions - from SAP NetWeaver, to core SAP applications. This toolset comprises a mix of step-by-step instructions, preconfiguration, sample master data, code samples (where applicable) and end-user training - organized by technical or business scenarios that you might want to implement in your landscape.
http://help.sap.com/content/bestpractices/crossindustry/bestp_based_netweaver.htm
Business Packages : The SAP NetWeaver Portal offers a state-of-the-art portal solution. However, to make a portal useful to all the people it seeks to serve, it must not only provide general portal capabilities, but also content designed specifically to serve users in various industries and business areas.
SAP provides such pre-assembled content bundled as business packages for completing business tasks. In essence, the business packages provide out-of-the-box portal applications that can be easily modified to suit a customer's needs.
http://www.sdn.sap.com/irj/sdn/contentportfolio
Hope this helps.
Cheers!
Sandeep Tudumu

SQL server Best Practice Analyzer output in .CSV

Hi Team, I ran SQL server Best practice analyzer on our SQL 2008 R2 server. I was trying to export scan result in .csv format but it is only giving me option to save it in .xml format. I have been looking for ways to export output in such a way
that it can be readable and I can send it to our clients but no luck.
How can I export SQL BPA output in .csv or any other user friendly format?
Thanks in Advance.

Hi MSRS27,
You can run Best Practices Analyzer (BPA) scans either from Server Manager, by using the BPA GUI, or by using cmdlets in Windows PowerShell. We can view or save BPA results from Windows PowerShell session in different format.
If you want to export BPA results to a comma-separated values (CSV) text file, run the following cmdlet, where Path represents the path and text file name to which you want to save the CSV results.
CSV results can be imported into Microsoft® Excel, or other programs that display data in spreadsheets or grids.
Get-BPAResultModel ID| Export-CSVPath
For more information, see: Run Best Practices Analyzer Scans and Manage Scan Results
http://technet.microsoft.com/en-us/library/hh831400.aspx
Regards,
Sofiya Li
Sofiya Li
TechNet Community Support

SCM Best Practice Scenarios - can't find them on Service Marketplace

I'd like to run Best Practice SCM scenarios such as:
     S24 Vendor-Managed Inventory
     S41 Supplier-Managed Inventory
     S51 Available-to-Promise with Product Allocation
but can't find them anywhere.
In version SCM 5.0 they could be located in the Best Practice Area, but the links are missing now. When I go to the Industry Specific Best Practices (i.e. for Vendor-Managed Inventory), all I see is scenarios related to ECC 6.0.
Thanks in advance for any help locating these.

Chris,
Small world. I live out in Chester county.
BPPs can be lengthy and sometimes take a while to load. They are in MS word format, so you must have a way to read MS Word docs. Also, our friends in Waldorff don't always have their servers up. Sometimes it helps to try again later, or during a period of low activity. I usually have good luck during late afternoon and early evening EST time zone.
Here are some links. I haven't tied to load all of them, but I was successful in the first four. Give it a shot.
http://help.sap.com/bp_scmv250/documentation/S24_BPP_EN_DE.doc
http://help.sap.com/bp_scmv250/documentation/S35_BPP_EN_DE.doc
http://help.sap.com/bp_scmv250/documentation/S37_BPP_EN_DE.doc
http://help.sap.com/bp_scmv250/documentation/S38_BPP_EN_DE.doc
http://help.sap.com/bp_scmv250/documentation/S39_BPP_EN_DE.doc
http://help.sap.com/bp_scmv250/documentation/S40_BPP_EN_DE.doc
http://help.sap.com/bp_scmv250/documentation/S41_BPP_EN_DE.doc
http://help.sap.com/bp_scmv250/documentation/S45_BPP_EN_DE.doc
http://help.sap.com/bp_scmv250/documentation/S46_BPP_EN_DE.doc
http://help.sap.com/bp_scmv250/documentation/S47_BPP_EN_DE.doc
http://help.sap.com/bp_scmv250/documentation/S48_BPP_EN_DE.doc
http://help.sap.com/bp_scmv250/documentation/S51_BPP_EN_DE.doc
http://help.sap.com/bp_scmv250/documentation/S52_BPP_EN_DE.doc
http://help.sap.com/bp_scmv250/documentation/S53_BPP_EN_DE.doc
http://help.sap.com/bp_scmv250/documentation/S66_BPP_EN_DE.doc
http://help.sap.com/bp_scmv250/documentation/S68_BPP_EN_DE.doc
http://help.sap.com/bp_scmv250/documentation/S70_BPP_EN_DE.doc
http://help.sap.com/bp_scmv250/documentation/S72_BPP_EN_DE.doc
Rgds,
DB49

Best Practice in using Business Packages

Hi All,
Are there any Best Practices in the use of Business Package content? Do you assign the Roles delivered by the Business Package and do you make changes to the original iViews?
or
Do you copy the content delivered in the Business Package to a new folder and work with there?
These questions are purely at the configuration level and not at the Java coding level. For instance if I want to turn of the iView Tray, or change a parameter such as height, or even remove an iView from a page or Role.
I would like to know the various approaches the SDN community uses and the different challenges and benefits that result in each approach.
Look forward to hearing from you all
Paul

Hi Paul,
I also build my own roles. The only time I might use the standard roles is for demo purposes early in a project. You will find that in some cases the business packages like MSS don't always even include standard roles, so you have no choice but to build.
I never change any of the standard iViews/Pages/Worksets - ever.
The most contentious issue seems to be whether to do a full or delta link copy of the standard objects. I tend to initially do a full copy of the objects into a custom folder set in the PCD and modify those. Then I only use delta links from Page to iViews where I need the option of setting different properties for the same iView if it appears in multiple pages. Delta links can be a bit flakey at times, so I tend to only use them where I have to. I suspect that I may get to a point where I don't use them at all.
Just my 2 cents worth....
Regards,
John

Best Practice to implement Business Packages

Hello All,
Need some clarification -
What is the best practice to implement ESS/MSS Business Package onto Portal -
(1) Should I just import and configure the content OR
(2) Should I import, create a copy and then configure it? If yes, are there any points to be kept in mind?
All blogs/articles that have been published show to configure the standard content.
The requirement is to maintain a different prefix/namespace for each Portal content that comes along the business package?
Thanks,
Ritu

Hi Paul,
I also build my own roles. The only time I might use the standard roles is for demo purposes early in a project. You will find that in some cases the business packages like MSS don't always even include standard roles, so you have no choice but to build.
I never change any of the standard iViews/Pages/Worksets - ever.
The most contentious issue seems to be whether to do a full or delta link copy of the standard objects. I tend to initially do a full copy of the objects into a custom folder set in the PCD and modify those. Then I only use delta links from Page to iViews where I need the option of setting different properties for the same iView if it appears in multiple pages. Delta links can be a bit flakey at times, so I tend to only use them where I have to. I suspect that I may get to a point where I don't use them at all.
Just my 2 cents worth....
Regards,
John

What is the best practice for package source locations?

I have several remote servers (about 16) that are being utilized as file servers that have many binaries on them to be used by users and remote site admins for content. Can I have SCCM just use these pre-existing locations as package sources, or is this
not considered best practice?
Or
Should I create just one package source within close proximity to the Site Server, or on the Site Server itself?
Thanks

The primary site server is responsible for grabbing the source data and turning it into packages for Distribution points. so while you can use ANY UNC to be a source location for content, you should be aware of where that content exists in regards
to your primary site server. If your source content is in Montana but your primary server is in California ... there's going to be a WAN hit ... even if the DP it's destined for is also in Montana.
Second, I strongly recommend locking down your source UNC path so that only the servers and SCCM admins can access it. This will prevent side-loading of content as well as any "accidental changing" of folder structure that could cause
your applications/packages to go crazy.
Put the two together and I typically recommend you create a DSL (distributed source library) share and slowly migrate all your content into it as you create your packages/applications. You can then safely create batch installers, manage content versions,
and other things without fear of someone running something out of context.

What are best practice for packaging and deploying j2EE apps to iAS?

We've been running a set of J2EE applications on a pair of iAS SP1b for about a year and it has been quite stable.
Recently however we have had a number of LDAP issues, particularly when registering and unregistering applications (registering ear files sometimes fails 1st time but may work 2nd time). Also We've noticed very occasionally that old versions of classes sometimes find their way onto our machines.
What is considered to be best practice in terms of packaging and deployment, specifically:
1) Packaging - using the deployTool that comes with iAS6 SP1b to package is a big manual task, especially when you have 200+ jsp files. Are people out there using this or are they scripting it with a build tool such as Ant?
2) Deploying an existing application to multiple iAS's. Are you guys unregistering old application then reregistering new application? Are you shutting down iAS whilst doing the deployment?
3) Deploying ear files can take 5 to 10 mins, is this normal?
4) In a clustered scenario where HTTPSession is shared what are the consequences of doing deployments to data stored in session?
thanks in asvance for your replies
Owen

You may want to consider upgrading your application server environment to a newer service pack. There are numerous enhancements involving the deployment tool and run time layout of your application that make clear where you're application is loading its files from.
If you've at a long running application server environment, with lots of deployments under your belt, you might start to notice slow downs in deployment and kjs start time. Generally this is due to garbage collecting in your iAS registry.
You can do several things to resolve this. The most complete solution is to reinstall the application server. This will guarantee a clean ldap registry. Of course you've got to restablish your configurations and redeploy your applications. When done, backup your application server install space with the application server and directory server off. You can use this backup to return to a known configuation at some future time.
For the second method: <B>BE CAREFUL - BACKUP FIRST</B>
There is a more exhaustive solution that involves examining your deployed components to determine the active GUIDS. You then search the NameTrans section of the registry searching for Applogic Servlet *, and Bean * entries that represent your previously deployed components but are represented in the set of deployed GUIDs. Record these older GUIDs, remove them from ClassImp and ClassDef. Finally remove the older entries from NameTrans.
Best practices for deployment depend on your particular environmental needs. Many people utilize ANT as a build tool. In later versions of the application server, complete ANT scripts are included that address compiling, assembly and deployment. Ant 1.4 includes iAS specific targets and general J2EE targets. There are iAS specific targets that can be utilized with the 1.3 version. Specialized build targets are not required however to deploy to iAS.
Newer versions of the deployment tool allow you to specify that JSPs are not to be registered automatically. This can be significant if deployment times lag. Registered JSP's however benefit more fully from the services that iAS offers.
2) In general it is better to undeploy then redeploy. However, if you know that you're not changing GUIDs, recreating an existing application with new GUIDs, or removing registered components, you may avoid the undeploy phase.
If you shut down the KJS processes during deployment you can eliminate some addition workload on the LDAP server which really gets pounded during deployment. This is because the KJS processes detect changes and do registry loads to repopulate their caches. This can happen many times during a deployment and does not provide any benefit.
3) Deploying can be a lengthy process. There have been improvements in that performance from service pack to service pack but unfortunately you wont see dramatic drops in deployment times.
One thing you can do to reduce deployment times is to understand the type of deployment. If you have not manipulated your deployment descriptors in any way, then there is no need to deploy. Simply drop your newer bits in to the run time space of the application server. In later service packs this means exploding the package (ear,war, or jar) in to the appropriate subdirectory of the APPS directory.
4) If you've changed the classes of objects that have been placed in HTTPSession, you may find that you can no longer utilize those objects. For that reason, it is suggested that objects placed in session be kept as simple as possible in order to minimize this effect. In general however, is not a good idea to change a web application during the life span of a session.

Best Practice: Usage of the ABAP Packages Concept?

Hi SDN folks,
I've just started on a new project - I have significant ABAP development experience (15 years+) - but one thing that I have never seen used correctly is the Package concept in ABAP - for any of the projects that I have worked on.
I would like to define some best practices - about when we should create packages - and about how they should be structured.
My understanding of the package concept is that they allow you to bundle all of the related objects of a piece of development work together. In previous projects - and almost every project I have ever worked on - we just have packages ZBASIS, ZMM, ZSD, ZFI and so on. But this to me is a very crude usage of packages, and really it seems that we have not moved on passed the 4.6 usage of the old development class concept - and it means that packages do not really add much value.
I read in the SAP PRESS Next Generation ABAP book (Thomas Ljung, Rich Hellman) (I only have the 1st edition) - that we should use packages for defining separation of concern for an application. So it seems there they are recommending that for each and every application we write - we define at the least 3 packages - one for Model, one for Controller and one for view based objects. It occurs to me that following this approach will lead to a tremendous number of packages over the life cycle of an implementation, which could potentially lead to confusion - and so also add little value. Is this really the best practice approach? Has anyone tried this approach across a full blown implementation?
As we are starting a new implementation - we will be running with 7 EHP2 and I would really like to get the most out of the functionality that is provided. I wonder what others have for experience in the definition of packages.
One possible usage occurs to me that you could define the packages as a mirror image of the application business object class hierarchy (see below). But perhaps this is overcomplicating their usage - and would lead to issues later in terms of transportation conflicts etc.:
                                      ZSD
                                        |
                ZSOrder    ZDelivery   ZBillingDoc
Does anyone have any good recommendations for the usage of the ABAP Package concept - from real life project experience?
All contributions are most welcome - although please refrain from sending links on how to create packages in SE80
Kind Regards,
Julian

Hi Julian,
I have struggled with the same questions you are addressing. On a previous project we tried to model based on packages, but during the course of the project we encountered some problems that grew overtime. The main problems were:
1. It is hard to enforce rules on package assignments
2. With multiple developers on the project and limited time we didn't have time to review package assignment
3. Devopelers would click away warnings that an object was already part of another project and just continue
4. After go-live the maintenance partner didn't care.
So, my experience is is that it is a nice feature, but only from a high level design point of view. In real life it will get messy and above all, it doesn't add much value to the development. On my neew assignment we are just working with packages based on functional area and that works just fine.
Roy

Best Practices - Update Explorer Properties of BW Objects

What are some best practices of using the process chain type "Update Explorer Properties of BW Objects"?
We have the option of updating Conversion Indexes, Hierarchy Indexes, Authorization Indexes, and RKF/CKF Indexes.
When should we run each update process?
Here are some options we're considering:
Conversion Indexes - Run this within InfoCube load process chains that contain currency conversions within explorer objects.
Hierarchy Indexes - When would this need to be run? Does this need to be run for PartProviders and/or Snapshots? Do ACRs handle this update? Should this be run within InfoCube load chains, or after ACRs?
Authorization - We plan to run this a couple times a day for all explorer objects.
RKF/CKS - Does this need to run after InfoCube loads? With PartProvider and/or Snapshot indexes? After transports have completed?
Thanks,
Cote

Does anyone productively use explorer and this process type for process chains?

Creating Software Update Packages - Best Practice?

I am setting up our SCCM 2012 R2 environment to begin using it for Windows Updates, however I'm not sure 100% the best method of setting it up.
Currently my plan is to break out the deployment packages by OS, but I read\told that I should avoid creating to many dynamic deployment packages, as every time it changes all the computers will re-scan that package. So What I want to do is create
various packages for OS and years, so I would have a package that contains all updates for Windows 7, older then January 31, 2013 (assuming the package doesn't have 1000+ updates), and are not superseded\Expired. Then I would create Packages for the 2014
monthly updates each month, then at the end 2014, combine them all in 1 package, and restart the process for 2015. Is this a sound plan or is there a better course of action?
If this the best practice method, is there any way to automatically create these packages? I tried the Automatic Deployment Rules, but I can not set a Year of release, only the a time frame of the release,(older then 9 Months), unless I am missing
something. The only way I can see doing this is going into All Software Updates, and filtering on my requirements, and then manually creating the package, but this would less desirable, as after each year I would like to remove the superseded and expired
without having to recreate the package.
Mark.

First, please learn what the different objects are -- not trying to be rude, just stating that if you don't do this, you will have fundamental issues. Packages are effectively meaningless when it comes to deploying updates. Packages are simply a way of grouping
the binary files so they can be distributed to DPs and in-turn made available to clients. The package an update is in is irrelevant. Also, you do not "deploy" update packages and packages are not scanned by clients. The terminology is very important because
there are implications that go along with it).
What you are actually talking about above are software update groups. These are separate and distinct objects from update packages. Software Update groups group updates (not the update binaries) into logical groups that can be in-turn deployed or used for
compliance reporting.
Thus, you have two different containers that you need to be concerned about, update packages and update groups. As mentioned, the update package an update is in is pretty meaningless as long as the update is in a package that is also available to the clients
that need it. Thus, the best way (IMO) to organize packages is by calendar period. Yearly or semi-annually usually works well. This is done more less to avoid putting all the updates into a single package that could get corrupted or will be difficult to deploy
to new DPs.
As for update groups, IMO, the best way is to create a new group every month for each class of products. This typically equates to one for servers, one for workstations, and one for Office every month. Then at the end of every year (or some other timeframe),
rolling these monthly updates into a larger update group. Keep in mind that a single update group can have no more than 1,000 updates in it though. (There is no explicit limit on packages at all except see my comments above about not wanting one huge package
for all updates.)
Initially populating packages (like 2009, 2010, 2011, etc) is a manual process as is populating the update groups. From then on, you can use an ADR (or really three: one for workstations, one for servers, and one for Office) that runs every month, scans
for updates released in the past month, and creates a new update group.
Depending upon your update process, you may have to go back and add additional deployments to each update group also, but that won't take too long. Also, always QC your update groups created by an ADR. You don't want IE11 slipping through if it will break
your main LOB application.
Jason | http://blog.configmgrftw.com

Best Practices for Packaging and Deploying Server-Specific Configurations

We have some server-specific properties that vary for each server. We'd
like to have these properties collected together in their own properties
file (either .properties or .xml is fine).
What is the best-practices way to package and deploy an application (as an
ear file), where each server needs some specific properties?
We'd kind of like to have the server-specific properties file be stored
external to the ear on the server itself, so that the production folks can
configure each server's properties at the server. But it appears that an
application can't access a file external to the ear, or at least we can't
figure out the magic to do it. If there is a way to do this, please let me
know how.
Or do we have to build a unique ear for each server? This is possible, of
course, but we'd prefer to build one deployment package (ear), and then
ship that off to each server that is already configured for its specific
environment. We have some audit requirements where we need to ensure that
an ear that has been tested by QA is the very same ear that has been
deployed, but if we have to build one for each server, this is not
possible.
Any help or pointers would be most appreciated. If this is an old issue,
my apologies, would you please point me to any previous material to read?
I didn't see anything after searching through this group's archives.
Thanks much in advance,
Paul
Paul Hodgetts -- Principal Consultant
Agile Logic -- www.agilelogic.com
Consulting, Coaching, Training -- On-Site & Out-Sourced Development
Java, J2EE, C++, OOA/D -- Agile Methods/XP/Scrum, Use Cases, UI/IA

The one draw back to this is you have to go all the way back to ant and the
build system to make changes. You really want these env variables to be
late binding.
cheers
mbg
"Sai S Prasad" <[email protected]> wrote in message
news:[email protected]...
>
Paul,
I have a similar situation in our project and I don't create ear filesspecific
to the environment. I do the following:
1) Create .properties file for every environment with the same attributename
but different values in it. For example, I have phoneix.properties.NT,phoenix.properties.DEV,
phoenix.properties.QA, phoenix.properties.PROD.
2) Use Ant to compile, package and deploy the ear file
I have a .bat file in NT and .sh for Solaris that in turn calls theant.bat or
ant.sh respectively. For the wrapper batch file or shell script, you canpass
the name of the environment. The wrapper batch file will copy theappropriate
properties file to "phonenix.properties". In the ant build.xml, I alwaysrefer
to phonenix.properties which is available all the time depending on theenvironment.
>
It works great and I can't think of any other flexible way. Hope thathelps.
>
Paul Hodgetts <[email protected]> wrote:
We have some server-specific properties that vary for each server. We'd
like to have these properties collected together in their own properties
file (either .properties or .xml is fine).
What is the best-practices way to package and deploy an application (as
an
ear file), where each server needs some specific properties?
We'd kind of like to have the server-specific properties file be stored
external to the ear on the server itself, so that the production folks
can
configure each server's properties at the server. But it appears that
an
application can't access a file external to the ear, or at least we can't
figure out the magic to do it. If there is a way to do this, please
let me
know how.
Or do we have to build a unique ear for each server? This is possible,
of
course, but we'd prefer to build one deployment package (ear), and then
ship that off to each server that is already configured for its specific
environment. We have some audit requirements where we need to ensure
that
an ear that has been tested by QA is the very same ear that has been
deployed, but if we have to build one for each server, this is not
possible.
Any help or pointers would be most appreciated. If this is an old issue,
my apologies, would you please point me to any previous material to read?
I didn't see anything after searching through this group's archives.
Thanks much in advance,
Paul
Paul Hodgetts -- Principal Consultant
Agile Logic -- www.agilelogic.com
Consulting, Coaching, Training -- On-Site & Out-Sourced Development
Java, J2EE, C++, OOA/D -- Agile Methods/XP/Scrum, Use Cases, UI/IA

Package properties - Run Best practice

Similar Messages

Maybe you are looking for