2-6 Oracle Fusion Middleware Services Reference Guide for Oracle Universal Content Management
2.
The Web server recognizes this request as an Oracle Content Server function and sends the specific request to the Oracle Content Server system.
3.
When the Oracle Content Server system has processed the request, it passes the result back to the Web server. In the case of the Administration link, the GET_
ADMIN_PAGE service:
■
Provides a login prompt if the user is not currently logged in.
■
Verifies that the user has admin permission.
■
Assembles the Administration page using the ADMIN_LINKS template.
■
Returns the assembled web page to the Web server.
4.
The Web server delivers the results of the Oracle Content Server service to the originating Web browser client.
Example The following example describes the steps that occur when a persistent URL is used to
perform a search request.
1.
When a user clicks the Search button on the standard Search page, a request for the GET_SEARCH_RESULTS service is sent to the Web server. The URL for the
search request specifies the service to execute, the search criteria, and the result parameters:
IdcService=GET_SEARCH_RESULTSQueryText=oracleftx=1 AdvSearch=TrueResultCount=25SortField=dInDateSortOrder=Desc
2.
The Web server recognizes the request as a Oracle Content Server function, and sends the specific request to the Oracle Content Server system.
3.
The Oracle Content Server system passes the request to the search engine.
4.
The search engine returns the search results to the Oracle Content Server system.
5.
Based on the user login and security permissions, the Oracle Content Server system assembles the search results page and returns it to the Web server.
6.
The Web server delivers the results to the originating Web browser client.
2.1.6 Customizing Locale Parameters
When using the Oracle Content Server system in a client server operation mode, you can use several parameters to improve the handling of locale-sensitive data, helping to
avoid date and encoding incompatibility problems.
In the following descriptions, it is assumed that an HDA formatted request is being made to the Oracle Content Server system using an operation such as IdcClient,
IdcCommandUX, IdcServerBean, or a custom server communication.
The following parameters are available:
■
UserDateFormat: Specifies the datetime format for dates in the incoming request and any dates produced in the response to the request. If not specified, the
response format always uses the login users date locale. If that is unavailable, it uses the Oracle Content Server system locale date. Do not use the ODBC
datetime format used internally by the Oracle Content Server system for archiver batch load files; that can create time zone ambiguity errors.
UserDateFormat=MDYYYY hh:mm[:ss]{aa}mAM,PMzUTC
Using Services 2-7
■
blDateFormat : Specifies the format of dates in the body of the incoming request.
It does not affect the format of the response. If set, this overrides values set with UserDateFormat
. If not specified, the incoming request format uses the login users locale date format. If that is unavailable, it uses the Oracle Content Server
system locale date format. This parameter is not available except if one of the headers that precedes the request is a REQUEST_METHOD header with a POST
value. GET style requests do not support this parameter.
■
ClientEncoding : Specifies the character encoding to be used in the response. If
no HDA header line exists with either the charset or jcharset specification, this parameter also dictates the encoding used to decode the body of the request.
ClientEncoding=cp1252
■
HEADER_ENCODING : Used in the header that precedes the body of the HDA
request. This allows the requesting agent to specify the encoding of headers. This functionality is useful for dictating the encoding of the HTTP_INTERNETUSER and
REMOTE_USER header entities.
■
blFieldTypes : Specifies a field type date or message during the translation of a
response. A message is a formatted string, usually an error message, that has not been localized. You can use this parameter to ensure that ODBC formatted fields
are parsed and returned in the format specified by blDateFormat or UserDateFormat
and will be applied even if the field is only in the response and not in the request. If the field types are not specified in biFieldTypes, then
fields are treated like plain strings and no localization is performed on them. The only fields that typically need such translation are ones created by customized
extensions of Oracle Content Server behavior such as those created using Idoc Script, for example. This is only available for POST style requests REQUEST_
METHOD header with value POST. This is normally used to specify additional date
fields and is best used in combination with UserDateFormat or blDateFormat to indicate that a field needs special handling as a date.
blFieldTypes=xNewDate date, xComment message
■
extraFieldTypes : Specifies a field type during the translation of a response to
HDA formatted requests, used in place of blFieldTypes. It is best used inside an Idoc Script expression that is executed when fulfilling a Oracle Content Server
request. It cannot be used in Idoc Script when generating the format of the response because the response is in a data format such as HDA. It can, however,
be used in other places where Idoc Script is evaluated when executing the logic of a request, such as the processing of an HCSP form, or determining the effects of a
document profile.
extraFieldTypes=xNewDate date, xComment message
■
convertDatabaseDate : Ensures that blFieldTypes or extraFieldTypes
are used to convert the ODBC date format to the desired response date format. This variable is necessary when using the blFieldTypes or extraFieldTypes
variables.
If this variable is not set, the ODBC date formats may not be converted to the desired response date format. ODBC dates can still be converted even if this
variable is not set. This occurs if the Oracle Content Server system determines that the response needs a full coercion from one date format to another. This typically
happens only if the incoming date format is different from the outgoing date format.
convertDatabaseDate=1
2-8 Oracle Fusion Middleware Services Reference Guide for Oracle Universal Content Management
■
SuppressResultLocalization : Suppresses localization conversions
performed before the response is sent back. Conversions done on incoming data can still be performed.
This parameter is useful to prevent messages from being localized or dates being fully converted. An example of usage is when the response is to be forwarded to
another Oracle Content Server instance to be processed or when the data is to be persistently stored and replayed back to the original Oracle Content Server
instance as needed.
SuppressResultLocalization=1 All of the parameters that affect date and message processing can be used with
this parameter, but the other parameters are only used when the data is replayed against another Oracle Content Server instance or the current Oracle Content
Server instance.
2.1.7 Forcing Authentication Challenges