![]() ![]() ![]() ![]() ![]() ![]() |
This appendix describes functional changes in WebLogic Portal 9.2 and 10.0 that affect your upgraded environment and might require that you perform manual tasks.
This chapter includes the following sections:
The following sections describe changes that occur when you upgrade directly from WebLogic Portal 8.1 to 10.0. You might be required to perform manual tasks.
This section includes these topics:
New features added in WebLogic Portal 10.0 to support federated portal propagation require you to perform the upgrade procedures described in this section. This section includes the following topics:
WebLogic Portal 10.0 supports features of WSRP 2.0 that permit a more flexible and practical approach to propagation of federated portals. With WebLogic Portal 10.0, the consumer applications in staging and production environments can point to separate producers. The primary advantage of this new capability is that you can create and modify remote (proxy) portlets in a staging environment in isolation from the production environment.
Before WebLogic Portal 10.0, if you wanted to propagate WSRP consumer applications, the consumers on the source and destination systems had to point to the same producer. This configuration, which is described in detail in WSRP Propagation in the WebLogic Portal 9.2 Production Operations Guide, included several limitations.
This section explains the upgrade procedure for federated portals. The procedures described here apply to the following scenarios:
It is recommended that you upgrade both your consumer and producer applications to WebLogic Portal 10.0 in your source (staging) and destination (production) environments. Doing so allows you to take advantage of new propagation features and simplifies the propagation process.
Obtain the producer registration handles from each consumer application from both the source and destination systems. To do this, run the List Producers JSP utility as described in Listing Producer Handles.
Update the producer registration handles. To do this, run the Update Registration Handles JSP utility as described in Updating Producer Registration Handles.
Tip: | When you propagate, you can adjust the scope to include only the Portal Framework resources. |
This completes the upgrade process. It is now possible for consumer applications in staging and production environments to point to separate producers.
Note: | If you want to retain a configuration where consumers in staging and production point to the same producer, you can do so; however, limitations described in WSRP Propagation in the WebLogic Portal 9.2 Production Operations Guide will no longer apply. |
See the Production Operations Guide for detailed information on propagating portals.
If you upgrade your domain and producer application but not the consumers, you need to follow the upgrade procedure described in this section. The procedure described in this section applies equally whether the consumer application(s) are currently at WebLogic Portal 8.1.x or 9.2.
Note: | If you upgrade only the producer, you are required to use the propagation model described in WSRP Propagation in the WebLogic Portal 9.2 Production Operations Guide. In this model, consumer applications in both staging and production environments must point to the same producer. |
Note: | If you upgrade only the producer, you must perform steps 2 and 3 below each time you propagate remote portlets in your consumer applications. |
See the Production Operations Guide for detailed information on propagating portals.
If you upgrade your consumer application(s) but not the producer(s), you need to follow the upgrade procedure described in this section. The procedure described in this section applies equally whether the producer application is currently at WebLogic Portal 8.1.x or 9.2.
Note: | If you want to retain a configuration where consumers in staging and production point to the same producer, you can do so; however, limitations described in WSRP Propagation in the WebLogic Portal 9.2 Production Operations Guide will no longer apply. |
Note: | If you upgrade only the consumer(s), you are required to use the propagation model described in WSRP Propagation in the WebLogic Portal 9.2 Production Operations Guide. In this model, consumer applications in both staging and production environments must point to the same producer. |
Note: | If you upgrade only the consumers, steps 2 and 3 are recommended each time you propagate your consumer applications. |
Note: | If you are currently running a configuration where consumer applications in staging and production environments point to the same producer, the following steps are optional but recommended. |
Note: | If you upgrade only the consumers, steps 2 and 3 are recommended each time you propagate your consumer applications. |
Note: | You only need to run the utility described in this section on the systems where your consumer applications are deployed. |
This section explains how to run the List Producer JSP utility (listProducers.jsp
) on both the staging and production systems on which your consumer applications are deployed. This utility obtains the registration handles for producers that have been previously added to your consumers.
Note: | You must have administration privileges to run the JSPs. |
Note: | If your consumer application is deployed in a WebLogic Portal 9.2 environment, you must perform steps 1 and 2 below. If your consumer environment was already upgraded to WebLogic Portal 10.0, steps 1 and 2 are not required. |
listProducers.jsp
file from the following J2EE Shared Library. You can use an archive tool, such as WinZip, to extract the listProducers.jsp
file from the archive:
WEBLOGIC_HOME/portal/lib/modules/wlp-propagation-web-lib.war
listProducers.jsp
file you extracted into the web applications in which your consumers are deployed. Do this on both the staging and production systems.
http://
host:
port/
EarProjectNamePropagation/wsrp/listProducers.jsp
Where EarProjectName is the name of the enterprise application deployed to the server. For example:
http://localhost:7001/myEarPropagation/wsrp/listProducers.jsp
Note: | You only need to run the utility described in this section on the systems where your producer application is deployed. |
This section explains how to run the Update Registrations JSP utility (updateRegistrations.jsp
) on both the staging and production systems. This utility updates the registration handles for each consumer application the currently references a given producer.
Note: | If your producer application is deployed in a WebLogic Portal 9.2 environment, you must perform steps 1 and 2 below. If your producer environment was already upgraded to WebLogic Portal 10.0, steps 1 and 2 are not required. |
updateRegistrations.jsp
file from the following J2EE Shared Library. You can use an archive tool, such as WinZip, to extract the updateRegistrations.jsp
file from the archive:
WEBLOGIC_HOME/portal/lib/modules/wlp-propagation-web-lib.war
updateRegistrations.jsp
file you extracted into the web application in which your producer is deployed. Do this on both the staging and production systems.
http://
host:
port/
EarProjectNamePropagation/wsrp/updateRegistrations.jsp
Where EarProjectName is the name of the enterprise application deployed to the server. For example:
http://localhost:7001/myEarPropagation/wsrp/updateRegistrations.jsp
Note: | The Update Registrations JSP copies all portlets related to the destination registration handle and gives the copies the source registration handle. |
When you upgrade a Unified User Profile (UUP) from WebLogic Portal 8.1 to 10.0, the p13n_ejb.jar
file is deleted and replaced with a new version of the WebLogic Portal 9.2 file. The new p13n_ejb.jar
file is packaged in the library modules that ship with WebLogic Portal 9.2.
Perform the following steps to upgrade a UUP configured in WebLogic Portal 8.1 to WebLogic Portal 9.2:
.work
file and click Open. Verify that the check boxes for the UUP application are selected and click Next, as shown in Figure A-1.p13n-ejb.jar
file was removed from the EARContent directory of the UUP application.UUPExample.jar
) exists in the EARContent directory of the UUP application.application.xml
file in the <
UUPApplication>/EARContent/META-INF/
directory.p13n-cache-config.xml
file in the <
UUPApplication>/EARContent/META-INF/
directory:<p13n:cache>
<p13n:name>UUPExampleCache</p13n:name>
<p13n:description>Cache for UUP Example</p13n:description>
<p13n:time-to-live>60000</p13n:time-to-live>
<p13n:max-entries>100</p13n:max-entries>
</p13n:cache>
UUPExample.usr
) file exists in the data/src/userprofiles/
directory (or where your Datasync folder exists).
Two JSP tags, <ugm:login>
and <ugm:logout>
, are deprecated in WebLogic Portal 9.2 and 10.0. The <ugm:login>
and <ugm:logout>
JSP tags were moved from the ugm_taglib.jar
file to the auth_taglib.jar
file.
After you upgrade to 10.0, you should use the <auth:login>
and <auth:logout>
JSP tags. The attributes and parameters are the same.
If you are upgrading from WebLogic Portal 8.1 and used Autonomy search, you need to do the following to upgrade to the new version of Autonomy that is included with WebLogic Portal 10.0. The upgrade process does not automatically migrate your existing search settings and databases to the new search capabilities. You need to manually configure Autonomy search to work with your upgraded applications.
The new version of Autonomy is installed into the portal/thirdparty/autonomy-wlp100
directory. For more information about configuring Autonomy search, see the
Search Guide.
After installing and configuring Autonomy search, do the following to upgrade your application to use the new features:
If you wrote applications using the WebLogic Portal com.bea.query
classes or using the 8.1 Autonomy API and want to continue using these applications without using the new 9.2 version of the Autonomy API, you need to manually add the older, deprecated APIs to your application.
However, if you continue to use the 8.1 API (either WebLogic Portal or Autonomy's), those APIs will take priority over the 10.0 API and are NOT compatible with the 10.0 Autonomy engine. This means that some 10.0 content management features will not work, such as full-text search.
If you want to continue to use the 8.1 version of Autonomy with your portal application, you must manually add the older APIs to your installation.
To add the older Autonomy version to your 10.0 application:
autonomyCompat.jar
and autonomyClient.1.5.0.jar
from weblogic_home/portal/lib/thirdparty/search/81-compat-only
into the application_home/APP-INF/lib
directory.The 8.1 Autonomy APIs and engines are now running.
If you want to upgrade to use the 10.0 version of Autonomy, after you have completed the steps in Using 8.1 Search within a 10.0 Portal Application, you can reverse the implementation.
To upgrade to use the 10.0 version of Autonomy (after you have implemented 8.1 Autonomy with 9.2):
com.bea.query.*
classes or any calls to the Autonomy client APIs in your applications and replace them with the appropriate calls to the 10.0 version of the Autonomy API.autonomyCompat.jar
and autonomyClient1.5.0.jar
file from the app-inf/lib
directory.After the upgrade is complete, you must manually re-enter the passwords for your third-party repositories using the Administration Console; see the Content Management Guide for more information about editing repository settings.
Until you manually re-enter the passwords for your third-party repositories, you cannot access those repositories.
In WebLogic 8.1 through WebLogic Portal 8.1 SP5, content query expressions were generated differently due to an order of precedence problem. The order of precedence was not maintained when executing a content query expression. For example, the following expression: (a && (b || c), gets evaluated/executed as (a && b || c).
This problem was fixed in Weblogic Portal 10.0 such that the order of precedence is now maintained when executing a content query expression. However, if you want to continue using the WebLogic Portal 8.1 through WebLogic Portal SP5 query behavior, you need to modify your domain scripts to define the following system property: -Dwlp.disable.content.rule.fix=true.
Portal Look & Feels in WebLogic Portal 8.1 used two configuration files for skins and skeletons (in the /skins/<skin_name>
and /skeletons/<skeleton_name>
directories): skin.properties
and skeleton.properties
. Both were text files, and skeleton.properties
was optional.
In WebLogic Portal 10.0, both files are now XML, and both are required.
To upgrade a WebLogic Portal 8.1 Look and Feel to the WebLogic Portal 10.0 format:
The cm_taglib.jar
and the pz_compat_taglib.jar
are deleted when you upgrade and Import Wizard flags all JSPs that refer to these taglibs, which have an unsupported taglib URIs. The JSPs will fail.
The cm_taglib.jar
file was not installed by default in a new 8.1 web application, but if you added it to your application for backward compatibility, you must handle this file manually in your upgraded application.
Change all references to the cm_taglib.jar
and the pz_compat_taglib.jar
so that they use supported tags and APIs, and delete the obsolete jar files.
WebLogic Portal support for Struts is slightly different in 10.0 if you upgrade to Struts 1.2.
Struts 1.1 support in WebLogic Portal is the same as in previous releases, with the struts-adapter taglibs mapped to URIs using web.xml
. You can use the struts-1.1.war
library module instead of the new struts-1.2.war
library module.
If you are upgrading to Struts 1.2, instead of mapping the struts and struts-adapter taglibs using web.xml
, WebLogic Portal now relies on the JSP 1.2 implicit taglib mapping, wherein any .tld
files in the META-INF
directory in a JAR are implicitly mapped by the web container to the URI specified in the tld. For WebLogic Portal. these are in struts-adapter.jar
, in the path META-INF/tlds
.
Choose to use one of these two methods to upgrade to Struts 1.2:
http://bea.com/struts/adapter/tags-html
and http://bea.com/struts/adapter/tags-nested
for the HTML and nested taglibs, and http://struts.apache.org/tags-*
for the remainder of the taglibs that our adapter does not override..tld
s from both struts.jar
(in struts-1.1.war
) and from struts-adapter.jar
(in our portal web library module) and copy them to WEB-INF/tlds
. This allows for the case where you want to continue using the explicit tld mapping via web.xml
. In WebLogic Portal 8.1, minimized portlet states were persisted only for the session. You can use a workaround, described in the Upgrade Guide for Version 8.1, to set up a backing file that controls the states of portlets under the desktop.
The solution used in 8.1 will continue to work if you depend on this behavior, but BEA recommends that you use a new method of persisting the portlet state.
In 9.2, you can persist the portlet state in the database by using the persistence-enabled
attribute in the control-state-location
element of the netuix-config.xml
file.
Here is an example of the persistence-enabled
attribute:
<session persistence-enabled="true"/>
If you set the persistence-enabled
attribute to true
, then the control tree state will be loaded from the database when a user logs in, and the new state will be stored when a user logs out. The control tree state is cleared when a user interacts with a portal.
The default and the only persistence type implemented is JDBC. The default implementation uses the BEA_PORTAL_FRAMEWORK_CONTROL_TREE_STATE property set of the user's ProfileWrapper; the ProfileWrapper must be created and stored in the user's http session. The ProfileWrapper is created by PortalServletFilter, which should be configured in the web.xml
file. If the ProfileWrapper is not found in the user's session, the control tree state is not persisted.
Note: | Page flow- and struts-related states are not persisted, as they are not part of the control tree state; page flow and struts portlets might not be in the exact same state when user logs out. |
The child elements reader-class-name/writer-class-name provide reader and writer class names for this state-location. If you want to customize reader/writer behavior, you can implement the ControlStateReader/ControlStateWriter interfaces and configure them in the netuix-config.xml
file.
Producer and consumer applications developed with WebLogic Portal 10.0 are compatible with producers and consumers developed with WebLogic Portal 8.1. That is, a portal developed with WebLogic Portal 10.0 can consume portlets deployed in a WebLogic Portal 8.1 domain. Similarly, portlets exposed in a WebLogic Portal 10.0 producer can be consumed by an 8.1 consumer.
However, if you want to use your own key for the 8.1 or 9.2 consumer, you need to follow the procedures outlined the chapter Establishing WSRP Security with SAML in the Federated Portals Guide.
This section describes changes in how the encoding is set on the HTTP response.
In WebLogic Portal 8.1, the following method of setting encoding was used:
.portal
file for a directive.page
element. If that element is present, obtain the encoding from an attribute there.<encoding>
element in the <jsp-param>
section of the web.xml
file; the default is ISO-8859-1 if these elements are missing.Both of these mechanisms are now deprecated.
In WebLogic Portal 10.0, the following method of setting encoding is used:
netuix:desktop
element for an encoding
attribute, and use that value if present..portal
file for the deprecated directive.page
element. If that element is present, pick up the encoding from an attribute there.netuix-config.xml
for a <defaultEncoding>
element, and use the encoding
attribute there.<encoding>
element in the <jsp-param>
section of the web.xml
file.The old methods continue to work, but to eliminate any deprecation warnings, BEA recommends that you use the new mechanisms; for example:
<netuix:desktop ... encoding="UTF-8" />
in your.portal
file
<defaultEncoding encoding="UTF-8" />
in yournetuix-config.xml
file
When you select the desktop element from the portal view or outline view while editing a .portal
file, the workbench now includes a new encoding
property in the property view. The value for a new portal defaults to UTF-8
. You can edit the value using an editable drop-down menu.
The drop-down menu initially displays a list of all the basic IANA encoding values as well as the extended encodings for Chinese, Korean, and Japanese. The values presented in the list are descriptive display names that are converted to actual IANA names when saved to the .portal
file.
If a desired value does not display in the drop-down menu, you can type it in. When you press Enter, the validator checks the encoding to verify that it is a valid and supported encoding. The value you enter can be from the extended encoding set and can be an IANA name, alias, or canonical name for the encoding. If the encoding fails validation, a warning message displays; you can choose to override the validation and accept the value anyway. The value will be stored as is, in the .portal
file for the desktop encoding
attribute.
For compatibility with 8.1 and prior releases, and to support the few desirable uses of a disconnected desktop, WebLogic Portal 10.0 provides a new, but deprecated, boolean property called desktopStateShared
for the StandalonePortletURL
and the associated JSP tag. You can use this property to retain the previous "disconnected desktop" behavior. The default value of this property and attribute will be true
, causing the portlet to be connected to a desktop.
Explicitly setting either the path
or contextualPath
properties on the URL or tag also disassociates the resulting standalone portlet from its originating desktop. This also holds true for any URLs generated within the context of the standlone portlet—setting path
or contextualPath
causes the resulting URLs to become disassociated with the originating desktop.
In 8.1 and previous releases of WebLogic Portal it was possible, though not recommended, to create more than one portlet category with the same name, at the same level in the hierarchy. In 10.0, this operation is not permitted. (You can use the same name for more than one category, but they must not be "peers" in the hierarchy.)
When you upgrade a portal application to 10.0, any duplicate portlet category names that were used previously are preserved. It is extremely important that you edit these category names to be unique; otherwise the WebLogic Portal propagation tools might cause unexpected results, or errors might occur during the propagation process.
The Propagation Utility web application, propagation.war
, became obsolete as of WebLogic Portal 9.2. This application was introduced in a patch for WebLogic Portal 8.1 SP4 and later incorporated into WebLogic Portal 8.1 SP5. If you are upgrading a WebLogic Portal web application in which you previously installed the file propagation.war
into the root directory of any WebLogic Portal enterprise applications, it is recommended that you remove the file before or after upgrading to WebLogic Portal 10.0.
In WebLogic Portal 8.1, the capability to edit definition labels existed, but was not recommended. Modifying the definition label could have unintended implications; for example, exposing a protected resource or breaking WSRP (which uses the definition label as the portlet handle).
As of WebLogic Portal 9.2, this functionality has been replaced by a much richer ability to move portal resources (books, pages, desktops) between production and development environments, without losing user customizations or changing labels. These new features include XIP and the propagation utility. XIP allows you to target individual portal resources to import and export between development and production systems, and you can specify the scope (library, admin, or visitor). For more information about WebLogic Portal's propagation tools, see the Production Operations Guide.
WebLogic Portal inventories saved with WebLogic Portal 8.1 or 9.2 cannot be used with WebLogic Portal 10.0 propagation tools.
The following sections describe changes that occur when you upgrade from WebLogic Portal 9.2 or 9.2 MP1 to 10.0. You might be required to perform manual tasks.
This section includes these topics:
The procedure for upgrading federated portals from 9.2 to 10.0 is identical to the procedure for updating from 8.1 to 10.0. See Upgrading Federated Portals from 8.1 to 10.0 for these detailed instructions.
Your WebLogic Portal 9.2 or 9.2 MP1 UUP automatically works in WebLogic Portal 10.0. You do not need to upgrade your 9.2 UUP.
For backward compatibility to WebLogic Portal 8.1 and previous releases, and to support the few desirable uses of a disconnected desktop, WebLogic Portal 9.2 provided a new, but deprecated, boolean property called desktopStateShared
for the StandalonePortletURL
and the associated JSP tag.
Note: | This property is retained in 10.0 and is still deprecated. |
You can use this property to retain the previous "disconnected desktop" behavior. The default value of this property and attribute will be true
, causing the portlet to be connected to a desktop. Explicitly setting either the path
or contextualPath
properties on the URL or tag also disassociates the resulting standalone portlet from its originating desktop. This also holds true for any URLs generated within the context of the standlone portlet—setting path
or contextualPath
causes the resulting URLs to become disassociated with the originating desktop.
Upgrading search services involves updating your Autonomy configuration files and re-indexing your content.
Optionally, you can choose to migrate your existing Autonomy installation to use the 10.0 Autonomy installation directory. WebLogic Portal 10.0 ships with the same version of Autonomy as was shipped with WebLogic Portal 9.2, but the installation directory has changed. The new installation directory is:
\\WebLogic_HOME
\cm\thirdparty\autonomy-wlp10
For production environments, BEA recommends continuing to use the 9.2 installation directory (\\WebLogic_HOME\portal\thirdparty\autonomy-wlp92
).
For development environments, BEA recommends discontinuing the use the of the previous installation directory and using the new installation directory.
Note: | You MUST re-index your BEA content within your production environment, see the Integrating Search Guide for detailed instructions. |
Update all of necessary Autonomy configuration files to use the new location, see Configuring Autonomy on Your Target Server in the Integrating Search Guide for more details on Autonomy configuration files.
To continue to support double-quotes in your search queries, you must make the following changes to your BEACMRepoFetch.cfg file.
To support double-quotes (for example, "quotes"):
1. On the Autonomy host, edit the file at
//
autonomyhome/operatingsystem
/internal/BEACMRepoFetch/BEACMRepoFetch.cfg
For example, on a Linux host, this might be at
//
WebLogic_Home
/portal/thirdparty/autonomy/linux-intel/internal/BEACMRepoFetch/BEACMRepoFetch.cfg
2. In the [BEACMRepoIDXImport]
section, add the line:
ImportBifIncludeQuotes=true
To continue support of querying Japanese characters, you must make the following modifications to your AutonomyIDOLServer.cfg
file:
[FieldProcessing]
section, do the following:[FieldProcessing]
Number field value by one.19=SetLanguage
using one number greater than the largest number listed in the [FieldProcessing]
section.For example, change from this:
[FieldProcessing]
Number=19
0=SetIndexFields
...
18=SetMoreReferenceFields
[FieldProcessing]
Number=20
0=SetIndexFields
...
18=SetMoreReferenceFields
19=SetLanguage
[Properties]
section, add the following section:[SetLanguage]
Property=LanguageFields
PropertyFieldCSVs=*/DRELANGUAGETYPE
[Properties]
section, add a line of the form 19=LanguageFields
using one number greater than the largest number listed in the [Properties]
sectionFor example, change from this:
[Properties]
0=IndexFields
...
18=MoreReferenceFields
[Properties]
0=IndexFields
...
18=MoreReferenceFields
19=LanguageFields
[Security]
section, add the following section:[LanguageFields]
LanguageType=TRUE
Optionally, you can migrate your 9.2 Autonomy configuration to the 10.0 installation.
Note: | For upgraded production environments, BEA recommends continuing to use the existing 9.2 Autonomy location. |
To migrate your 9.2 Autonomy configuration and data to the new 10.0 location:
On the IDOL server, copy the following folders from the 9.2 location to the 10.0 location.
\\wlp-92\IDOLserver\IDOL\content\
folder, copy the following subfolders to the new content folder in the \\wlp-10\IDOLserver\IDOL\content\
location:\\wlp-92\IDOLserver\IDOL\indextasks\
folder, copy the following subfolders to the new \\wlp-10\IDOLserver\IDOL\indextasks\
folder:\\wlp-92\IDOLserver\IDOL\agentstore\
folder, copy the following subfolders to the new \\wlp-10\IDOLserver\IDOL\agentstore\
folder:\\wlp-92\IDOLserver\IDOL\category\
folder, copy the following subfolders to the new \\wlp-10\IDOLserver\IDOL\category\
folder:You need to export all indexed data from your 9.2 IDOL Server and re-import it into the 10.0 location.
Use the following command from your browser to export indexed content. Use the correct host name and port for your Autonomy configuration. You also need to indicate a file name, including a directory, to which to index content.
http://
host
:
port
/DREEXPORTIDX?FileName<
filename
>&Compress<true\false>
After exporting your indexed data from the 9.2 location, use the following command to import the content to the new WebLogic Portal 10.0 location. Use the correct host name and port for your Autonomy configuration and the file you created when you exported your data.
http://host
:port
/DREADD?<filename
>
After completing the above sections, you must re-index your BEA content. For detailed instructions on re-indexing BEA content, see the Integrating Search Guide.
Producer and consumer applications developed with WebLogic Portal 10.0 are compatible with producers and consumers developed with WebLogic Portal 9.2. That is, a portal developed with WebLogic Portal 10.0 can consume portlets deployed in a WebLogic Portal 9.2 domain. Similarly, portlets exposed in a WebLogic Portal 10.0 producer can be consumed by a 9.2 consumer.
However, if you want to use your own key for the 9.2 or 10.0 consumer, you need to follow the procedures outlined the chapter "Establishing WSRP Security with SAML" in the Federated Portals Guide.
If you created any propagation Ant scripts in 9.2, you must either manually update them or regenerate the scripts in 10.0. This change is required because several JAR file names have changed and the package name for all propagation Ant tasks has changed.
If you regenerate your scripts using Workshop for WebLogic, the correct filenames and package name will be used automatically. If you must update your scripts manually (for instance, if you created them manually in the first place), you need to make the following changes:
The propagation ant tasks are now located in the package com.bea.propagation.ant.taskdefs.
The following table lists the 9.2 JAR file names and the updated names for 10.0:
WebLogic Portal inventories saved with WebLogic Portal 8.1 or 9.2 cannot be used with WebLogic Portal 10.0 propagation tools.
![]() ![]() ![]() |