| Oracle® Retail Service Backbone Oracle® Retail Service Backbone Implementation Guide 14.1 E57331-01 |
|
 Previous |
 Next |
| Oracle® Retail Service Backbone Oracle® Retail Service Backbone Implementation Guide 14.1 E57331-01 |
|
Previous |
Next |
This chapter describes the RSB's administration and logging options.
RSB has following configuration properties to customize the RSB installation to your environment. After any configuration changes, the rsb-compiler must be run and then decorators and/or admin-application should be deployed to the server.
This variable must point to the JDK home folder. This is a mandatory property.
For example
JAVA_HOME=/u00/java/jdk1.7.0_07.64bit
This property holds the list of applications that act as service providers. The list is a comma separated list of the short app names. For example,
rsb-deployment-env-info.service-provider-app-in-scope-for-integration=rms,igs,sim,cm,oms,ooc,mms,rwms,fin,rpm,rm
This property holds the list of applications that act as service consumers. The list is a comma separated list of the short app names. For example,
rsb-deployment-env-info.service-requester-app-in-scope-for-integration=rms,rwms,sim,rpm,mms,reim,pos,ooc,oms,fin,rib4oms
This property holds the name of the WebLogic domain where the RSB is deployed.For example,
rsb-osb-container.domain-name=rsb_domain
This property holds the WebLogic domain home directory of the RSB installation. Replace the <Domain Name> with actual domain name.For example,
rsb-osb-container.rsb_domain.home=/u00/rsb/Oracle/Middleware/user_projects/domains/rsb_domain
This property holds the name of the cluster used when configuring the domain.
For example,
rsb-osb-container.rsb_domain.cluster-name=rsb_cluster
This property holds the URL for the HTTP Proxy server of the cluster.For example,
rsb-osb-container.rsb_domain.rsb_cluster.http-url=http://rsbhost:19707
This property holds the https URL for the HTTP Proxy server of the cluster. This property is needed only if the services are secured with https policies (like PolicyA).
For example,
rsb-osb-container.rsb_domain.rsb_cluster.https-url=https://rsbhost:19708
This property holds the URL for the Admin server of the clusterFor example,
rsb-osb-container.rsb_domain.admin-server-http-url=http://rsbhost:19701
This property holds the connection URL for the Admin server of the cluster.For example,
rsb-osb-container.rsb_domain.admin-server-connection-url=t3://rsbhost:19701
This property holds the names of managed servers in the cluster. The names are comma separated.For example,
rsb-osb-container.rsb_domain.rsb_cluster.managed-servers=rsb_server1,rsb_server2
This property holds the connection URL for each of the managed servers in the cluster. There should be one line item for each of the managed servers.For example,
rsb-osb-container.rsb_domain.rsb_cluster.rsb_server1.managed-server-connection-url=http://rsbhost:19703 rsb-osb-container.rsb_domain.rsb_cluster.rsb_server2.managed-server-connection-url=http://rsbhost:19705
This property holds the JDBC URL for the schema where the RSB_SERVICE_ACTIVITY table resides.For example,
service-infrastructure-db.jdbc-url=jdbc:oracle:thin:@rsbhost:1521:orcl
This property holds the connection URL for the edge application servers where the services are hosted. There must be one line item for each of the applications in scope.For example,
edge-app-container.rms.connection-url=t3://rsbhost:19720 edge-app-container.sim.connection-url=t3://rsbhost:19721
This property holds the URL pattern of the edge application web services. This pattern is used to generate the actual URLs of the services. Do not replace the entries in upper case with any values. This hard coded text, which gets replaced by the values taken from other property by the compiler. You should not change that text. You can modify the pattern (except the uppercase entries) to match the service URL. The pattern given above works for WebLogic hosted service. In that case, you do not have to change anything.
If the service is hosted in Glassfish, the pattern would be http://<HTTP_HOSTNAME>:<HTTP_PORT>/<SERVICE_NAME>Service/<SERVICE_NAME>Bean.
This property holds the application specific URL pattern for the web services. This is an optional property and you need to specify only when the application service URLs do not match the global pattern. If application pattern is present, the global pattern is ignored for that application. For example,
oms.app-service-end-point-url-pattern=https://<HTTP_HOSTNAME>:<HTTP_PORT>/<SERVICE_NAME>Bean/<SERVICE_NAME>Service
This property holds the decorator level URL pattern. This is an optional property and need to be specified only if the service URL do not match the application pattern or global pattern. This is the lowest granular level of control for the URL pattern. This entry need not be a pattern; you can provide the actual URL instead.
If a decorator level property is present, the app level and global level properties are ignored for that decorator. You can give any number of decorator level properties.
The global, app and decorator level properties give the complete control to specify any type of web service URLs.
For example,
rms-Supplier-AppServiceDecorator.app-service-end-point-url=https://rmshost:19721/SupplierBean/SupplierService
|
Note: Use service level pattern, if there are only few services with a different pattern. If most of the services in an application follow a pattern, use application level pattern and service level pattern for the exceptions. |
This property holds the path of rib-home, if RIB is installed. This is an optional property and is not needed for RSB only implementations. This property helps the compiler to extract RIB information and make it available in RIC. If present, the rib-home must be a valid installation.
rib-home and rsb-home must coexist in one file system but RIB runtime and RSB runtime can be deployed by any remote host. If rib-home is in a different host than the rsb-home, the compiler cannot extract RIB information.
For example,
rib.home.path=rib1@ribhost:/u00/rib/rib-install/Rib1410ForAll14xxApps/rib-home
There are a few properties in rsb-decorator-instrumentation.properties that determines the instrumentation. The services can be instrumented at the global level or service level. Two factors that affect this configuration are business requirements and performance. The tracing and audit are designed to persist the information asynchronously. It should not affect the main flow of execution other than just an asynchronous call to the data persistence code. However, if all the services are instrumented and there is very high transaction volume, performance of the server is affected. In those cases, the instrumentation is enabled based on service.
There are two levels of instrumentation: Trace and Audit. Tracing is the flag to enable instrumentation. Audit flag decides whether payload is also persisted along with other instrumentation data. Persisting the payload will have an impact on the size of the database since size of the payload bigger than the combined sizes of all other instrumented data. So the decision to audit should consider the overhead it has.
Tracing for all the service level is decided by the following property:
global.instrumentation.tracing.enabled
Audit for all the service level is decided by the following property:
global.instrumentation.auditing.enabled
Auditing and Tracing for a specific service is enabled by the properties <App>-<ServiceName>-AppServiceDecorator.instrumentation.auditing.enabled and <App>-<ServiceName>-AppServiceDecorator.instrumentation.tracing.enabled where <ServiceName> is the name of the service and <App> is the name of the edge app.Examples:
rms-PayTerm-AppServiceDecorator.instrumentation.auditing.enabled=true rms-PayTerm-AppServiceDecorator.instrumentation.tracing.enabled=true
Tracing and Auditing can be enabled while RSB is up. The server polls the property files at the specified interval and the new changes are in effect from that moment. The default interval is 10 minutes. If this interval does not suit the requirement, it can be changed by specifying new interval (in minutes) for the property:
instrumentation.property.reload.interval
Following steps show how to change the trace and audit properties:
Make changes to desired trace and audit properties in rsb-decorator-instrumentation.properties file.
Compile RSB using rsb-compiler.sh.
Deploy any decorator (just one decorator is enough). This will deploy the jar file containing the property to the server.
The changes will take effect in utmost 10 minutes (The default interval for the background task that runs to pick up the changes).
RSB uses many passwords during the installation. These usernames and passwords are stored in an encrypted credential wallet file under predetermined aliases.
Service Activity Schema (sidb-jdbc-user-alias)
WebLogic Server Admin (admin-server-user-alias)
RIC Admin (rsb-admin-user-alias)
If you are using Policy B for securing the services, there are additional credentials captured at compile time. If any of the passwords need to be changed, run the script setup-message-protection-security-credentials.sh to update the password in the credential wallet file. After updating the wallet file, run the script configure-rsb-app-server-for-security-policy-b.sh to update WebLogic server with new password(s) for policy B.
If any of the passwords need to be changed for any reason, follow the steps listed below.
Change the password of the target system (Database, WebLogic).
Run the rsb-compiler with -setup-security-credential option and update with new password.
Run rsb-deployer.sh with -prepare-wls option.
Deploy decorators, service integration flow, and admin application.
The trace and audit information is maintained in the RSB_SERVICE_ACTIVITY table. The contents of the table can be viewed through RIC. The Trace and Audit Log page in RIC allows users to filter the content by server by app name, message family, service name, time and time interval.
In RSB, the decorators are deployed to OSB cluster. When a consumer invokes a service, the invocation can happen in any of the managed servers of the cluster, depending on the load balancing algorithm. Each of the managed servers has its own log file. So the log information for the service execution will go to the log file of the managed server where the service got executed. This poses a hurdle when troubleshooting. RSB solves this issue by having the managed servers broadcast the log to the admin server. Thus the logs from all managed servers are made available in a single location.
Each of the managed server is enabled for log broadcasting. A global log filter (RSBLogFilter) is selected as the filter for selecting the log entries to be sent to the Admin Server. The default setting for this log filter is to send all the log entries. This is done using a log filter expression: "(SERVER LIKE '%')". The log filter expression may be modified, if only specific types of logs need to be broadcasted. For example, if the system requirement is to broadcast only message of certain log level, then the log filter expression needs to be modified to filter the entries accordingly.
The users can view the consolidated log its location or via the RIC application.
The default log file size or number of logs may not be adequate in a production environment. Every customer must choose the file size and number of files suitable for their environment. However, larger log file sizes may impact the performance of Retail Integration Console (RIC) pages that show log information.
To change the default size of the log file and the number of log files through WebLogic Admin console.
Click the domain name (rsb_domain).
Click the Logging tab to reach the screen.
Click Lock & Edit, if necessary.
Click Save and then Release Configuration, if needed.
