Long prized for its open platform strategy, Oracle’s JD Edwards EnterpriseOne can now run on a complete Oracle technology stack—including Oracle VM, Oracle Enterprise Linux, Oracle Database 11g, Oracle Fusion Middleware, and Oracle Enterprise Manager.
Here are the seven top reasons to run JD Edwards EnterpriseOne on a complete Oracle technology stack:
1. Assure system uptime and performance with Oracle Enterprise Manager: Working together, Oracle Enterprise Manager and the Application Management Pack for JD Edwards EnterpriseOne give system administrators a top-down view of all servers and their infrastructure, managed from a single console. The result: better proactive monitoring of servers, faster troubleshooting, and a higher service level for end users.
2. Give business users more control over report content and formatting: With the integration of Oracle BI Publisher with JD Edwards EnterpriseOne, business users can now design more-robust output templates for their reports, including pictures, logos, and font control. Business users can also write ad hoc queries into the JD Edwards data and run reports through common desktop tools such as Microsoft Word and Excel.
3. Reduce the cost, complexity, and risk of integrating applications within Oracle’s portfolio: The Oracle technology stack helps provide seamless integrations to Oracle’s best-of-breed applications, including project management, demand planning, forecasting, content management, and CRM On Demand. Oracle’s Application Integration Architecture and Process Integration Packs provide a flexible, standards-based framework for building resilient business processes more quickly and at lower cost.
4. Improve performance and increase flexibility of business processes. The Oracle technology stack also helps customers integrate JD Edwards EnterpriseOne with third-party applications. With the Oracle SOA Suite, users can re-engineer business processes with more agility while avoiding service interruptions.
5. Simplify and improve user access and security: With Oracle Access Manager, users can sign into all of their systems at once, which eliminates the need for multiple usernames and passwords, helps enforce strong password and authentication policies, and provides a centralized framework for security and compliance enforcement.
6. Increase productivity with a consistent user interface: As JD Edwards users switch from one Oracle application to another, Oracle’s standard user interface design provides a seamless design experience that incorporates the latest advances in UI design. Users spend less time learning how to navigate new interfaces, which increases productivity.
7. Build enterprise IT on a trusted, reliable, rock-solid platform: Oracle’s JD Edwards EnterpriseOne is engineered and tested to work with Oracle’s core technology—Oracle VM, Oracle Enterprise Linux, Oracle Database 11g, and Oracle Fusion Middleware, all of which consistently garner the industry’s top rankings.
Monday, July 20, 2009
Thursday, June 11, 2009
Password Policy
Passwords are an important aspect of computer security and front line of protection for user accounts. A poorly chosen password may result in the compromise of entire corporate network. All employees (including contractors and vendors with access to systems) are responsible to select and secure their passwords. The purpose of this policy is to establish a standard for creation of strong passwords, protection of those passwords, and frequency of change of passwords.
The scope of password policy includes all personnel who have or are responsible for an account on any system that resides at their respective facility, has access to network, or stores any non-public information.
General Password Policy is:
1. All system-level passwords (e.g., root, NT admin, application administration accounts, etc.) must be changed on at least a quarterly basis.
2. All production passwords must be part of the Information Services administered global password management database.
3. All user-level passwords (e.g., email, web, desktop computer, etc.) must be changed at least every six months though recommended every four months.
4. User accounts that have system-level privileges granted through group memberships or programs such as “sudo” must have a unique password from all other accounts held by that user.
5. Passwords must not be inserted into email messages or other forms of electronic communication.
6. Where SNMP is used, the community strings must be defined as something other than the standard defaults of “public,” “private” and “system” and must be different from the passwords used to log in interactively. A keyed hash must be used where available (e.g., SNMPv2).
7. All user-level and system-level passwords must conform to the guidelines described below.
Guidelines to follow for Password Policy are:
A. General Password Construction Guidelines
Passwords are used for various purposes like user level accounts, web accounts, email accounts, screen saver protection, voicemail password, and local router logins. Everyone should be aware of how to select strong passwords as very few systems have support for one-time tokens (i.e., dynamic passwords).
Poor, weak passwords have the following characteristics:
1. The password contains less than eight characters
2. The password is a word found in a dictionary (English or foreign)
3. The password is a common usage word such as:
3.1. Names of family, pets, friends, co-workers, fantasy characters, etc.
3.2. Computer terms and names, commands, sites, companies, hardware, software.
3.3. The words “companyname“, ”individualname”, “sanjose”, “sanfran” or any derivation.
3.4. Birthdays and other personal information such as addresses and phone numbers.
3.5. Word or number patterns like aaabbb, qwerty, zyxwvuts, 123321, etc.
3.6. Any of the above spelled backwards.
3.7. Any of the above preceded or followed by a digit (e.g., secret1, 1secret)
Strong passwords have the following characteristics:
1. Contain both upper and lower case characters (e.g., a-z, A-Z)
2. Have digits and punctuation characters as well as letters e.g., 0-9, !@#$%^&*()_+|~-=\`{}[]:”;’<>?,./)
3. Are at least eight alphanumeric characters long.
4. Are not words in any language, slang, dialect, jargon, etc.
5. Are not based on personal information, names of family, etc.
6. Passwords should never be written down or stored on-line. Try to create passwords that can be easily remembered. One way to do this is create a password based on a song title, affirmation, or other phrase. For example, the phrase might be: “This May Be One Way To Remember” and the password could be: “TmB1w2R!” or “Tmb1W>r~” or some other variation.
NOTE: Please do not use either of these examples as passwords!
B. Password Protection Standards
Do not use the same password for accessing different accounts (e.g., personal ISP account, option trading, benefits, etc.). For example, separate password for the Engineering systems and IT systems. Also, select a separate password for an NT and UNIX account. Do not share your passwords with anyone, including administrative assistants or secretaries. All passwords are to be treated as sensitive and confidential.
Here is a list of “Dont’s”:
1. Don’t reveal a password over the phone to ANYONE
2. Don’t reveal a password in an email message
3. Don’t reveal a password to the boss
4. Don’t talk about a password in front of others
5. Don’t hint at the format of a password (e.g., “my family name”)
6. Don’t reveal a password on questionnaires or security forms
7. Don’t share a password with family members
8. Don’t reveal a password to co-workers while on vacation
If someone demands a password, refer them to this document or have them call someone in the Information Security Department. Do not use the “Remember Password” feature of applications (e.g., Internet Explorer, Mozilla Firefox, Outlook, Netscape Messenger, etc..) Again, do not write passwords down and store them anywhere in your office. Do not store passwords in a file on ANY computer system (including Mobile Phones, Palm Pilots or similar devices) without encryption.
Change passwords at least once every six months (except system-level passwords which must be changed quarterly). Again, the recommended change interval is every four months. If an account or password is suspected to have been compromised, report the incident to Information Services and change all passwords. Password cracking or guessing may be performed on a periodic or random basis by Information Services or its delegates. If a password is guessed or cracked during one of these scans, the user will be required to change it.
C. Application Development Standards
Application developers must ensure their programs contain the following security precautions. Applications should:
1. support authentication of individual users, not groups.
2. not store passwords in clear text or in any easily reversible form.
3. provide for some sort of role management
4. support with LDAP security retrieval, wherever possible.
D. Use of Passwords and Passphrases for Remote Access Users
Access to the Organization Networks via remote access is to be controlled using either a one-time password authentication or a public/private key system with a strong passphrase.
E. Passphrases
Passphrases are not the same as passwords. Passphrases are generally used for public/private key authentication defining a mathematical relationship between the public key that is known by all, and the private key only to the user. Without the passphrase to “unlock” the private key, the user cannot gain access.
A passphrase is a longer (composed of multiple words) than password, therefore, more secure. Because of this, a passphrase is more secure against “dictionary attacks.” A good passphrase is long and contains a combination of upper and lowercase letters and numeric and punctuation characters. An example of a good passphrase:
“The*?#>*@TrafficOnThe101Was*&#!#ThisMorning”
All of the rules above that apply to passwords apply to passphrases. Enforcement of Password Policy is required in secured environment of systems.
The scope of password policy includes all personnel who have or are responsible for an account on any system that resides at their respective facility, has access to network, or stores any non-public information.
General Password Policy is:
1. All system-level passwords (e.g., root, NT admin, application administration accounts, etc.) must be changed on at least a quarterly basis.
2. All production passwords must be part of the Information Services administered global password management database.
3. All user-level passwords (e.g., email, web, desktop computer, etc.) must be changed at least every six months though recommended every four months.
4. User accounts that have system-level privileges granted through group memberships or programs such as “sudo” must have a unique password from all other accounts held by that user.
5. Passwords must not be inserted into email messages or other forms of electronic communication.
6. Where SNMP is used, the community strings must be defined as something other than the standard defaults of “public,” “private” and “system” and must be different from the passwords used to log in interactively. A keyed hash must be used where available (e.g., SNMPv2).
7. All user-level and system-level passwords must conform to the guidelines described below.
Guidelines to follow for Password Policy are:
A. General Password Construction Guidelines
Passwords are used for various purposes like user level accounts, web accounts, email accounts, screen saver protection, voicemail password, and local router logins. Everyone should be aware of how to select strong passwords as very few systems have support for one-time tokens (i.e., dynamic passwords).
Poor, weak passwords have the following characteristics:
1. The password contains less than eight characters
2. The password is a word found in a dictionary (English or foreign)
3. The password is a common usage word such as:
3.1. Names of family, pets, friends, co-workers, fantasy characters, etc.
3.2. Computer terms and names, commands, sites, companies, hardware, software.
3.3. The words “companyname“, ”individualname”, “sanjose”, “sanfran” or any derivation.
3.4. Birthdays and other personal information such as addresses and phone numbers.
3.5. Word or number patterns like aaabbb, qwerty, zyxwvuts, 123321, etc.
3.6. Any of the above spelled backwards.
3.7. Any of the above preceded or followed by a digit (e.g., secret1, 1secret)
Strong passwords have the following characteristics:
1. Contain both upper and lower case characters (e.g., a-z, A-Z)
2. Have digits and punctuation characters as well as letters e.g., 0-9, !@#$%^&*()_+|~-=\`{}[]:”;’<>?,./)
3. Are at least eight alphanumeric characters long.
4. Are not words in any language, slang, dialect, jargon, etc.
5. Are not based on personal information, names of family, etc.
6. Passwords should never be written down or stored on-line. Try to create passwords that can be easily remembered. One way to do this is create a password based on a song title, affirmation, or other phrase. For example, the phrase might be: “This May Be One Way To Remember” and the password could be: “TmB1w2R!” or “Tmb1W>r~” or some other variation.
NOTE: Please do not use either of these examples as passwords!
B. Password Protection Standards
Do not use the same password for accessing different accounts (e.g., personal ISP account, option trading, benefits, etc.). For example, separate password for the Engineering systems and IT systems. Also, select a separate password for an NT and UNIX account. Do not share your passwords with anyone, including administrative assistants or secretaries. All passwords are to be treated as sensitive and confidential.
Here is a list of “Dont’s”:
1. Don’t reveal a password over the phone to ANYONE
2. Don’t reveal a password in an email message
3. Don’t reveal a password to the boss
4. Don’t talk about a password in front of others
5. Don’t hint at the format of a password (e.g., “my family name”)
6. Don’t reveal a password on questionnaires or security forms
7. Don’t share a password with family members
8. Don’t reveal a password to co-workers while on vacation
If someone demands a password, refer them to this document or have them call someone in the Information Security Department. Do not use the “Remember Password” feature of applications (e.g., Internet Explorer, Mozilla Firefox, Outlook, Netscape Messenger, etc..) Again, do not write passwords down and store them anywhere in your office. Do not store passwords in a file on ANY computer system (including Mobile Phones, Palm Pilots or similar devices) without encryption.
Change passwords at least once every six months (except system-level passwords which must be changed quarterly). Again, the recommended change interval is every four months. If an account or password is suspected to have been compromised, report the incident to Information Services and change all passwords. Password cracking or guessing may be performed on a periodic or random basis by Information Services or its delegates. If a password is guessed or cracked during one of these scans, the user will be required to change it.
C. Application Development Standards
Application developers must ensure their programs contain the following security precautions. Applications should:
1. support authentication of individual users, not groups.
2. not store passwords in clear text or in any easily reversible form.
3. provide for some sort of role management
4. support with LDAP security retrieval, wherever possible.
D. Use of Passwords and Passphrases for Remote Access Users
Access to the Organization Networks via remote access is to be controlled using either a one-time password authentication or a public/private key system with a strong passphrase.
E. Passphrases
Passphrases are not the same as passwords. Passphrases are generally used for public/private key authentication defining a mathematical relationship between the public key that is known by all, and the private key only to the user. Without the passphrase to “unlock” the private key, the user cannot gain access.
A passphrase is a longer (composed of multiple words) than password, therefore, more secure. Because of this, a passphrase is more secure against “dictionary attacks.” A good passphrase is long and contains a combination of upper and lowercase letters and numeric and punctuation characters. An example of a good passphrase:
“The*?#>*@TrafficOnThe101Was*&#!#ThisMorning”
All of the rules above that apply to passwords apply to passphrases. Enforcement of Password Policy is required in secured environment of systems.
Monday, June 1, 2009
Objectives of Technology Scope
Various Enterprise Resource Planning (ERP) systems are used worldwide regardless of company size helping in the business of an enterprise of which Oracle JD Edwards ERP been one of the choice.
Every company faces its own unique challenges. When a company isn't operating efficiently, steps are usually taken to resolve the issue; though inconvenient as well as disruptive, it may also require a steep learning curve and costs the company time, money and resources. All these concerns can be overcome, only if the ERP implementation is executed correctly. Some large companies still hesitate to invest in ERP Solutions due to the exorbitant costs. But it is indeed encouraging to find that a vast majority of them have realized ERP implementation benefits and have determined to excel among their competitors.
Any ERP Technology Solution should enable the Business to achieve both short-term and long-term benefits and provide a competitive advantage of implementation. Technology is an integral part of the Implementation Design Process. Scope is essential through Planning, Design, Work Breakdown, Verification and Control. The focus of the Technology Scope should include:
1. To introduce the suggested approach to the Oracle JD Edwards Implementation
2. Explain the Technology Checkpoints that are required for the Implementation
3. Explain the basic Hardware and Software requirements necessary to support the Oracle JD Edwards business solution
4. Creating a Foundation for the development of a technology project strategy that compliments the Application Implementation Project Strategy
5. Provide a basis for estimating the Licenses, Hardware, Software, Training and Resources to establish a Total Cost of Ownership for Oracle JD Edwards implementation
6. Uncover any concerns or constraints to proposed implementation for a Successful Project Strategy
7. Define high level steps necessary to bridge any gap between the current Technology Foundation and Oracle’s JD Edwards World or JD Edwards EnterpriseOne Solution
Every company faces its own unique challenges. When a company isn't operating efficiently, steps are usually taken to resolve the issue; though inconvenient as well as disruptive, it may also require a steep learning curve and costs the company time, money and resources. All these concerns can be overcome, only if the ERP implementation is executed correctly. Some large companies still hesitate to invest in ERP Solutions due to the exorbitant costs. But it is indeed encouraging to find that a vast majority of them have realized ERP implementation benefits and have determined to excel among their competitors.
Any ERP Technology Solution should enable the Business to achieve both short-term and long-term benefits and provide a competitive advantage of implementation. Technology is an integral part of the Implementation Design Process. Scope is essential through Planning, Design, Work Breakdown, Verification and Control. The focus of the Technology Scope should include:
1. To introduce the suggested approach to the Oracle JD Edwards Implementation
2. Explain the Technology Checkpoints that are required for the Implementation
3. Explain the basic Hardware and Software requirements necessary to support the Oracle JD Edwards business solution
4. Creating a Foundation for the development of a technology project strategy that compliments the Application Implementation Project Strategy
5. Provide a basis for estimating the Licenses, Hardware, Software, Training and Resources to establish a Total Cost of Ownership for Oracle JD Edwards implementation
6. Uncover any concerns or constraints to proposed implementation for a Successful Project Strategy
7. Define high level steps necessary to bridge any gap between the current Technology Foundation and Oracle’s JD Edwards World or JD Edwards EnterpriseOne Solution
Saturday, May 16, 2009
Roles in JD Edwards ERP
JD Edwards ERP has 3 areas of expertise: 1. Functional - Business Analyst, 2. Technical Programmer - Developer and 3. CNC - System Administrator and Architect.
1. Functional - Business Analyst
Business subject matter expert on one or more of the JD Edwards modules (Financials, Manufacturing, Transportation, Sales, etc...) often they started as a JDE user, the power user and gradually developed the skill to support the business aspects of JDE. Else, they might have a business degree and come into JDE on the job as a Business Analyst. Functional person seldom has any programming or development experience.
2. Technical Programmer - Developer
Developers are trained in the software development and programming tools that translate the business requirements as identified by the functional into programming code. Sometimes these individuals simply modify existing JDE objects and in other cases, develop entire suites of applications using EnterpriseOne development tools including the Report Design Aide (RDA), Table Design Aide (TDA), Business Function C-code design tools and others using JDE's Change Management System, Object Management Workbench.
3. CNC - System Administrator and Architect
Configurable Network Computing or CNC is a catch-all function comprising all that the two positions above do not cover including, Installation, Upgrades, Migrations, Updates, Change Management, System Administration, Security, Performance Tuning, Package Build and Deployment and over-all Architecture. CNC also refers to the systems analysts who install, maintain, manage and enhance the JD Edwards ERP architecture.
The CNC title is taken from the term ‘Configurable Network Computing’ which describes the overall JDE architecture combining mixed hardware, operating systems and databases to work together seamlessly. CNC technology continues to be at the heart of JD Edwards EnterpriseOne architecture and will play a significant role Oracle's Fusion Architecture initiative. Now a division of the Oracle Corporation, CNC is JD Edwards's client-server proprietary architecture and methodology that implements its highly-scalable enterprise-wide business solutions software that can run on a wide variety of hardware, operating systems and hardware platforms.
1. Functional - Business Analyst
Business subject matter expert on one or more of the JD Edwards modules (Financials, Manufacturing, Transportation, Sales, etc...) often they started as a JDE user, the power user and gradually developed the skill to support the business aspects of JDE. Else, they might have a business degree and come into JDE on the job as a Business Analyst. Functional person seldom has any programming or development experience.
2. Technical Programmer - Developer
Developers are trained in the software development and programming tools that translate the business requirements as identified by the functional into programming code. Sometimes these individuals simply modify existing JDE objects and in other cases, develop entire suites of applications using EnterpriseOne development tools including the Report Design Aide (RDA), Table Design Aide (TDA), Business Function C-code design tools and others using JDE's Change Management System, Object Management Workbench.
3. CNC - System Administrator and Architect
Configurable Network Computing or CNC is a catch-all function comprising all that the two positions above do not cover including, Installation, Upgrades, Migrations, Updates, Change Management, System Administration, Security, Performance Tuning, Package Build and Deployment and over-all Architecture. CNC also refers to the systems analysts who install, maintain, manage and enhance the JD Edwards ERP architecture.
The CNC title is taken from the term ‘Configurable Network Computing’ which describes the overall JDE architecture combining mixed hardware, operating systems and databases to work together seamlessly. CNC technology continues to be at the heart of JD Edwards EnterpriseOne architecture and will play a significant role Oracle's Fusion Architecture initiative. Now a division of the Oracle Corporation, CNC is JD Edwards's client-server proprietary architecture and methodology that implements its highly-scalable enterprise-wide business solutions software that can run on a wide variety of hardware, operating systems and hardware platforms.
Friday, May 15, 2009
Security Policy
Security policies are an absolute must ground-work for any organization providing the virtual glue to hold it all together. Before we begin about policies, let’s talk a little about trust as a central theme in many policies. Some policies may not be written because there is trust that people will do the right thing but needed because people don't always do the right thing. Ideally you want to trust all resources, but that is unrealistic. Buggy hardware and software are commonplace. Try to implement controls and procedures to minimize the impact when a failure does occur. Trust of employees and users develops over time. Different categories of employees should be trusted at different levels ensuring level of access is commensurate with level of trust.
When looking at trust, you have three basic models: 1. Trust everyone 2. Trust no one and 3. Trust some people at some time. In today's world it is not very common to find organizations that follow the model of trusting everyone all of the time or trusting no one at any time. The most common model is to trust some people some of the time and build trust over time. Also keep in mind that it may be appropriate to apply different trust models to different parts of the organization.
My experience in the field has consistently shown that security policies tend to elevate the level of tension in any given situation with the fact that people don’t like rules and restrictions in their activities. Everyone tends to view security needs differently: 1. Users are concerned about being able to get their work done without a lot of controls. 2. System support personnel are concerned about the ease of managing systems under tight control. 3. Management is concerned about costs versus protection. Getting all to agree of a policy is impossible so best is to try a Win-Win compromise.
To some extent everyone should be concerned of security policies as everyone is affected by them. The system users are typically affected the most as they see the policies as a set of rules to regulate their behavior making it more difficult for them to accomplish their job. The people who have to support the infrastructure are concerned since they are the ones who have to implement and comply by many of the policies. For example, a policy that requires all Windows Servers to be installed according to a baseline security standard would require more work on the part of the system administrators, not only for the initial install, but also for the system upkeep.
When planning policies, some organizations will go overboard and come up with something that will be impossible to implement and comply with. The bottom line for policies is they must take into consideration the balance of protection with the level of productivity hit. Policies should be concise and easy to read and understand. One thing to keep in mind when developing a policy is how it will affect legacy systems and other infrastructure that is already in place. Once the policies are fully approved, they should be made available to all users who are affected. Finally, all policies should be updated to reflect changes in organization or culture.
One of the major goals of a policy is to implement control. Deciding on the level of control for a specific policy is not always clear-cut. The security needs and the culture of the organization will play a major role when deciding what level of control is appropriate. If you make policies too restrictive or too hard to implement and comply with, they will either be ignored (not implemented) or people will find a way to circumvent the controls in the policies.
When looking at trust, you have three basic models: 1. Trust everyone 2. Trust no one and 3. Trust some people at some time. In today's world it is not very common to find organizations that follow the model of trusting everyone all of the time or trusting no one at any time. The most common model is to trust some people some of the time and build trust over time. Also keep in mind that it may be appropriate to apply different trust models to different parts of the organization.
My experience in the field has consistently shown that security policies tend to elevate the level of tension in any given situation with the fact that people don’t like rules and restrictions in their activities. Everyone tends to view security needs differently: 1. Users are concerned about being able to get their work done without a lot of controls. 2. System support personnel are concerned about the ease of managing systems under tight control. 3. Management is concerned about costs versus protection. Getting all to agree of a policy is impossible so best is to try a Win-Win compromise.
To some extent everyone should be concerned of security policies as everyone is affected by them. The system users are typically affected the most as they see the policies as a set of rules to regulate their behavior making it more difficult for them to accomplish their job. The people who have to support the infrastructure are concerned since they are the ones who have to implement and comply by many of the policies. For example, a policy that requires all Windows Servers to be installed according to a baseline security standard would require more work on the part of the system administrators, not only for the initial install, but also for the system upkeep.
When planning policies, some organizations will go overboard and come up with something that will be impossible to implement and comply with. The bottom line for policies is they must take into consideration the balance of protection with the level of productivity hit. Policies should be concise and easy to read and understand. One thing to keep in mind when developing a policy is how it will affect legacy systems and other infrastructure that is already in place. Once the policies are fully approved, they should be made available to all users who are affected. Finally, all policies should be updated to reflect changes in organization or culture.
One of the major goals of a policy is to implement control. Deciding on the level of control for a specific policy is not always clear-cut. The security needs and the culture of the organization will play a major role when deciding what level of control is appropriate. If you make policies too restrictive or too hard to implement and comply with, they will either be ignored (not implemented) or people will find a way to circumvent the controls in the policies.
Tuesday, April 28, 2009
Hitler and CNC
I found this hilarious video on JD Edwards CNC, hoping you all enjoy it too. Kindly read the subtitles.
JD Edwards E1 Complete Reference
Authors: Allen Jacot, Joseph Miller, Michael Jacot, John SternYour definitive guide to JD Edwards EnterpriseOne. Implement and maintain a fully integrated, SOA-based ERP framework across your entire corporation. JD Edwards EnterpriseOne: The Complete Reference explains how to install and administer JD Edwards EnterpriseOne, store BI information in data marts and warehouses, manage servers and portals, and develop customized applications and kernel processes. You'll also learn how to create and distribute packages, use the security workbench, optimize performance, and apply the latest JD Edwards EnterpriseOne updates and tools releases.
Set up and configure the JD Edwards EnterpriseOne applications suite. Work with Oracle, SQL Server, DB2, MSDE, and SSE data sources. Define JD Edwards EnterpriseOne path codes, task views, and environments. Deploy the object configuration manager and solution explorer. Build client and server packages, media objects, and data warehouses. Secure JD Edwards EnterpriseOne using LDAP, single sign-on, and third-party tools. Administer portals and Web sites using JD Edwards EnterpriseOne's HTML server and server manager. Troubleshoot and tune your system using the performance workbench.
Covers Release 8.12.
Subscribe to:
Posts (Atom)
