Accessing RestMessageContext from java service

, ,
1

I’d like to access RestMessageContext from a java service. What jars do I need to import? I have API Gateway version 10.3.

Thanks in advance.

Yunus Aswat.

2

You need to import <Install_Location>\IntegrationServer\instances\default\packages\WmAPIGateway\code\jars\apigateway-runtime-base.jar

Additionally you might need to import the below jars for dependencies related to the usage of the MessageContext.

  • axis2-kernel-.jar, axis2-transport-http-.jar and synapse-core-*.jar from <Install_Location>\WS-Stack\lib.

  • <Install_Location>\IntegrationServer\instances\default\packages\WmAPIGateway\code\jars\apigateway-runtime.jar

  • <Install_Location>\IntegrationServer\instances\default\packages\WmAPIGateway\code\jars\static\apigateway-API.jar

1 Like
3

Thank you Vallab. I have imported the mentioned jar files to the project in designer:

apigateway-API.jar
apigateway-runtime-base.jar
apigateway-runtime.jar
axis2-kernel-1.6.2.jar
axis2-transport-all-1.0.0.jar
axis2-transport-local-1.6.2.jar
synapse-commons-2.1.0.jar
synapse-core-2.1.0.jar
synapse-extensions-2.1.0.jar
synapse-nhttp-transport-2.1.0.jar
synapse-securevault-2.1.0.jar
synapse-tasks-2.1.0.jar

I believe apigateway-runtime-base.jar has the class RestMessageContext. However, I get this error:

The source was saved, but was not compiled due to the following errors:

redacted/priv.java:11: error: package com.softwareag.pg.rest does not exist

import com.softwareag.pg.rest.*;

^

1 error

Any suggestions on how to fix this?

4

Hi Yunus,

Adding jars to classpath is for the designer IDE (eclipse-based) to understand the dependencies and provide IDE support for the Java code such as code suggestions, auto-import, showing compile errors, etc, which is helpful for easier development of the java code.

However, for marking the dependency at the Integration Server level, you need to add the wmAPIGateway package in the package dependencies of your IS service package. Othewise you would get the errors you mentioned.

Writing Java service to programmatically access the MessageContext is a old approach. Newer versions (10.3 and later) support a lot of usecases which can be achieved via flow service using pipeline variables without having to write java service. More details here.. Please take a look at this article if you are not already aware of this.

Regards,
Vallab.

1 Like
5

Hello Vallab

I’ve read the article, but it doesn’t give me a how-to on extracting fields from MessageContext. I want the OAuth header.

Regards,

Yunus.

6

Hi Yunus,

You can access the Oauth auth header using the pipeline variable “Authorization” → “authHeader”. You can also access the actual Oauth token using the pipeline variable “Authorization” → “incomingToken”. This can be done using the similar steps given for reading the headers or query params in the link I provided earlier.

Right click the pipeline variable “Authorization” at the “Pipeline In” section and click on “Insert String”. Name it as “authHeader” or “incomingToken” as per your requiremnent. The value of this will be available in the newly added string now. You can use it as per your need.

Note: This is recently added support and will be available in recent fixes (10.3 fix 21 or later, 10.5 fix 10 or later). We will update the article to add the information for the support to access the authorization related values via the authorization pipeline variable.

1 Like
7

Hello Vallab,

After installing the fix I can confirm this technique works. Just for the record I did the following:

  1. Installed fixes to API Gateway as specified above.
  2. In the service Pipeline In, I added a document called authorization with one string variable called incomingToken. The authorization document does not appear in the pipeline as a variable by default.
  3. I mapped this out to my own variable and the token can be used for further processing.

Thank you.

Yunus Aswat.

1 Like
8

Hi Yunus,

Glad to hear it helps.

“The authorization document does not appear in the pipeline as a variable by default.” - Can you confirm if you added the RequestSpec to your IS Service as a specification. Does this authorization document still didn’t get added after that?

Regards,
Vallab

1 Like
9

Hello Vallab,

Yes pub.apigateway.invokeISService.specifications:RequestSpec was always there in the service. I did a refresh in Designer and that resolved the issue. I can see authorization in the pipeline variables. Thanks.

Another question. I want to use the Log Invocation policy to log custom variables to Elasticsearch. Is this possible?

Regards,

Yunus Aswat.

10

Hi Yunus,

Yes the refresh of designer might be needed if there are new changes in the IS Service/Spec. In this case, since the Spec changed in recent fixes, it would work only after refresh. Glad it helped.

Reg the log invocation, if you are talking about custom fields to the transaction events, given below are the steps for that.

Steps to add custom field to transaction events via Invoke IS Service

  1. Create webMethods IS service by specifying the “pub.apigateway.invokeISService.specifications:RequestSpec” (or ResponseSpec) as a specification reference.
  2. In the webMethods IS service, set the required custom fields in the customFieldsMap output variable.
  3. Once when customFieldsMap gets created, the custom fields will be available in the transactional events.
  4. Invoke the API with the Invoke webMethods IS policy.

Regards,
Vallab

11

This topic was automatically closed after 1083 days. New replies are no longer allowed.