Via multiple channels Oracle appears to have embraced Web 2.0. The integration of Web 2.0 functionality with core ERP suites and through a wider framework using AIA will be interesting to watch.
Oracle already seems to have taken a step towards integrating Oracle CRM (part of Oracle E-business Suite) with social networking sites, as well as with the Blackberry RIM platform. It would be very useful to have RSS feeds from an ERP transactional system that would create a "push" mechanism to traditional ERP systems.
There is mixed opinion about this release (as is the case with most software releases). In summary this is an exciting development with a lot of promise. Something to keep a close watch on. It has the potential to create an entire ecosystem of wedge applications.
Monday, March 31, 2008
Thursday, March 27, 2008
Business Process Modeling Diagramming Options
There are various business modeling diagramming options. The choice of the modeling notification depends on the level at which the modeling is being. Each notification model has its benefits and drawbacks.
The Value Added Chain Diagram (VACD) is best suited for level 0 and level 1 diagrams. The Business Process Modeling Notification (BPMN) and the Event Driven Process Chain (EPC) modeling is more suited for level 2 and lower diagrams, which are generally more inclined towards implementation code.
Oracle's BPA suite supports all 3 modeling options. The BPMN and EPC models are both interpreted by the BPA server and can be converted to the BPEL blueprint and eventually to the BPEL process flows.
IDS-Scheer is inherently geared towards EPC modeling, however the newer BPMN standard is recommended if you are using the Oracle BPA suite, especially if the final intent is to create executable BPEL code.
The Value Added Chain Diagram (VACD) is best suited for level 0 and level 1 diagrams. The Business Process Modeling Notification (BPMN) and the Event Driven Process Chain (EPC) modeling is more suited for level 2 and lower diagrams, which are generally more inclined towards implementation code.
Oracle's BPA suite supports all 3 modeling options. The BPMN and EPC models are both interpreted by the BPA server and can be converted to the BPEL blueprint and eventually to the BPEL process flows.
IDS-Scheer is inherently geared towards EPC modeling, however the newer BPMN standard is recommended if you are using the Oracle BPA suite, especially if the final intent is to create executable BPEL code.
Tuesday, March 25, 2008
BPEL domains and OC4J
The Oracle BPEL_PM is a java application that can be deployed in any J2EE container. In the case of Oracle Application server it is deployed in Oracle's OC4J (Oracle Container for Java) container.
The OC4J container is hosted on an Application server. It is similar to an instance of a database. It should be managed and administered as a physical object. Property settings for the OC4J container affect all applications deployed within that container.
The BPEL domain is a logical partition. BPEL domains are created for logically separating different business process flows. Domains could be used to delineate dev and test environments in a stable production environment. They could also be used to delineate along functional or business areas. Domain settings affect all process flows that are deployed within that domain.
There can be multiple domains within a BPEL_PM instance running in an OC4J container.
The OC4J container is hosted on an Application server. It is similar to an instance of a database. It should be managed and administered as a physical object. Property settings for the OC4J container affect all applications deployed within that container.
The BPEL domain is a logical partition. BPEL domains are created for logically separating different business process flows. Domains could be used to delineate dev and test environments in a stable production environment. They could also be used to delineate along functional or business areas. Domain settings affect all process flows that are deployed within that domain.
There can be multiple domains within a BPEL_PM instance running in an OC4J container.
Thursday, March 20, 2008
NFS settings for RAC
Setting up RAC requires a shared disk architecture. Most of the documentation provided by Oracle provides a good sequence of steps to be followed to set up RAC and then to set up TAF (Transparent Application Failover). One of the issues that most first time implementers of RAC face is that the RAC instance does not start in spite of all the settings being correct.
This issue is not due to incorrect configuration of the RAC, but can usually be traced to missing settings in the shared disk mount point. One of the most common errors in NFS based shared systems is that not all the parameters have been correctly specified when the mount point is created. The NFS mount point must have the following parameters in a RAC environment:
cio,rw,bg,hard,nointr,proto=tcp,vers=3,noac,rsize=32768,
wsize=32768,timeo=600
Ensure that these settings are in place for a successful RAC implementation.
This issue is not due to incorrect configuration of the RAC, but can usually be traced to missing settings in the shared disk mount point. One of the most common errors in NFS based shared systems is that not all the parameters have been correctly specified when the mount point is created. The NFS mount point must have the following parameters in a RAC environment:
cio,rw,bg,hard,nointr,proto=tcp,vers=3,noac,rsize=32768,
wsize=32768,timeo=600
Ensure that these settings are in place for a successful RAC implementation.
Wednesday, March 19, 2008
Hardware sizing for Oracle EBS
Sizing hardware is always a challenge. The issue here is that production sized hardware usually needs to be procured even before the project has started. This is usually the case with organizations where Oracle and Oracle EBS is being installed for the first time. There is no prior version of the application, to benchmark against.
Most of the hardware vendors provide sizing spreadsheets that can be filled out, and a rough estimate of the computing power needed can be reached. This exercise usually helps in clarifying the SAN and disaster recovery architecture, but does not get to the specifics of the production hardware.
Each organization has unique access patterns and transaction patterns, and hence it is genuinely difficult to extrapolate hardware sizing between different organizations. The best approach is to procure the production database server (since this can usually be sized with a fair degree of accuracy) or the post-production development server. These can be used to start the implementation process, and once a certain level of organization specific configuration has bene completed, then production benchmarking can be accomplished.
There is some assistance available in the for of white papers and benchmarking for typical transaction loads. This link has a list of white papers on sizing for IBM, HP and Sun machines. This link provides detailed performance information for representative transaction loads.
When it comes to estimating the network bandwidth requirements the information is very scattered. There are no bench marks and thumb rules need to be applied. A usual CRM/imodule would have the same bandwidth requirements as a normal internet user. HOwever, power users, especially in the demand planning and forecasting space will require a higher bandwidth
Most of the hardware vendors provide sizing spreadsheets that can be filled out, and a rough estimate of the computing power needed can be reached. This exercise usually helps in clarifying the SAN and disaster recovery architecture, but does not get to the specifics of the production hardware.
Each organization has unique access patterns and transaction patterns, and hence it is genuinely difficult to extrapolate hardware sizing between different organizations. The best approach is to procure the production database server (since this can usually be sized with a fair degree of accuracy) or the post-production development server. These can be used to start the implementation process, and once a certain level of organization specific configuration has bene completed, then production benchmarking can be accomplished.
There is some assistance available in the for of white papers and benchmarking for typical transaction loads. This link has a list of white papers on sizing for IBM, HP and Sun machines. This link provides detailed performance information for representative transaction loads.
When it comes to estimating the network bandwidth requirements the information is very scattered. There are no bench marks and thumb rules need to be applied. A usual CRM/imodule would have the same bandwidth requirements as a normal internet user. HOwever, power users, especially in the demand planning and forecasting space will require a higher bandwidth
Subscribe to:
Posts (Atom)