What’s the trick to build a JSON string

[Rennur]

Tomcat Log:

REST Servlet (GET) called
Connecting to server localhost at port 9002
Successfully created a connection to the server
Setting session timeout to 30000 seconds.

This process is on repeat until CPU usage reaches 100% and I have to manually kill server processes.

The Service is reachable via the Aware IM Rest URL, but it does not like the GET verb.
The same Tomcat log message appears when using POST & HEAD verbs, also consumes memory and CPU.

The OPTIONS verb returns a successful code 200 response instantly.

Here is the result of this using OPTIONS:

TIMELINE:

* Preparing request to http://192.168.0.17:8081/AwareIM/REST/C ... ST_Service
* Using libcurl/7.51.0-DEV OpenSSL/1.0.2j zlib/1.2.8 libssh2/1.6.1_DEV
* Enable automatic URL encoding
* Enable SSL validation
* Enable cookie sending with jar of 10 cookies
* Connection 8 seems to be dead!
* Closing connection 8
* Trying 192.168.0.17...
* TCP_NODELAY set
* Connected to 192.168.0.17 (192.168.0.17) port 8081 (#9)

> OPTIONS /AwareIM/REST/CR/SI_REST_Service HTTP/1.1
> Host: 192.168.0.17:8081
> User-Agent: insomnia/5.16.6
> Accept: */*

< HTTP/1.1 200
< Allow: GET, HEAD, POST, OPTIONS
< Content-Length: 0
< Date: Thu, 12 Jul 2018 05:16:01 GMT

* Curl_http_done: called premature == 0
* Connection #9 to host 192.168.0.17 left intact

=== end timeline ===

I have set up the process to initiate the service within Aware IM, but it's the same behaviour as above, for GET, POST and HEAD verbs.

[aware_support]

You are doing something wrong in the process that handles the service. OPTIONS verb is not handled by Aware IM.

GET and POST do work. The Tomcat printout indicates that everything is OK. What is not OK is that this print out is repeated. This means that you are doing something wrong.

By the way the business space that exposes the service must not be in the testing mode - it should be published.

[Rennur]

What should the process look like?

FIND Objects specified in Service Reply
FIND BO storing the JSON string
BO.JSON=URL_CONTENTS('REST URL ADDRESS')

[Rennur]

A trick we have used in AwareIM to get data into a JSON string is

1. Publish an AwareIM REST Service that outputs as JSON
2. Call that Service using the AwareIM’s URL_CONTENTS function to call the local REST request

CODE: SELECT ALL
Object.JSON_String = URL_CCONTENTS(‘http://localhost:8080/REST SERVICE ADDRESS’)

I've sent a BSV to support for testing. I'm probably doing something wrong.

[Rennur]

Confusion on my part. URL_CONTENTS sorted.

[RLJB]

Not sure I understand this correctly, but you're suggesting to expose the data as a web service to format it? Is this secure?

Isn't there an easier method?

[Jaymer]

Isn't there an easier method?

Posting a new thread about developing a Java Plugin.
New Thread ---> https://www.awareim.com/forum/viewtopic.php?f=1&t=10490

[Rennur]

Not sure I understand this correctly, but you're suggesting to expose the data as a web service to format it? Is this secure?

UPDATE: Web service does expose data.

Ideally, Aware IM should have the feature such as generating access tokens for authorisation e.t.c

[aware_support]

There is a LOT of parameters you may want to provide to the function that converts a business object to JSON. This is because there are quite a few subtleties in how a JSON string can be generated from an Aware IM record (or records) - how empty values are encoded, how names are mapped etc. All of this has already been done when you expose a REST-ful service and define its response to have JSON format. Therefore, the official suggestion is to use a service and URL_CONTENTS function to do this

[Rennur]

Therefore, the official suggestion is to use a service and URL_CONTENTS function to do this

I have to agree with support that this is currently the best option.
You only need to work on the query to get the specific BO instances in context for the JSON parameter sting (body), store the parameter response using URL_CONTENTS, then continue to POST via REQUEST_SERVICE.

[RLJB]

But it still exposes the data.

We haven't fully started developing V8.1 Restful functionality yet, but using previously created Aware Functions (Java plugins) that we built we do currently construct a lot of JSON text using BO rules, LIST_LINE functions etc. I guess we will continue this method as exposing the data isn't something clients will accept.

One thing that would assist greatly is being able to use the " symbol in rule construction, even perhaps escaping them such as \" as nicely described in the topic below, there are workarounds but they are annoying to work with and debug:

https://www.awareim.com/forum/viewtopic ... 87&p=47517

[Jaymer]

But it still exposes the data.

True, but its only exposing the data to yourself.
No one else will know about that endpoint, will they?
And you could make sure a correct token is being passed in in the event someone else DID find the endpoint.
I just discussed this "objection" last night with someone and we don't see the issue, so I've been leaning toward thinking this is a viable solution.
Jaymer...

[johntalbott]

The REST approach should work given no better option. But it's a mighty inefficient way to accomplish the task of building a JSON string.

How about incorporating https://github.com/google/gson into Aware?

It is designed to convert complex Java objects into JSON objects and vice versa.

Mini-hijack (sorry Jaymer)
Working with JSON has been fundamental to web development for 10 years. It's baked into all of the popular platforms and frameworks.

In general, I'm surprised that the AIM platform hasn't completely shifted from XML to JSON. We're all looking for performance. XML is significantly slower to parse than JSON and way more difficult to work with.

JSON killed XML at least five Friday the 13ths ago.

[aware_support]

Code: Select all

It is designed to convert complex Java objects into JSON objects and vice versa.

Aware IM already includes a library to convert Java to JSON and back.
This is not the point, though. The point is how to convert an Aware IM object to JSON, not Java object.

Keep in mind that the format of the JSON object is likely be defined by the provide of the REST service that you want to consume. Like I said, there can be quite a few subtleties in how this is done and putting all these subtleties into parameters of a function will be very cumbersome.

Exposing data is not an issue. Like Jaymer said you are only exposing it to yourself (URL_CONTENTS call can always use localhost). Besides, you can always create another Aware IM object that will only have attributes that you want to expose and use that object as a parameter.

[BenHayat]

Besides, you can always create another Aware IM object that will only have attributes that you want to expose and use that object as a parameter.

This is the prescribed methodology when exposing data in REST services, to use DTO (Data Transfer Object) model than the entity model. To get even more secure, people should use ViewModel for forms Entries and then map the VM to Entity model before saving to DB to make sure nothing crazy was sent by user.