webMethods

Hello SAG community,
we know how to access the HTTP context and control the HTTP request/response in a Java service:

import com.wm.app.b2b.server.Service;
...
Service.getHttpResponseHeader().setField("Content-Length", String.valueOf(result.getBytes().length));
Service.setResponse(result.getBytes());

How can we do the same in an AppPlatform service?

Best regards,
Marcus

Do you mean Integration Server? check documentation on service:
pub.client:http

Hello Tong,
no, not using Flow services on Integration server, but Java’s own capabilities - just like the example shows for Java services.

Best regards,
Marcus

if you talking about writing client in java directly, then java doc should be the place to check.
are you using: java.net.HttpURLConnection ?
you can use setRequestProperty to set header fields.

Hi Tong,
maybe my question was not unambiguous, so let me rephrase it to avoid misunderstandings:
We know how to access the HTTP context of the REST call and control the HTTP request/response in a Java service when such a service is called via REST. How can we do the same in an AppPlatform service?

Hence, I don’t want to fire a separate HTTP request, but want to access the HTTP context of the REST call which invoked the PLS service.

Best regards,
Marcus

Hi Marcus,
The answer depends on how you are invoking the App Platform OSGi service. Is this service annotated such that an IS flow service has been created and deployed to an IS package? In that case, you’d do the approach you are familiar with because in that case, the inbound REST call is coming to the Integration Server ( e.g. port 5555 ). If you are coming in from an OSGi web bundle WAB or a traditional Tomcat WAR project (e.g. port 8072) , you’d access the response via the Servlet API.)

Hi Warren,
it’s an annotated IS service in an IS package:

@Service
@ExposeToIS(packageName="PackageName")
public class ClassName {
@ExposedMethod
public String MethodName() {
// code
}
}

However, my very first idea was to do it the same way like in a conventional Java service, but when I want to import the com.wm.app.b2b.server.Service class, I get the error “com.wm.app.b2b.server.Service cannot be resolved to a type”.

Best regards,
Marcus

PS: The approach for servlets is easy and straightforward. I implemented that several times meanwhile it is working perfectly.

Hi Warren,
do I have to add all additional libraries of an regular IS package manually to the Java Build Path of the PLS project in order to get it working?

image1146×777 75.9 KB

Best regards,
Marcus

Hi Marcus, you can’t reference ‘com.wm.app.b2b.server.Service’ from an OSGi App Platform (PLS service). The IS Service class is part of the Integration Server’s ServerClassLoader, and App Platform PLS services run as an OSGi bundle in the OSGi container. ( the server compoents for the App Platform product manage the interaction between your application services and the IS services.

It may be a bit confusing because App Platform also supports running Tomcat WAR projects. Those WAR projects run in a Tomcat servlet container also hosted by the OSGi equinox container, so it is not a plain old Tomcat installation.

So when you import library dependencies for your application, do not attempt to import Integration Server jars ( e.g. wm-isserver.jar ). This won’t work. So you can’t use the Service API to get to HTTP-related details in a PLS service project. -hth

About your second question. You don’t want to add those libraries to your application service project. When you create your service project, you can click the ‘Add Library’ button on the right side of the ‘Java Build Path’ configuration( same panel in your screenshot above). Select add ‘Server runtime’ and select ‘Application Platform Integration Server (Remote)’ configuration. Doing this will add an Eclipse classpath container to your project containing the libraries included in an App Platform server installation. That includes everything you will need to annotate your OSGi services or create POJO service wrappers via the App Platform service wizard and publish your project to the server.

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/d67d78a73d07b256c04cad441fa1f07a2be20275_2_492x750.png 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/d67d78a73d07b256c04cad441fa1f07a2be20275.png 2x" data-dominant-color="DDDBDC">

ss577×878 175 KB

When you have done this, if you open that classpath container, you can see it includes the bundles that are resident in the AP server container, so there is no need to bundle this jars in your project as they are already installed in the server. (Note, the screenshot does not show the complete set of jars included in the ‘server runtime’ classpath container.)

Hi Warren,
thank you for your answers!

I thought so. Thanks for clarifying!

Which API or library can I use then to access the HTTP context directly in the PLS service? I understood from your first answer (see below) that there is a way.

Could you elaborate this way to access the HTTP context directly in a PLS service, please?

Best regards,
Marcus

@Warren_Cooper
Thank you for providing the APIExample archive with the demo projects! I’ve got some questions:

1. Do such AP services always have to be registered manually with Jersey in order to be able to call it as REST service and access its Request and Response objects?

2. If so, is there something else to be taken into account besides the registration in the main class and the Activator bean?

3. Your example method unchunkySleep() shows how to access and write to the Response bean:

	@Path("/sleepUnchunky")
@GET
public Response unchunkySleep() {
ResponseBuilder responseBuilder = Response.status(Status.OK);
responseBuilder.entity(sleep());
responseBuilder.type("text/plain");        
responseBuilder.header("Content-Length", "2");
return responseBuilder.build();

}

Would we be able to access the Request bean as well if we added it to the method parameters?

public Response unchunkySleep(Request Req) { ... }

Because this is what we were looking for in the first place.

Best regards,
Marcus