The range of business processes inheriting the Cookie information is described here.

1. From the first service invocation till execution of receive activity and reply activity
2. From the first service invocation till the business process instance ends

In the range of 1., the Cookie information is also inherited in the following cases:

• If the business processes are invoked hierarchically
  The cookie information is inherited even if receive activity and reply activity exist in the business process, which is being invoked.
  
• If a business process containing asynchronous receive activity is invoked
  If the communication model is asynchronous, reply activity cannot be deployed for the operation name defined in the receive activity. In such cases, the Cookie information is inherited only when there is no receive activity between invoke service activities.
  
• If a business process is invoked in which the activity is defined after the reply activity
  In such cases, Cookie information is inherited only when there is no receive activity between invoke service activities.
  
• If a business process is invoked in which wait activity is defined
  If there is a wait activity after a reply activity is executed, the Cookie information is inherited even if there is invoke service activity before and after the wait activity.
  

However, the Cookie information is not inherited in the following cases regardless of inheritance range:

• If the execution environment process is down
• If a request is to be processed in multiple execution environment processes
• If a process instance is re-executed

The Cookie information is inherited if all the following conditions are met for information on invoking of service components and for the information on the invoked service components:

• ON is specified in the cookie-parsing property of HCSC runtime definition file or the Cookie information is set in the header allocation variable in the invoke service activity that invokes a SOAP adapter.
• Character string of "Service component host name: Port number" matches completely.
  Each different host name specification format is handled as a separate URL. For example, if the same host is specified, when items specified in the host name and items specified in IP address are mixed, each is handled as a separate URL. At this stage, the Cookie information is not inherited. Also, if the port number is not set, there is comparison with a character string that does not contain ":Port number".
  
• path attributes matches in front.
  Examples of the cases when the front is considered as matching and as not matching are as follows:
  (Example) When front is considered as matching
  /sap and /sap, /sap and /sap/aaa, /sap and /sapaaa/bbb
  (Example) When front is considered as not matching
  /sap and /aaa, /sap and /aaasap/bbb, /sap and /aaa/sap
  

Notes

• The Cookie information inheritance is determined by "path attribute" of Set-Cookie header specifications of SAP ERP 6.0. However, "path attribute" is not considered while using SOAP communication infrastructure (SOAP1.1 mode) and only "Host name:Port number" is considered. Host name is considered, if port number is not specified.
• If Set-Cookie header does not contain path attribute, "path=/" is set as default value.
• If multiple "path" attributes are set as the attribute name in Set-Cookie header, as the following example shows, operation is to be performed by considering that "path=/" is set in path attribute.
  (Example)
  Set-Cookie: NAME=value; path=/sap/aaa; path=/sap/bbb
  
• If the Cookie information containing multiple different path attribute values is set in HTTP header, path attribute value is set in detailed order in HTTP header independent of Set-Cookie reading order.
  For example, if the next Set-Cookie header is received, "cookie:NAME3=value3; NAME2=value2; NAME1=value1" is set in HTTP header.
  (Example)
  Set-Cookie: NAME1=value1; path=/
  Set-Cookie: NAME2=value2; path=/sap
  Set-Cookie: NAME3=value3; path=/sap/aaa
  

If a value above "2" is set in methodtrace-level property of HCSC server runtime definition file, log is output in method trace.

(a) Unsupported specifications and attributes

• "domain attribute", "expires attribute" and "secure attribute" that are Set-Cookie header specifications in Netscape Communications are not supported.
• "Comment attribute", "Domain attribute", "Max-Age attribute" and "Secure attribute" that are Set-Cookie header specifications in RFC2109 are not supported.
• Set-Cookie2 specifications supported in RFC2965 are not supported.
• "JSESSIONID" is not supported. Session is managed in SAP ERP 6.0 by "sap-contextid attribute".

(b) Version attributes

• You can set Cookie version only in "0" (Set-Cookie specifications of Netscape Communication) or "1" (Set-Cookie specifications of RFC2109). Version is decided in the following order:
  
  1. If "expires attribute" is defined in Set-Cookie header, version is 0.
  2. If "Version attribute" is defined in Set-Cookie header, version is 1.
  3. If "Max-Age attribute" is defined in Set-Cookie header, version is 1.
  4. If none from 1-3 fits, version is 0.
• Set-Cookie header issued by SAP ERP 6.0 does not contain "Version attribute".
• If "Version attribute" differs in multiple Cookie information items, "Version attribute" value of the first Cookie information read is used.
• In case of operations by Cookie specifications supported by RFC2109, it is necessary to set "Version attribute" setup value in "cookie-version attribute" of Cookie header.