This chapter describes issues associated with Oracle B2B. It includes the following topics:
This section describes general issues and workarounds. It includes the following topics:
Section 15.1.1, "Non-administrator Users Can Perform Certain Administrative Tasks"
Section 15.1.2, "replyToAppMessageId Incorrectly Set in Ack Notifications"
Section 15.1.3, "Batched EDI Message State Changes for FA Do Not Consider Individual Messages"
Section 15.1.5, "Notification Is Not Available for an Ack Received for an EDI FA"
Section 15.1.6, "Oracle Enterprise Manager Displays Truncated Active Document Type Information"
Section 15.1.7, "FileNotFoundException Message After Saving an EDI Document Definition"
Section 15.1.8, "Incorrect User Information for Receipt Notification (AS2 MDN) to AQ"
Section 15.1.9, "Application Message Report Displays Incorrect Document Type"
Section 15.1.10, "Generated MDN Incorrectly Uses Name Identifier in Inbound Agreement"
Section 15.1.11, "Oracle B2B Signs MDN Using the Algorithm Set in the Agreement Delivery Channel"
Section 15.1.14, "Sending an Unknown AS2 From-Header Is Not Recognized as an Error"
Section 15.1.15, "Incorrect URL in the Wire Message for a Received Synchronous MDN"
Section 15.1.19, "XEngine Is Not Installed on the Second Node in a Clustered Environment"
Section 15.1.21, "Messages Remain in MSG_WAIT_ACK State After Receiving Acknowledgement"
Section 15.1.22, "EDI Batching Results in Incorrect Average Message Size on Metrics Page"
Section 15.1.23, "Setting a Property Back to Null on the Configuration Page Generates an Error"
Section 15.1.25, "Updating a Schedule May Result in Batched Messages Not Being Picked Up"
Section 15.1.26, "Do Not Purge Instance Metadata When Messages Are Being Processed"
Section 15.1.27, "Test Page for B2BMetadataWSPort Is Not Found"
Section 15.1.29, "ebMS Negative Acknowledgments for Decryption and Signature Failures"
Section 15.1.30, "Issues When Resubmitting Messages Using the AS2 Exchange"
Section 15.1.31, "Instance Data Access Java API Is Not Available"
Section 15.1.35, "Settings for Large Payloads When Using Enqueue Scripts"
Section 15.1.36, "Batch with One Error in the Outbound CONTRL Message"
Section 15.1.37, "FTPS Connection Times Out with Implicit SSL Encryption"
Section 15.1.38, "%ACTIONNAME% Filename Format Is Not Recognized"
Section 15.1.39, "RosettaNet Message Encoded in UTF-16 Fails at the Receiver's End"
Section 15.1.40, "RosettaNet Delivery Channel Settings on Inbound Side"
Section 15.1.41, "Save Autogenerated Agreements Before Deployment"
Section 15.1.42, "Permanent MLLP Delivery Channels Can Become Transient After Activation"
Section 15.1.43, "Upgrading from Oracle Integration B2B 10g to Oracle B2B 11g"
Section 15.1.44, "Some Listening Channel Details Are Not Relevant for the Selected Protocol"
Section 15.1.45, "FTP Listening Channel Does Not Have Proxy Support"
Section 15.1.49, "Even with the Log Level Set to Default, Details Are Written to the Log File"
Section 15.1.50, "B2B Interface Does Not Show the Custom Trading Partner Icon"
Section 15.1.51, "Enabling Multibyte Support for EDIFACT and HL7 Documents"
Section 15.1.52, "Use UNICODE in the Payload Header for an HL7 Document with Multibyte Characters"
Section 15.1.53, "Using Document Definition Names with Multibyte Characters in JDeveloper"
Section 15.1.54, "Do Not Use the anyType Document Handling Option with JMS"
Section 15.1.55, "Use Version 1.0 of the ecs and XSD Files for an EDIFACT CONTRL Message"
Section 15.1.56, "NULL May Be Displayed in the Document Definition Names for Cloned Partners"
Section 15.1.57, "Suppressing Validation Errors on Extra Elements in HL7 Messages"
Section 15.1.58, "Oracle B2B in High Availability Environments"
Section 15.1.60, "Methods for Recovering Messages in High-Stress Environments"
Section 15.1.61, "Inbound ebMS Messages Checked Irrespective of Duplicate Elimination Setting"
Section 15.1.63, "SOA Infrastructure Schema Prevents the Use of Edition-Based Redefinition"
Section 15.1.65, "No Agreement Found for One Inbound Batched Document Type Errors All"
Although the Save button is not displayed on the Agreement page for remote partner administrators, these users can update and save agreements by editing the agreement name on non-deployed agreements, and then updating and saving the agreements. Oracle B2B does not check the user authorization in this case.
Oracle B2B offers a notification of an Ack (AS2-MDN or EDI-FA) that is sent back to a composite or AQ (IP_IN_QUEUE) if configured using the Oracle B2B interface (Administration > Configuration page). The received Ack notification appears similar to the following:
<Acknowledgment xmlns="http://integration.oracle.com/B2B/Acknowledgment" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <replyToB2BMessageId>0AB1FE0211FE933570200000120666E0</replyToB2BMessageId> <replyToAppMessageId>0AB1FE0211FE933570200000120666E0</replyToAppMessageId> <ackB2BMessageId>0AB1FE0211FE9338CB80000012066930-1</ackB2BMessageId> </Acknowledgment>
Note, however, that the replyToAppMessageId is always incorrectly set to be the same as the replyToB2BMessageId.
In a batched message, if multiple documents batched as part of a single message have different settings for the FA in the agreement, Oracle B2B uses the FA setting for the first document and applies the setting to all other documents in the batch.
In the outbound case, documents that do not require functional acknowledgement wait on the FA with a status of MSG_WAIT_FA. In the inbound case, documents for which the FA need not be produced are generated and this can cause FA documents to transition to the MSG_ERROR state if there are no deployed agreements for the FA.
Note the following:
If an exception occurs during an outbound batch, the batch is not cleared from the repository. This is true even if a trigger has been fired. In this case, you must manually delete the scheduled batch entry using the Administration > Manage Batch page in the Oracle B2B interface.
If you disable a single time invocation batch schedule, any messages set in WAIT_BATCH mode remain in this mode if the schedule is not re-enabled before the expiry time. Furthermore, a new batch schedule created for the same document will not process these messages. The workaround is to resend the message using the resubmit application message option.
Receipt notification does not occur for an Ack (AS2-MDN) received back for an EDI FA document that was sent.
In the Oracle Enterprise Manager B2B Infrastructure (SOA Binding) page, the Top 5 Active Document Types section displays inbound messages received using the AS2 exchange showing only the DocumentTypeName instead of DocumentProtocolName DocumentProtocolVersion DocumentTypeName. For example, 850 may display instead of EDI_X12 4010 850.
After creating an EDI document definition, accessing and saving the document definition (when no updates have been made to the ecs file) can cause a FileNotFoundException message to be generated.
When delivering a receipt notification (AS2 MDN) to AQ, Oracle B2B incorrectly sets the user information to the document routing ID (if the outbound document has a document routing ID set) instead of b2backuser.
The application message report in the Oracle B2B interface incorrectly displays document types. Specifically, the application message report displays the following:
For receipt messages, the displayed document type is for the outbound message. If you want to collect metric data on the number of inbound application messages for a specific document type, the issue can cause queries to report incorrect data.
For FA messages, the displayed document type is the same as the FA message type.
In synchronous AS2 mode, the generated MDN uses the AS2 Identifier set in the inbound agreement. If no AS2 Identifier is defined in the agreement, then the generated MDN incorrectly uses the name identifier. The workaround is to set the expected AS2 Identifier in the inbound agreement.
In AS2, a request for a signed MDN from the recipient can specify the algorithm to use for signing. Oracle B2B, however, incorrectly signs the MDN with the algorithm set in the agreement delivery channel. This algorithm may be different from the requested algorithm.
In the Oracle B2B interface, the default time to initiate an event in the Administration > Configuration > Schedule Batch page is 10 minutes ahead of the current server time. However, if you launch the scheduler between 11:50 PM and midnight, then this default time setting does not work properly.
If the Oracle B2B interface is running in two Web browsers or Web browser windows (on the same or different computers), then actions performed in one instance of the Oracle B2B interface may not be automatically reflected in the other running instance. For example, importing metadata in one instance of the Oracle B2B interface is not reflected in the other instance, even after performing a browser refresh.
Clicking on another tab in the Oracle B2B interface and then returning to the previous page causes the information to refresh correctly.
When receiving an EDI document over an AS2 exchange, if Oracle B2B fails to identify the trading partner using the AS2 From Identifier, Oracle B2B tries to identify the partner using the EDI Interchange and Group ID. The failure to identify the partner by the AS2 Identifier is ignored.
The synchronous MDN received by the host server in response to an AS2 message sent over SSL shows an incorrect URL in the wire message. Specifically, the URL indicates the HTTPS protocol while the port information is for the HTTP listen port.
Setting an invalid EDI Interchange ID Qualifier or an invalid Function Group Identifier (not part of the default ecs Qualifier Standard Code List_105 or Function Identifier Code Standard Code List_479 respectively) is not signalled as a MSG_ERROR in the outbound case. Oracle B2B instead delivers the message to the configured endpoint without error.
When a B2B channel is configured to retry following an error (such as a transport channel being unavailable) and the message is subsequently successfully delivered, Oracle Enterprise Manager fails to adjust the corresponding error count.
When validating an agreement, Oracle B2B validates the saved data. Oracle B2B does not validate any unsaved changes that you make to an agreement.
In a clustered environment, the XEngine is not installed on the second node when the node is on another computer. This is because the XEngine extraction occurs only when you run the Configuration Wizard (which is not run automatically on the second node). The workaround is to perform the XEngine extraction manually and then restart the server.
When you change the identification fields of a custom document (such as the XPath expression, value, start-position, or end-position, among others), you must retire and purge all agreements referring to the document definition before redeploying the agreements so that the changes take effect. Note that redeploying the agreements without purging does not ensure an update of the identification fields in memory.
When sending EDI messages batched over the AS2 exchange protocol, only one message transitions to the MSG_COMPLETE state after receiving an acknowledgment (MDN). All other messages remain in the MSG_WAIT_ACK state.
When Oracle B2B batches multiple messages into a single message, the native message size for each business message is recorded as the size of all messages in the batch. This results in Oracle B2B reporting an incorrect average message size on the Metrics pages of the Oracle B2B interface.
When using the Administration > Configuration page in the Oracle B2B interface, after you enter a value for a property and save it, you cannot change the property value to null. Doing so causes the Oracle B2B interface to generate the following error:
The value must be of the following type: Type Name: non-empty-string Base Type: string Primitive Type: string With the following constraints: minimum length: 1 Value '' does not satisfy '' facet : minLength
Furthermore, after receiving this error, you cannot update any other values on the Administration > Configuration page. The workaround is to navigate to another page, return to the Administration > Configuration page, and then update the values.
After deleting a user using Oracle WebLogic Server Administration Console, the user continues to appear in the Oracle B2B interface for approximately five minutes. This is because the user information remains cached in the managed server (Oracle B2B) for a user-configurable period of time. Performing certain operations, such as provisioning this user, can generate an error.
The workaround is to wait for longer than five minutes after deleting a user using Oracle WebLogic Server Administration Console.
Alternatively, you can specify the following system property in the setDomain.cmd file to disable the cache:
-Dweblogic.security.identityAssertionTTL=-1
In some cases, Oracle B2B may not pick up batched messages when you update the batching schedule. If you see that batched messages are not being picked up, delete the batch and create a new batch schedule with the same name as the previous batch. The same name must be used so that Oracle B2B picks up the previous messages in WAIT_BATCH status.
Do not purge instance metadata (using the Purge Instance Metadata button on the Administration > Purge tab) when messages are being processed. Doing so can result in messages in progress being lost. Instead, use the b2bpurge command-line utility, which accepts a date range and message state as arguments. When using the b2bpurge command, remove messages in the Completed state only (unless you have a specific reason for doing otherwise).
The test page for B2BMetadataWSPort results in a "404 Not Found" error. The workaround is to change the port number in the URL for the link from the managed server port to the admin server port (7001) and try again.
In a clustered environment, do not use the B2B command-line utilities for purging data, importing data, and exporting data. Use the Oracle B2B interface for these functions.
For ebMS documents, negative acknowledgments for decryption and signature failures are sent as security severity errors. For all other negative ebMS acknowledgments, the error is set as UnknownError.
Under certain circumstances, resubmitting an asynchronous AS2 inbound wire message does not work as expected. For example, change the state of an inbound agreement to inactive. On receiving a message, a negative acknowledgment is generated and sent back. The sender sees the message state as MSG_ERROR on receipt of the negative acknowledgment. Resolve the issue on the inbound side by changing the agreement state from inactive to active. Now two scenarios for resubmitting the asynchronous message exist:
Scenario A: Resubmit the wire message at the sender's side. Because the message was already processed at the receiver's end, this results in a duplicate error message.
Scenario B: Resubmit the wire message at the receiver's end. This passes at the receiver's end and pushes back a positive acknowledgment message. However, the state of the message on the sender's side is not changed. Although scenario A can be expected, scenario B should have worked. However, because the state of the message is MSG_ERROR, the incoming positive acknowledgment is ignored. This results in inconsistency in reporting at the two ends. The inbound side passes the message to the back-end successfully, whereas the outbound side has the message in the MSG_ERROR state.
The Oracle B2B Instance Data Access Java API is not available in this release. The API will be available in a future release.
The predefined callout, XSLTCallout, is not available in this release.
Allow pop-ups (disable the browser pop-up blocker) to use the Oracle B2B online help.
Based on the database load and the application server load, tune the transaction timeout setting in the Oracle Weblogic Server Administration Console. Select JTA from the home page and increase the default setting of 30 to a higher value.
Set the following properties in the enqueue.properties file when enqueuing large payloads:
payload=payload_filename_with_absolute_path
eventName=LARGE_PAYLOAD=true
Because the full directory path must be provided, use the local computer for this operation.
If a CONTRL message contains multiple document types and one document is in error, then one ORDERS message remains in the MSG_WAIT_FA state.
Consider the following example:
A batch containing the following is sent from Acme to GlobalChips:
ORDERS
ORDRSP
ORDERS (duplicate GUID)
ORDERS (new GUID)
The outbound message is sent with one ORDERS message in the MSG_ERROR state, as expected. The other messages are in the MSG_WAIT_FA state. The inbound FA (CONTRL) updates only the status of one ORDERS and one ORDRSP message. The result is that one ORDERS message remains in MSG_WAIT_FA.
Implicit SSL encryption is not supported in the transport layer.
The %ACTIONNAME% filename format is not recognized when used with the File, FTP, and SFTP transport protocols.
Oracle B2B is unable to process an inbound RosettaNet message encoded as UTF-16. A document protocol identification error is returned.
The RosettaNet delivery channel security settings for an inbound agreement must be set as follows:
When sending back an unsigned receipt acknowledgment message, set both Message Signed and Ack Signed to false (do not select the boxes).
When sending back a signed receipt acknowledgment message, set both Message Signed and Ack Signed to true (select the boxes). Select the signature algorithm and certificate alias as required.
Save autogenerated agreements at least once before the agreements are deployed. The agreement parameter settings for translation/validation and FA are generated in the agreement only when you save an agreement and not when it is autogenerated. Although the interface may show the default values, they are not captured in the agreement metadata and are ignored at run time; that is, the inbound EDI message may not be translated.
When creating an MLLP client delivery channel specified using a host name and a permanent connection, the permanent delivery channel can become transient when the in-flight message establishes the connection to the server. The workaround is to use an IP address instead of the host name when creating the client MLLP delivery channel. However, if the connection is pre-established (by enabling the client channel to establish the connection), then the connection works as a permanent connection.
See the following for upgrade information:
On the Listening Channel tab, some parameter fields that are displayed in the Channel Details area based on your protocol selection are not relevant to that protocol. Entering a value for these parameters has no effect. Table 15-1 lists the parameter fields that are not relevant.
Table 15-1 Fields That Display but Are Not Relevant for the Selected Protocol
| If you select this protocol... | Then you can ignore these parameter fields... |
|---|---|
|
AS1-1.0 |
Subject, Send as attachment, Ack Mode, Response Mode, Retry Count, Retry Interval, all fields on the Security tab |
|
Generic File-1.0 |
Retry Count, Retry Interval |
|
Generic AQ-1.0 |
Retry Count, Retry Interval |
|
Generic FTP-1.0 |
Use Proxy, Retry Count, Retry Interval |
|
Generic SFTP-1.0 |
Retry Count, Retry Interval |
|
Generic JMS-1.0 |
Retry Count, Retry Interval |
|
Generic Email-1.0 |
Subject, Send as attachment, Retry Count, Retry Interval |
The Generic FTP-1.0 protocol for a listening channel does not have proxy support.
When using the b2bpurge command-line utility, if inactive channels exist, then those listening threads are not terminated. The workaround is to repeat the b2bpurge call two or three times until the listening threads for the inactive channels are terminated.
If you select multiple agreements to export (from Administration > Import/Export), and any of those agreement names are in a multibyte character language, then in the export ZIP file, which contains a separate ZIP file for each agreement, the ZIP file names for the agreement names with the multibyte characters are garbled. The ZIP files with the garbled names are corrupted and cannot be successfully imported. However, a single agreement name (or repository name) in a multibyte character language is exported correctly.
For an inbound agreement that uses an ebMS exchange with the Ack Mode parameter set to asynchronous, an ebMS delivery channel is required.
Normally the default log level suppresses details in the log file. However, for RosettaNet deployments, log details are not suppressed even with the default log level setting.
If you use a custom icon for a trading partner (a PNG image file) and export the entire repository, then the icon image file is present in the exported configuration (ZIP file). However, if you import the ZIP file to another B2B server, then the custom icon for the trading partner does not appear in the B2B interface.
The workaround is to do the following:
Move the image file for the trading partner from the images directory to the images\tpIcons directory.
The images directory is located under the b2bui directory. For example, the directory path looks something like
DOMAIN_HOME\servers\soa_server1\tmp\_WL_user\b2bui\xov2md\b2bui\images
Rename the PNG image file to remove the prepended string, tpIcons.
The directory name is added to the image file name. To preserve the image file name, remove the prepended directory name. For example, if your original image file name is TP_ICON_tp_dGL-8506012758410451620_mobile.png, then after moving it, rename it from tpIconsTP_ICON_tp_dGL-8506012758410451620_mobile.png back to the original file name, TP_ICON_tp_dGL-8506012758410451620_mobile.png.
For documents using the XEngine, such as EDIFACT and HL7 documents, when you have a payload with multibyte characters that are not in the EDIFACT and HL7 document character set registry, you may see the error, "A data element contains characters not listed in the allowed character set."
To avoid this error, create a custom character set (CS) file in Oracle B2B Document Editor called user.cs:
In Oracle B2B Document Editor, click Tools > Character Set Registry.
In the Character Set Registry window, select the character set you want to override.
For example, you may want to override EDIFACT UNOB CS or HL7 CS.
Click the Duplicate icon.
In the Duplicate Character Set Properties window, accept the defaults and add the specific multibyte characters at the end of the Charset blank; then click OK.
With the duplicated file still selected, click the Export icon.
Name the file user.cs and save it.
Copy user.cs to
ORACLE_HOME/soa/thirdparty/edifecs/Common
Now documents such as EDIFACT and HL7 will use the user.cs file instead of the default CS file to verify the payload file.
If the a01.xml payload for an HL7_2.3.1_ ADT_A01 XML document contains multibyte characters, then, to support multibyte characters, you must change the MSH.18 element in the payload from <MSH.18>ASCII<MSH.18> to <MSH.18>UNICODE</MSH.18>. If the UNICODE value is not included, you will get the error "Sub-Component PID5-1-1 (family name) contains characters not listed in the allowed character set." You must also create user.cs and modify it to contain the multibyte characters. See Section 15.1.51, "Enabling Multibyte Support for EDIFACT and HL7 Documents," for more information.
When working with document definition names with multibyte characters (MBCS-named document definitions) in the B2B Configuration Wizard in JDeveloper, you may see the error " Invalid UTF8 encoding" at the step where the document definitions are loading for you to select the document definition for the service. This occurs when JDeveloper is running in a non-UTF-8 environment (for example, in Windows, using Simplified Chinese Win2k3, or in a native encoding Linux OS, using zh_CN.gb18030). However, in a Linux environment with UTF-8 encoding, such as zh_CN.utf8, MBCS-named document definitions load correctly. After loading, the MBCS-named document definition becomes the name of the document XSD folder in JDeveloper.
To ensure that MBCS-named document definitions load and display correctly in the B2B Configuration Wizard, do the following:
When using JDeveloper in a Linux environment, first set the LANG and LC_All environment variables to a locale with the UTF-8 character set. This enables the operating system to process any characters in Unicode. Then start JDeveloper.
When using JDeveloper in a Windows environment, start JDeveloper using UTF-8 encoding with jdev -J-Dfile.encoding=utf-8.
In the B2B Configuration Wizard in Oracle JDeveloper, do not select the anyType option on the Document Definition Handling - Advanced tab when using the JMS integration type. The anyType option allows you to use an XML document without specifying an XSD. However, when it is used with the JMS option to enqueue or dequeue, run-time errors result. Instead, use the opaque or the regular XSD-referenced settings to integrate when using JMS in the B2B Configuration Wizard.
For an EDIFACT document CONTRL message, you must use version 1.0 of the ecs and XSD files. Version 2.0 ecs and XSD CONTRL documents create validation errors for the outbound CONTRL message, which attempts to indicate an error for the failed inbound message.
Exports from an 11g R1 SOA - Oracle B2B installation that contain cloned trading partners will show null for document definition names for the definitions in the cloned trading partner. (This issue is not seen with partners cloned using the 11g PS1 SOA - Oracle B2B installation.) For example, the definition will appear as EDI_X12-4010-850-null.
When this occurs, recreate the document definition as follows:
Delete agreements associated with the document definition. (If you do not delete the agreement, trying to delete the definition produces an error.)
Delete the document definition.
Create the document definition and add it to the trading partner.
Create new agreements containing the document definition.
For HL7 messages, set HL7.AllowExtraData to false in XERegistry.xml to suppress validation errors on extra elements.
The XERegistry.xml file is located in the following directory:
SOA_HOME\thirdparty\edifecs\XEngine\config
See Section 6.2.13, "Message Sequencing and MLLP Not Supported in Oracle B2B HA Environments," for more information.
Transport callouts are not exported as part of trading partner or agreement exports. The channel contains the reference to the callout XML file; however, the file itself is not available. This causes import errors. The workaround is to export the entire repository to get the callout metadata along with the export ZIP file.
Use the following solutions to recover messages that would otherwise be lost in high-stress environments involving outbound messages with multiple instances of Oracle B2B running, each with multiple threads.
Situation 1: Duplicate File Names
In situations where all message file names, TPname_timestamp, are sent to the same directory, the timestamps include milliseconds; thus, in normal situations, all file names are unique. However, in high-stress environments, duplicate file names can occur, resulting in files being overwritten by a later file with the same name.
The solution is to append the unique MSG_ID value to file names. In the B2B interface, go to the Partners link and select a remote trading partner. Go to Channels > Transport Protocol Parameters. For channels where the Filename format parameter is applicable, add %MSG_ID% as a filename format macro. All file names will then be unique.
Situation 2: Exhausted Message Redelivery Attempts
If you see the message java.lang.RuntimeException: AppMessage is null:msg_id, a race condition may be indicated. A race condition occurs when a JMS event has been enqueued and dequeued for processing, but the corresponding message is not committed in the run-time repository. The B2B engine will retry the transaction, but it may fail if retry occurs immediately. If all retry attempts are exhausted, the event delivery transaction is rolled back and an exception message is sent to the configured exception queue, if an exception queue is configured.
To configure the exception queue and to resubmit exhausted redelivered messages from the exception queue to B2BEventQueue, use Oracle WebLogic Server Administration Console.
Do the following:
Create a queue and name it something like B2BEventException.
In the console, go to the settings for B2BEventQueue (Home > JMSModules > SOAJMSModule) and click the Configuration > Delivery Failure tab.
For Expiration Policy, select Redirect.
For Error Destination, select the queue you created in step 1 (for example, B2BEventException).
The messages that cannot be processed by B2B for the given redelivery count are forwarded to this error destination queue.
Move the messages from the configured error destination queue to B2BEventQueue to resubmit the messages for processing.
See the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help topic, "Manage queue messages," for how to move messages.
According to ebMS standards, Oracle B2B must check for duplicate inbound ebMS messages only if the DuplicateElimination tag is present in the ebMS message. However, currently, B2B tries to detect duplicate inbound ebMS messages irrespective of whether the DuplicateElimination tag is present or not in the ebMS message.
The @ symbol is not supported in Msgid.
Edition-based redefinitions are not supported for SOA B2B in the current release.
The Check Duplicate Control Number flag, available on the Miscellaneous tab of the Document Protocol Version page for an EDI document, is used to reject incoming EDI messages with duplicate interchange control version numbers. In a situation with multiple trading partners or multi-version batched messages, there are multiple interchanges. However, in this situation, Oracle B2B picks up the setting for the first interchange that it processes and then applies this setting to subsequent interchanges, irrespective of the settings. For example, if the first interchange is received for partner GlobalChips, which has the flag set to reject the duplicate interchange number, then B2B also rejects duplicate interchange numbers for subsequent interchanges, including for trading partners that may not have the flag set to reject duplicates.
In a batched, inbound EDI message containing multiple documents, failure to find an agreement for one of the documents causes the entire message to fail. The report shows only one business message for the failed document type and an error status. Other document types received as part of the batch are not seen in the reports.
Transport callouts are not available for listening channels.
In a multiple-node SOA server domain, the JMX framework propagates local changes to a file-based policy to each run-time environment, so that the data is refreshed based on caching policies and configuration.
In a multiple-node server environment, it is recommended that the domain policy and credential stores be centralized in an LDAP-based store. Otherwise, if they are file-based, then local changes to user privileges made in the B2B UI will not be properly propagated and can end up in error situations.
See Oracle Fusion Middleware Security Guide for more information.
This section describes configuration issues and workarounds. It includes the following topics:
Section 15.2.1, "Functional Ack Internal Properties Setting Ignored for HL7"
Section 15.2.3, "Unable To Set Ack Requested Field for Interchange"
Section 15.2.4, "Overriding Defaults in a Host Document Not Carried to the Remote Trading Partner"
Section 15.2.5, ""Query Sent to an Unactivated UnitOfWork" Exception"
Section 15.2.6, "Tablespace Configuration Recommendation for Production Environments"
Section 15.2.7, "Changes to Ignore Validation on Envelope Elements Setting Require Server Restart"
Section 15.2.8, "Enable Auto Search Feature Does Not Function"
For HL7, setting the Functional Ack internal property (FAInternalProperty) to false using the Administration > Configuration page in the Oracle B2B interface causes Oracle B2B to nevertheless use the payload header FA internal properties instead of the design-time parameters.
When the FAInternalProperty is set to true and there are different payload and design-time parameter values, you may see an error in the Ack message. Therefore, it is recommended that you do not set the FAInternalProperty to true for HL7.
Although the metadata for a remote trading partner stores separate information for the sender and the receiver for the same document definition, you cannot specify these differences using the Oracle B2B interface.
The workaround is to create a new document definition and use the two definitions to specify the parameters for the sender and receiver separately.
The Oracle B2B interface does not offer the ability to set the Ack Requested field for Interchange.
When creating a host document, including specifying the version, type, and definition, Oracle B2B assigns default values to certain fields that can be overridden by the user. If you override one or more nonmandatory fields by making them blank and then add the definition to the remote trading partner, the default values that you intentionally left blank reappear for the remote trading partner.
To resolve this issue, manually make the nonmandatory fields blank again for the remote trading partner.
When using any document protocol, the following exception appears in the seller's soa.log file:
oracle.toplink.exceptions.QueryException Exception Description: Query sent to an unactivated UnitOfWork.
The workaround is to increase the JTA timeout from 30 to a higher value using Oracle WebLogic Server Administration Console.
Increase the default tablespace configuration in production environments to prevent error conditions that can occur when processing a large number of messages.
You can specify the envelope elements, separated by commas, to be ignored during look-up validation for agreements. The possible values for ignore validation on envelope elements varies based on the identifiers used in the agreement. For example, for HL7 agreements, you can specify MessageSendingApp, MessageReceivingApp, MessageSendingFacility, and MessageReceivingFacility, among others.
For EDI agreements, the possible values are InterchangeSenderID, InterchangeReceiverID, GroupReceiverID, GroupSenderID, TransactionAssociationAssignedCode, InterchangeReceiverQual, InterchangeSenderQual, and InterchangeControlVersion, among others.
Changes to the Ignore Validation on Envelope Elements setting require you to restart the Oracle B2B server for the setting to take effect.
In the Oracle B2B interface, the Enable Auto Search parameter (on the Administration > Configuration page) does not function in this release.
When the log level is set to trace for oracle.soa.b2b.repository, the payload received by B2B is logged in plain text into the server's diagnostic.log file.
This section describes documentation errata. It includes the following topics:
Section 15.3.2, "Default Value for the b2b.r1ps1 Property Is True"
Section 15.3.3, "B2B Configuration Wizard Tooltip in JDeveloper Incorrectly Refers to OC4J"
See Oracle Fusion Middleware User's Guide for Oracle B2B for more complete information than what is available from the Help link in Oracle B2B. In particular, the guide includes descriptions of the Active Document Types fields and Active Trading Partners fields (Table 17-1) and the Summary fields (Table 17-2) that are not found in the online help.
In Figure 30-3, "Configuring B2B Attributes," in Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite, the value displayed for the b2b.r1ps1 property in the Element_1 node is incorrect. The default value for this property is true, not false.
The descriptive text (tooltip) that pops up when you move the cursor over the Test B2B button on the Application Server Connection page of the B2B Configuration Wizard in Oracle JDeveloper incorrectly refers to the SOA OC4J HTTP port. Clicking this button tests the B2B server connection.