The mailbox's AS4 tab allows you to to configure a Usage Profile,
along with all the associated AS4 Processing Mode (P-Mode) settings.
- Usage Profile
- To assist with the job of configuring all the required P-Mode settings, you can select
a profile that provides the default values for many of the P-Mode fields. Profiles that
are available:
- AS4 profile
- eDelivery profile
- PEPPOL profile
-
- Profile
- Displays the name of the current profile.
- The initial setting for this field is None. Althought
it's not required to select a profile, it is recommended.
- Set Profile Defaults...
- Click this button to display a list of profiles from which you can load
processing mode settings.
-
Note: The settings configured here will override any existing settings already in
place.
- Processing Mode (P-Mode) parameters
- P-Mode parameters define how User Messages and Signal Messages should be processed.
These parameters define either elements that are expected to be found in the messages or
expected processing behavior.
- This section contains a series of tabs on which you can enter values for various
settings related to AS4 Processing Modes. Each tab contains a set of related fields, as
defined by the AS4 specifications.
-
- General tab
-
- PMode.ID
- An optional identifier for this P-Mode agreement, used primarily for the
convenience of P-Mode management.
- PMode.Agreement
- A reference to the agreement governing all message exchange.
- PMode.Agreement.Type
- Additional information indicating how the parties will interpret the
Agreement value.
- PMode.Initiator.Party
- Identifies the VersaLex party ID for this relationship.
- Outbound User Messages use this value as the
<eb:PartyInfo/eb:From/eb:PartyId> element value.
- For inbound User Messages, the receiving message handler (MSH) takes the
values of the <eb:PartyInfo/eb:To/eb:Party> and the
<eb:PartyInfo/eb:From/eb:Party> elements and searches
every AS4 mailbox for matches to
PMode.Initiator.Party and
PMode.Responder.Party settings, respectively. It
does this in order to associate the inbound message with the proper
recipient. If a match is not made, the request is not accepted. If more than
one mailbox matches, the request is also not accepted. For this reason, the
to/from settings must be unique within every AS4 mailbox of the VersaLex
instance.
- PMode.Initiator.Party.Type
- The domain of names to which the string in the content of the
<eb:PartyId> element belongs. The value of the type
attribute must be mutually agreed to and understood by each of the
parties.
- PMode.Initiator.Role
- Identifies the VersaLex role for this relationship. An outbound User
Message will use this value as the
<eb:PartyInfo/eb:From/eb:Role> element value.
- PMode.Responder.Party
- The trading partner party ID for this relationship.
- Outbound User Messages use this value as the
<eb:PartyInfo/eb:To/eb:PartyId> element value.
- For inbound User Messages, the receiving message handler (MSH) takes the
values of the <eb:PartyInfo/eb:To/eb:Party> and the
<eb:PartyInfo/eb:From/eb:Party> elements and searches
every AS4 mailbox for matches to
PMode.Initiator.Party and
PMode.Responder.Party settings, respectively. It
does this in order to associate the inbound message with the proper
recipient. If a match is not made, the request is not accepted. If more than
one mailbox matches, the request is also not accepted. For this reason, the
to/from settings must be unique within every AS4 mailbox of the VersaLex
instance.
- PMode.Responder.Party.Type
- The domain of names to which the string in the content of the
<eb:PartyId> element belongs. The value of the type
attribute must be mutually agreed and understood by each of the
parties.
- PMode.Responder.Role
- The trading partner role for this relationship. Outbound User Messages use
this value as the <eb:PartyInfo/eb:To/eb:Role> element
value.
- PMode.MEP
- Read-only.
- The type of ebMS message exchange pattern (MEP) associated with this
P-Mode.
- PMode.MEPbinding
- Read-only.
- The transport channel binding assigned to the MEP (for example, push,
pull).
- Protocol tab
-
- PMode.Protocol.Address
- Read-only.
- The server address and port of the receiving message handler (MSH). You
can only change it through the host General configuration.
- PMode.Protocol.SOAPVersione
- Read-only.
- The SOAP version to be used. SOAP 1.2 is supported.
- Business Info tab
-
- PMode.BusinessInfo.Service
- The name of the service to which the User Message is intended to be
delivered.
- PMode.BusinessInfo.Service.Type
- Additional information indicating how the parties will interpret the
Service value.
- PMode.BusinessInfo.Action
- The name of the action the User Message is intended to invoke.
- PMode.BusinessInfo.Properties[]
- A table that contains a list of key-value pairs added to the User Message
within the <eb:MessageProperties> element.
Note: For the
eDelivery and PEPPOL profiles, these two properties are required:
- originalSender
- finalRecipient
- Error Handling tab
-
- PMode.ErrorHandling.Report.AsResponse
- Indicates whether an error generated on reception of a message must be
returned as a synchronous response over the same SOAP message exchanged
pattern (MEP).
Note: Only synchronous Error Signals are currently supported.
If this setting is turned off, it will be ignored.
- PMode.ErrorHandling.Report.ProcessErrorNotifyConsumer
- Read-only.
- Indicates whether the Consumer of User Message should be notified when an
error occurs in the receiving message handler (MSH), during processing of
the received User Message. By default and relative to how VersaLex operates, this setting is always true as processing
errors are always logged.
- PMode.ErrorHandling.Report.ProcessErrorNotifyProducer
- Read-only.
- Indicates whether the Producer of a User Message should be notified when
an error occurs in the sending message handler (MSH), during processing of
the User Message to be sent. By default and relative to how VersaLex operates, this setting is always true as processing
errors are always logged.
- PMode.ErrorHandling.Report.DeliveryFailuresNotifyProducer
- Read-only.
- Indicates whether the Producer of a User Message must be notified when the
delivery to Consumer fails. By default and relative to how VersaLex operates, this setting is always true as transmission
errors are always logged.
- PMode.ErrorHandling.Report.MissingReceiptNotifyProducer
- Read-only.
- Indicates whether the Producer of a User Message must be notified when the
required receipt is not received. By default and relative to how VersaLex operates, this setting is always true as transmission
errors are always logged.
- Security tab
-
- PMode.Security.WSSVersion
- Read-only.
- The version of WS-Security you want to use. WSS 1.1.1 is supported.
- PMode.Security.X509.Sign
- Indicates whether User Messages and Pull Requests should be signed by a
sending message handler (MSH). Also indicates whether Receipt Signals should
be signed by a receiving MSH..
- Select this check box to enable the other fields in this section of the
tab.
Note: All of the security signing properties apply to both the sending
MSH (for example, sending a User Message) and the receiving MSH (for
example, returning a Receipt Signal) where applicable.
- PMode.Security.X509.Sign.Element.Body
- Indicates whether the <eb:Body> element should
be included in the signature.
- PMode.Security.X509.Sign.Element.Messaging
- Indicates whether the <eb:Messaging> element should be included
in the signature.
- PMode.Security.X509.Sign.Attachment
- Indicates whether attachments should be included in the
signature.
- PMode.Security.X509.Signature.Certificate
- Read-only on this screen. It can be changed only through the host
Certificates configuration.
- The filename of the trading partner's certificate (stored in the
certs/ folder). The public key of this
certificate is used for validation of incoming signatures. This value
is only used if the incoming <wsse:Security>
element does not contain a
<wsse:BinarySecurityToken>.
- PMode.Security.X509.Signature.HashFunction
- The hash function to be used for signing.
- PMode.Security.X509.Signature.Algorithm
- The algorithm to be used for signing.
- PMode.Security.X509.Encryption.Encrypt
- Indicates whether User Messages should be encyrpted.
- Per the eDelivery and PEPPOL specifications and, by reference, per the AS4
Profile specification, encryption takes place only on payloads (either body
payload or attachment payload). No component of the
<eb:Messaging> element is encrypted. If security is
required for this element, transport level security should be used.
- Select this check box to enable other fields in this section of the tab.
- PMode.Security.X509.Encryption.Certificate
- Read-only on this screen. It can be changed only through the host
Certificates configuration.
- The filename of the trading partner's certificate (stored in the
certs/ folder). This certificate's public key
is used to encrypt outgoing messages.
- PMode.Security.X509.Encryption.Algorithm
- The algorithm to be used for data encryption.
- PMode.Security.X509.Encryption.KeyTransportAlgorithm
- The algorithm to be used for key encryption.
- PMode.Security.X509.Encryption.KeyTransportAlgorithm.Parameter
- Represents both the mask generation and digest generation functions.
This setting only applies when the RSA-OAEP key
transport algorithm has been selected.
- PMode.Security.SendReceipt
- Indicates whether a Receipt signal should be used to acknowledge
successful receipt of a User Message.
Note: Regarding signing of receipts,
the Cleo Harmony AS4 server will always sign receipts if
PMode.Security.X509.Sign is set to
true.
- Select this check box to enable the other fields in this section of the tab.
- PMode.Security.SendReceipt.ReplyPattern
- The mode in which a Receipt Signal should be sent.
- Callback indicates the receipt should be sent
asynchronously.
- Response indicates the receipt should be sent
synchronously.
Note: Only synchronous Receipt Signals are currently supported.
If this setting is configured to Callback, it
is ignored.
- PMode.Security.SendReceipt.NonRepudiation
- Indicates whether a Receipt Signal should contain an
<ebbp:NonRepudiationInformation> (NRI) element.
The NRI element can only be included if the original User Message is
signed, as it contains references to the User Message digests. If the
original User Message is unsigned, then the complete
<eb:UserMessage> element from the inbound
request is included instead, regardless of this setting.
- Payload Sercice tab
-
- PMode.PayloadService.CompressionType
- Indicates whether User Messages should be compressed
(application/gzip) or uncompressed
(<None>).
- Reception Awareness tab
-
- PMode.ReceptionAwareness
- Indicates whether the sending message handler (MSH) expecting a receipt
(related to a sent message) should generate an error if no receipt is
received.
- Select this check box to enable the rest of the fields on the tab.
- PMode.ReceptionAwareness.Retry
- Read-only. It can be changed only through the host Advanced
properties (Command Retries > 0).
- Indicates whether the sending message handler (MSH) should retry to
send a User Message if a receipt is not received.
- PMode.ReceptionAwareness.Retry.MaxRetries
- Read-only. It can be changed only through the host Advanced
properties (Command Retries).
- Indicates how many times the sending message handler (MSH) should
retry to send a User Message if a receipt is not received.
- PMode.ReceptionAwareness.Retry.Period
- Read-only. It can be changed only through the host Advanced
properties (Retry Delay).
- Indicates the amount of time (in seconds) the sending message
handler (MSH) should wait between retry attempts.
- PMode.ReceptionAwareness.DuplicateDetection
- Indicates whether the receiving message handler (MSH) should track
received message IDs
(<eb:MessageInfo>/<eb:MessageId>) in order to
prevent duplicates from being available to the Consumer.
- This means, in addition to detecting duplicates, the
receiving MSH eliminates duplicates by blocking them from being
received. An appropriate Error Signal is provided to the sending MSH
when this occurs.
- PMode.ReceptionAwareness.DuplicateDetection.MaxWindow
- Indicates the number of days the receiving message handler
(MSH) should store message IDs for the purpose of duplicate
detection.