cancel
Showing results for 
Search instead for 
Did you mean: 

AS2 sender adapter 403 forbidden error

marcos_zepeda
Explorer

I have a scenario which is connecting with third party using sender AS2 adapter but every time the third party sends a message to PI they are getting 403 forbidden. I’m using PI 7.3 version and SeeBurger AS2 adapter and I’m currently testing using my QA environment.  I have check
the configurations multiple times and everything look to be correct. See the configuration of each object below

Party

I have make sure me and our partner have entered exactly the same AS2ID in the configuration.

Sender: IAN_COATINGEXCELLENCE

Receiver: DOMINO_INFOACCESS

Sender

Receiver

Communication Channels

I created a Virtual receiver in the sender agreement and provide the receiver party and service name as well. We also Make
sure that we created only one sender agreement for the sender and receiver party.

Sender

Receiver

Sender Agreement

The certificates are installed properly and there is only
one sender Agreement

Receiver Agreement

Receiver Determination

Interface Determination

With all the configurations checked multiple times the sender still get the 403 forbidden error and when I check my logs “SAP Netweaver Administrator/troubleshooting/logs & traces/log viewer” I see the following error. I have check this tread http://scn.sap.com/thread/3526236
and make sure I have all the settings correct but no matter what I do I still get the error message. Any help will really be appreciated.

Inbound communication from
IAN_COATINGEXCELLENCE to DOMINO_INFOACCESS not allowed: com.seeburger.as2.exception.AS2PluginException:
Failed to get inbound configuration from DATABASE. [LOC:
com.seeburger.as2.component.AS2Server.checkInboundRelation]

Error while checking inbound
communication [LOC: Error while checking inbound communication.checkInboundRelation]
Caused by: com.seeburger.as2.exception.AS2PluginException: Failed to get
inbound configuration from DATABASE.

at
com.seeburger.as2.conf.ConfigurationInbound.getInstanceInboundMessage(ConfigurationInbound.java:100)

at com.seeburger.as2.component.AS2Server.checkInboundRelation(AS2Server.java:1036)

at
com.seeburger.as2.component.AS2Server.handleServerInbound(AS2Server.java:380)


at
com.seeburger.as2.component.AS2Server.handleServerInboundLS(AS2Server.java:160)

Accepted Solutions (0)

Answers (2)

Answers (2)

engswee
Active Contributor
0 Kudos

Dear Marcos,

I noticed there are some differences between your configuration with the details in the log viewer.

In your sender agreement configuration, the associated sender and receiver AS2IDs are

Sender: IAN_COATINGEXCELLENCE

Receiver: DOMINO_INFOACCESS

However, in your log viewer screenshot, it shows that the message contains the following AS2IDs:

Sender: AMERI799_TMDF_3

Receiver: DOMINO_AMERI799

Can you check with your external party if they are sending the message with the correct/expected AS2IDs?

I would also suggest that you use the following tool for testing AS2.

mendelson AS2 solution

I normally will use this tool to check that all my configurations are in place, before even getting the external party to send a message. With this tool, you can send a message to your AS2 listener URL and check that your sender agreement and AS2IDs are correctly configured. The only limitation to this type of self-testing is that you do not have your partner's private key to sign the message in mendelson. Therefore, in your sender agreement, temporarily remove the sender AS2 authentication certificate when you test from Mendelson.

Rgds

Eng Swee

marcos_zepeda
Explorer
0 Kudos

Hello Eng,

I'm sorry I took a screenshot of another transmission I'm getting the same error but the configuration I'm testing are using the AS2IDs

Sender: IAN_COATINGEXCELLENCE

Receiver: DOMINO_INFOACCESS

Thank you for the link for the test tool. I downloaded the tool and send a test file and I'm getting the same 403 error that they are getting

When I look at my logs I'm getting the same 3 error messages when I try to send the test file.

One thing we did a few months ago was to change our firewalls and we are allowing their IP address to go thru but I'm not sure if there is anything specific that we need to allow.

 

I'm also currently testing using our QA environment and I notice something

When I go here "SAP NetWeaver Administrator --> Operation --> Start & Go --> Java Instances --> OS Processes" I don't see the executable “msg_server.exe” running but I'm not sure if this has to do anything with the error.

Any other suggestions will be really be appreciated.

Thank you

Marcos

engswee
Active Contributor
0 Kudos

Hi Marcos

I don't think it's related to the firewall because there are able to reach the AS2 endpoint, plus your testing from Mendelson gives the same error.

From the AS2 manual, below are the main reasons for such an error.

My suggestion would be:

i) Check that there are no cache issues. Try to refresh the cache and check that the sender agreement and sender comm channel is reflected in the cache

ii) Try to create a new scenario with different set of sender and receiver party with different AS2IDs. Test this new scenario using the Mendelson tool. If it works, then we can narrow down the issue to the specific configuration rather than your system as a whole. For the test, best to just skip encryption and signing to simplify the scenario.

iii) Check also the Message Monitor in the Seeburger Workbench. See if there are any errors there that might provide more details.

Rgds

Eng Swee

marcos_zepeda
Explorer
0 Kudos

Hi Eng,

It end up being the cache. I refresh SDL and Newweaver cash and it worked.

Thank you

marcos_zepeda
Explorer
0 Kudos

Hi Eng,

It end up being the cache. I refresh SDL and Newweaver cash and it worked.

Thank you

engswee
Active Contributor
0 Kudos

Thanks for updating the status. Good to hear that it's been resolved.

Harish
Active Contributor
0 Kudos

Hi Macros,

The configuration seems to be good. Can you check the seeburger message monitoring logs? you will get more details about the error with the seeburger message monitoring log.

regards,

Harish