Points to be considered when using HTTP reception

HTTP reception does not support IPv6. Connect from HTTP client to HTTP reception by IPv4.
Set a valid HTTP header to set HTTP response header in http-header element of response message (header). HTTP reception does not verify whether HTTP header is valid.
HTTP reception does not support HTTP session management.
For session management functionality of the application server, see the following locations:
- "2.7 Session management functionality" in "Application Server Web Container Functionality Guide"
- "6. Database Session Failover Functionality" in "Application Server Expansion Guide"
- "6. Migration Function of Expansion Functionality (Memory Session Failover Functionality)" in "Application Server Maintenance and Migration Guide"
Even if text data does not exist in HTTP request, set the request message (body) to be set in the receive activity.
Even if text data is not returned in HTTP response, set the request message (body) to be set in the reply activity. For schema to be set, use the schema that the product provides.
If pass-through mode is used while passing HTTP request body to the business process and if httprecp.pass-through.parameter-use=true is specified in HTTP reception definition file, the following points are to be considered:
- Specify only 1 pair of "msg=value". If multiple "msg=value" pairs are specified, operation is not guaranteed. If msg key is not specified, error occurs.
- Specify all msg keys in lower case. If upper case characters are specified, error occurs.
- Specify a valid XML character string in HTTP request body. XML documents are not checked in HTTP reception.
- If multiple "=" are specified in the query character string or message body as in "msg=msg=abc", the first "=" is used as the separation character. In such cases, the part before the first "=" is read as the key and the entire character string after the first "=" is read as the value.
The following restrictions exist in text data transfer using HTTP reception and in file data upload or download:
- A business process must return a response to HTTP reception. Due to this, HTTP reception communication model cannot be asynchronous.
- Parallel processing of BPEL (FLOW) cannot be used.
- The maximum number of files that can be processed simultaneously with 1 request in HTTP reception is 1,024.
- If multi-byte characters are specified in part ID element and file-name element of the response message (header), operation is not guaranteed.
- The maximum number of files that can be specified to send file data in HTTP response is 1,024. If the number of specified files exceeds 1,024, operation is not guaranteed.
Consider the following points while transferring file data by using HTTP reception and allocate sufficient working folder disk size for each HTTP reception:
- Number of simultaneous executions
  If you can send HTTP request handling large files in large numbers once, consider the number of simultaneous executions to avoid high resource consumption.
- Assumed maximum HTTP request size
  The size and number of temporary files created while processing file data is same as that of intermediate files. Due to this, you must estimate in advance the maximum HTTP request to be sent.
- Processing of business process correlated to HTTP reception
  While generating files in the working folder by using the file operations adapter in the business process invoked from HTTP reception and storing the files acquired by HTTP adapter, in the working folder, you must consider in advance the file size generated according to the process. Consider the processing time till intermediate files and temporary files are deleted and design the business process.

Context root is used as the directory name in the working directory of Component Container. Therefore, you must specify a context root in which the path length of the entire working directory does not reach upper limit of OS. For maximum path length of OS, see the document on each OS in use.
The following table describes the configuration of the entire working directory of Component Container:

Configuration of entire working directory of Component Container									Remarks
Path till the working directory of Component Container\									-
	Working directory of Component Container\								Directory path is as follows: In Windows <Service platform installation directory>\CC\server\public In UNIX If slash (/) is specified in /opt/Cosminexus/CC/server/public context root name, value is replaced by 3 digit single-byte character.
		web\							-
			<J2EE server name>\						-
				<Context root name>\					-
					WEB-INF\				-
						classes\			-
							Directory hierarchy of package name of HTTP reception\		Directory hierarchy is jp/co/Hitachi/soft/csc/msg/message/reception/http/impl.
								HTTP reception class file	Longest file name is "CSCMsgHTTPServletContextListener.class".

Legend:: -: There is no applicable description.

You can calculate the path length of the entire working directory of Component Container using the following estimation method. Specify the context root so that this path length does not exceed the maximum path length of OS.
Path length of entire working directory of Component Container=A+2xB+C+D+E+F+25
A: Path length till working directory of Component Container
B: Length of working directory name of Component Container
C: Length of longest J2EE server name
D: Context root length (if symbols such as "/" are included, replace them by character x 3)
E: Length of directory hierarchy of package name of HTTP reception
F: Length of longest file name from among HTTP reception class files

2.13.10 Points to be considered when using HTTP reception