EdiSecurityModule: Signing of EDIFACT/EANCOM Messages; An Example Configuration
This blog post describes two example configurations with the EdiSecurityModule of two receiver channels in an outbound and an inbound scenario.
EdiSecurityModule
In many European EDI processes it is mandatory to sign invoices with your company’s signature. With the EdiSecurityModule it is possible to sign EDIFACT and EANCOM messages with your signature depending on your configuration and your certificates.
Your outbound EDI message to your EDI partner gets enhanced with EDIFACT 4.0 conform AUTACK segments.
For inbound EDI message from your EDI partner the EdiSecurityModule de-signs and/or verifies the message and then forwards it to the next module, e.g. EdifactConverterModule.
Note: Within the help.sap.com portal there is a configuration documentation which has a small divergence in spelling of the EdiSecurityModule. You will find the documentation here: Configuring the EDI Security Module (AUTACK) – SAP Process Integration, business-to-business add-on Configuration – SAP …
Example Configuration of a Receiver Channel in an Outbound to Partner Scenario
Adapter module used: localejbs/EdiSecurityModule local
|
Module Key |
Parameter |
Value |
|---|---|---|
|
EdiSecurity |
includeOwnCertificate |
YES |
|
EdiSecurity |
ownCertificateAlias |
MyOwnCompany_CERT |
|
EdiSecurity |
ownCertificateView |
_as2_MyOwnCompany |
|
EdiSecurity |
ownPrivateKeyAlias |
MyOwnCompany_KEY |
|
EdiSecurity |
ownPrivateKeyView |
_as2_MyOwnCompany |
|
EdiSecurity |
secureMsgDirection |
Outbound |
|
EdiSecurity |
securityScope |
UNH |
Results:
With the configuration above you will have the following results. The hash value and a short description of your certificate is added to your message on UNH level.
On sum level the EdiSecurityModule adds the equivalent parameters to your message. E.g. USH values (USH+1+781761049280+…), USC values.
With the configuration above it we will to add additionally the certificate with which we signed our EDI message after the UNO segment. The EDI message always finishes with the UNZ segment. Please note that all other segments remain untreated (see UNT segment before and after the EdiSecurityModule).
Example Configuration of a Receiver Channel in an Inbound from Partner Scenario
Adapter module used: localejbs/EdiSecurityModule local
|
ModuleKey |
Parameter |
Value |
|---|---|---|
|
EdiSecurityModule |
generateAutAck |
YES |
|
EdiSecurityModule |
ownCertificateAlias |
MyOwnCompany_CERT |
|
EdiSecurityModule |
ownCertificateView |
_as2_MyOwnCompany |
|
EdiSecurityModule |
ownPrivateKeyAlias |
MyOwnCompany_KEY |
|
EdiSecurityModule |
ownPrivateKeyView |
_as2_MyOwnCompany |
|
EdiSecurityModule |
secureMsgDirection |
Inbound |
|
EdiSecurityModule |
securityScope |
UNH |
|
EdiSecurityModule |
usePartnerCertFromNWA |
false |
|
EdiSecurityModule |
verifyMsgSignature |
FALSE |
Please note: That the verifyMsgSignature parameter is set always to true by the EdiSecurityModule.This is why I used the parameter generateAutAck and the all of my certificate settings to avoid an error in the message verification. My guess is that SAP will change that in future.
Results:
The security segments were removed by the EdiSecurityModule. The EDIFACT or EANCOM message is now fully convertible by the standard b2b adapter modules.
Verification of EDI Message
In cases of an error within your verification process you will receive the following error message within monitoring and alerting.
| Error Message |
|---|
| MP: exception caught with message Signature verification failed for incoming message with Message type: INVOIC Message Version: 96A Sender Identification: TSTCLNT123:14 Receiver Identification: 0000010001:14 Interchange Control Number: 1234567 |
Summary
With the EdiSecurityModule the b2b addon gets a new module to meet required specifications in sign; “de”-sign and verify EDI messages.
Hi Konrad,
I like this feature, and it seems to work just fine as described in your blog.
However, I have been reading up on note:
2074602 - Secure authentication and acknowledgement message usecases for B2B AddOn SP4
and here it is stated, that the certificate/key details can also be derived from TPM - I assume this is a reference to the AUTACK setting, that can be maintained under a given TPM partner's 'EDI Acknowledgement' AUTACK settings + perhaps also in combination with the checkbox in the agreement for outbound messages.
Regardless, I can't get the adapter module to read the EdiSecurityModule parameters from TPM - it keeps throwing an error saying that the parameters need to be maintained.
Since we will be doing this setup for multiple partners, while using generic receiver channel for our VANS + have a goal to keep certificate/key usage transparent, then it would be a nice feature to be able to control this generically from TPM.
So if you have tried using TPM settings instead of adding the certificate/key details directly in the communication channel, then additional details about how to make that work, would be a great followup to your blog.
Thanks for a great blog.
Best regards, Emil
P.S.
As you can see in the log below, our message processing have found the TPM agreement + partner, since other parameters are being read.
Also, we are on SP4 Patch73, so that should be ok.
1/19/2017 03:24:09.847 PM Information TPM AckHandler Module: Selected TPM Agreement is: EDIFACT:DESADV:99B:.*:D:UN
1/19/2017 03:24:09.848 PM Information B2B GenericConverterModule is being executed
1/19/2017 03:24:09.852 PM Information B2B EdifactConverterModule : EDI format detected as EDIFACT
1/19/2017 03:24:09.852 PM Information B2B EdifactConverterModule: Property: edifact.indent value is set as: true. Read from TPM.
1/19/2017 03:24:09.852 PM Information B2B EdifactConverterModule: Property: edifact.monitor.ackstatus value is set as: true. Read from TPM.
1/19/2017 03:24:09.852 PM Information B2B EdifactConverterModule: The module-paramteter "eancom.subversion.prefix" is not set. Using default value "false"
1/19/2017 03:24:09.927 PM Information B2B EdifactConverterModule: Message will be sent as ISO-8859-1.
1/19/2017 03:24:09.927 PM Information B2B EdifactConverterModule: Property: ControlKey value is set as: 2. Read from TPM.
1/19/2017 03:24:09.979 PM Information B2B EdifactConverterModule: Property: b2b.edi.acksla.outbound value is set as: 2. Read from TPM.
1/19/2017 03:24:10.097 PM Information EdiSecurityModule is being executed
1/19/2017 03:24:10.097 PM Information EdiSecurityModule: Property: secureMsgDirection value is set as: Outbound. Read from Channel.
1/19/2017 03:24:10.097 PM Information MP: processing local module localejbs/EdiSecurityModule
1/19/2017 03:24:10.102 PM Error MP: exception caught with cause javax.ejb.TransactionRolledbackLocalException: The module-parameter ownCertificateView has to be set
Hi Konrad,
Thanks for the Post. I have something that i really need help with.
As per the description above I have configured the scenario (SAP INVOIC >> PI >> Partner) + Request AUTACK.
This part works perfectly however we get back the AUTACK from the Partner but EDI separater is unable to process the AUTACK we get. The message type not found.
I search the B2B EDIFACT content tables and was not able to find the message type AUTACK.
I also noticed also that in the monitoring for the outgoing invoice that the column "Application Ack" = Autack requested = yellow.
My assumption is that the returned AUTACK is not being mapped/linked with the invoice requested.
Is there additional AdapterModule parameters i need to set for the inbound autack to be processed?
Any tip would be appreciated.
Kind Rregards
Juan
Hi Juan,
the question here is: Do you receive a real AUTACK edi message? AFAIK this is still not part in the b2b addon tables. OR: Do you have AUTACK segments within the INVOIC? Then kindly use the EdiSecurityModule before converting.
Kind regards
Konrad
Hi Konrad,
Yes we receive an AUTACK message back. Not sure why the partner would send the Invoice back.
Here is a sample
UNA:+.? 'UNB+UNOC:2+XXXXXXX002901:14+XXXXXXX000001:14+170324:1747+EW550337610'UNH+ACK_97049+AUTACK:1:1:UN:EAN001'USH+5+EWS933986+2+1+6+2+1+1::TEST_MAILBOX_XXX::9+2::CZ41505191::9++5:20170324:174705'USA+1:::16:1'USC+1991B9E117095823'USA+6:16:1:10:1+14:2048+12:Ù@ôTïêsëpÃlÐvXYgjQEÝpÓCPZÿÒëUzÐÙkUVM_låuñYpÝØcA]TÅdiÚÜUIuUÒGaågúÕÅLkoÁ^anYüâÃwéösÀKÏ[ÜiÎÒÒIubVvÐòchñÃçÜìÃîøâhzIüeåïÊÏRôËÔafk{hrhdòkÆ^Eæ{CËmÇæZösEMoúFÃÔgÂ`ëqlj@IdàÍFXãZghèÛMÔ\÷]JYÍõÎâÓJbhCçÃøÿeàæïäÉõ|wÕOÜSëfòÓâåNdãUcT[atøÕó|~×úàiwùÉÑî^íLçÝþùüZÀÝæQßÿáíò`vLEu|êvzúhWðÌÃÀlSÖwVXOXoOËäÓzdùóÇZ_RÔYzá[q+13:ðA@A'USB+1+5:20170324:174705+TEST_MAILBOX_XXX:14+CZ41505191:14'USX+5177864++++++1'USY+EWS97049'USX+5177864++++++1'USY+EWS97049'UST+EWS933986+6'USR+1:Õ]Oû|Q[^Ë×CFðw|Hù[~LçcýãzÓVDßOÕYðõBêiT×ÌðÆMÊEgF[bêDívÀN^øFýYZ[ÉrÈ\ÌmÌWîÅbÑIfÔstÔhaïÚõdYJfHcMJÔÑCNóIÐaXO|òháçäYÃäfedIÚmBè÷_QGéwùúÒ_vUB_ÌQXI[úBümHcHÍJLËjÌÞÃöJFà@öCKVn\ÔäêäìtéÆrÞMàùÙãqUánrÛít×ÖãåÒaßFXsïûÚlózZîáäôñFßPaûïPùáNÇÝÁAx|ÑÚiNnuÜøÒáÞýRÆêLlãÿÜnûnKCPBÓQUPâÄ~ñþòîôÓtÿlúOiUÕãxfÐÒñ]pÒqúIheÈrñ'UNT+7+ACK_97049'UNO+EWS60641+1:1991B9E117095823+46:EDC+62:PKCS7+2602'÷pÂHàFIj×ÆHÆ÷MAGûBàÂHÑpÂßHÍBAAq@þpKFIjÆHßÆ÷MAGAàÿÂHõpÂHñÿpÂFÙàCBÿABBHYÑùwáWIXcpMúFIjÆHÆ÷ÿMAAEE@pßÁØqNpLFßCUDQLEtÿvyxpqgpýeFIjÆHÆ÷MAIAVX@acedico@m@edicoAmgroupnOcomqTpRïFCUDCLK@ACEDICOM`pqqRp÷PFCUDESßIByvtypÿxvwqLpJïFCUDKLCOPKIqOpMïFCUDJLFAEDICOMqýtprFCUDðGLkRondda`de`AuBguste`yÁ`Louis`@Lumiereø`qr`PatGernaqQp÷OFCUDHLÀHValenc_iaqKpIFÞCUDFSBESp^WMquÿptqvqqq÷rtsZWMqÿxptrxpyûttuxZpÁøqepcFIëjÆHÆ÷MAøIAVVedi@com@edi@comgroucpncomqTûpRFCUDnÿSKrtsttósupT_wqýp}FCUDðCLvInte@rcambioÀ`ElectrBonico`d`e`DatosÐ`y`Comu@nicacioJnes`SnLÿnqRpPFCUDESIrtþsttsupTþqRpPFCUøDjLIJosae`BlasqýWpUFCUDðDLNVilaPta`TamaOritqOpMïFCUDJLFAEDICOMqýKpIFCUDóFSBESqYÿpWFJkFAÿDAÁÓVAAïLIByvtyÿpxvwpÂAÿbpMFIjÆoHÆ÷MAAAÿE@CÂAO@ÿpÂAJBÂAìA@ôTïêsØëÃlÐvXYUgQEÝpÓCMPÿÒëUzÐUÙUVM_låøuYpÝØcAÊ]ÅdiÚÜUZIUÒGaågêúÅLkoÁ^×aYüâÃwéYöÀKÏ[ÜiéÎÒIubVvyÐchñÃçÜaìîøâhzIÒüåïÊÏRôêËafk{hrRhòkÆ^EæA{ËmÇæZöÂsMoúFÃÔág`ëqlj@RIàÍFXãZTgèÛMÔ\÷E]YÍõÎâÓQJhCçÃøÿpeæïäÉõ|jwOÜSëfòñÓåNdãUcMTatøÕó|ë~úàiwùÉ÷Ñ^íLçÝþ~ùZÀÝæQßpÿíò`vLEÞuêvzúhWfðÃÀlSÖwLVOXoOËä]ÓdùóÇZ_kRYzá[qBÿCA@AãÂC{[pÂCWpÁÿÎFHkFAEÿEGAADÁÁ×pp@FHkÿFAEEGpBáÆthttpzàooacediHcomnedi@comgroubpncomocDertsoacAedicompãqncerp{ÿFHkFAEEüGpAÆoht\tpzooocPspnacedDicomned@icomgroQupncomo@acedicompqp]FCU]NDVDTPóææDÏfæ×æDöùâùÅÕwPøyV{p÷LFCU]SAßAÿDBp@p÷_FCU]cDýXpVÀTMÙñiBÃY@ÈöqÂÆòBýhÅâqäup{FÿHkFAEEGÿACDopmpÿJFHkFAEÿEGKBpHFûFD@ÎFAAÿpKFFD@ÎFACBAKpþHFFD@ÎFýADpÂAFßCU]`DÂA{vpÂArpHÿFFD@ËpAûApÂAdFMþkFADAÁêcBABCBpïÂAQpÂA`ÿFHkFAEEÿGBBpÂARý^ÂAN@C@je@r@t@iÕ@f@i@c@ka@t@e@`Õ@P@o@l@ki@c@y@`Õ@f@o@r@ê`@Q@u@aÕ@l@i@f@ki@e@d@`Õ@C@e@r@jt@i@f@iÕ@c@a@t@ne@s@`@f×@o@r@`@jd@i@g@iÕ@t@a@l@ê`@s@i@gÕ@n@a@t@ku@r@e@`×@i@n@`@jS@S@C@Dõ@`@a@p@jp@l@i@aÕ@n@c@e@ê`@d@e@vÕ@i@c@e@ê`@l@o@cÕ@a@t@e@zd@`@a@tõ@`@h@t@ot@p@z@oõ@o@a@c@je@d@i@c×@o@m@n@je@d@i@cÕ@o@m@g@jr@o@u@põ@n@c@o@mpkFHkFÿAEEGBAVÃ_httpzoÀoacedicPomnedic@omgroupÇncompFßCU]_DxpÿvptàràpáÆnhttpzàooacediHcomnedi@comgroubpncomoa@cedicomñpqncrlp÷NFCU]OAßAÿDDCBGýÀpaFCU]ÿQDZpXÁV@edicom@@edicomgDroupncoompBFJkFùADAÁêcCÿBDtprLp@SignatuRre`of`c@ommerciQal`and`@tributaPry`docuCmentsnpýMFIjÆHÆ÷MAAEE@ÿCÂBA@\nvÿ[VH`P×÷NnSQéjQÕZNIþ^zÚ{ÕËåÌnòöÜwwSzREoÁjlSMPÂëuMäOI{^[IÿRÓÝÎònÝBHAæxÖyR}QaÕa×àweCÔhhDUÎAïOÇFeùeèçØu×QìnVECHgÛqÚGíáÏØ[lYUÄÈPp~ÒlnäÅÒEAÇQ×î|ÖüådtÅCÅcijËhkMcëVèÜüÀhÏÁUpLùMJÎT^VÇ@CÂÍOëuÓWÑìËâZÛîÈLllÿX}jböpLXÞÛPmùéÀiúÏöMÖþ~äNKlõi÷ÈqYhWóæújíÏzU\ÚèàìqÄxNSm}gÄ[SôáéíðWXÎaFFÏùNDpÐ]\RiBi]XéÁVÖ~aLHEkR}Ãy}ûËÆî~÷lìzçTöÝØáÃwUÐáZïuZîRkOHNNZFÜTñ_ýÂObÂCegYcçyÌÙífðCýÄQÉqaÐJñÈCüc~kD`ZÆjåÞñmWÁqáNô[Öðy^HlÔØkuofióu}ÇÛøóÄhPUCÏgRRÐoÊçör}Wë}×ç{ïLÌËaàõóâjã^nÌOzQûæTlBÀôÉUküAêíéYUøèØþÅBÇþIÎSÌxÊàMrÅÈÇFlMÛyz_Ga}áôBÁâÞcxßõð]}NpÓ|öZ[VÞØQ|ìfÊþÀîáKTrÇNkûyÛÞoênÝ{idÄ|ÅÕîÉKåÒÑÅãïÈÃLÔDÆaFàÌ\úùOÃýWùn_ôâÕùzÆqÀ@UNP+2602+EWS60641'UNZ+1+EW550337610'
The invoice we send contains the security segment + the flag to indicate i expect an AUTACK confirmation back.
issue i have how do I receive the AUTACK and inform the sent INVOICE that it was accepted by the partner.
If it is not supported then why
Thanks for your feedback
Hello Mr. Thalheim,
thank you very much for this helpful post. Is it possible to download the signed sample file somewhere or can you send it by email?
Kind regards