Netsuite logger string is too long to show up in details field - netsuite

When I log a whole Purchase or sales order record object using JSON.stringifyy(SOobject);,the logger don't show the whole object, What could I do to see entire object. The log level used is Log.debug({})

As per NetSuite's documentation, you cannot log more than 3999 characters in one log - see excerpt from SuiteAnswers "log.debug(options)" page below:
For a temporary quick and easy solution to overcome this limitation in order to troubleshoot some specific part of your script, you can call email.send() and include the details in the email body.

Similar to what Krypton suggested, typically I will write my long JSON or other data directly to an output text log file in the file cabinet. This I find is more reliable because sandbox will not send out emails unless specifically configured to do so.

Our approach for long string is that we separate the long log string into several parts and print each one.
function logger(str) {
str.match(/.{1,3000}/g).forEach(function(smallString, idx) {
log.debug('part' + idx, smallString);
});
}
var longStr = 'xxxx.....xxxxxx'; // This is your long string
logger(longStr);
However, I think sending mail is a better way in this case :)

Related

How to use fhir client search to include all resources i.e. ($everything)

How would you search for all resources for a given patient e.g. encounter, appointment, consent?
I know you could search for it via postman request http://localhost:9090/organId/Patient/12345/$everything and get the result. But I want to be able to execute the search query from my java program.
This is what I have so far, but I know the include part is not good and not working. Googling didn't return any result.
Bundle bundle = myFhirClient
.search()
.forResource(Patient.class)
.returnBundle(Bundle.class)
.where(new NumberClientParam(Patient.SP_RES_ID).exactly().number(patientId)).include(new Include("$everything"))
.sort(new SortSpec().setOrder(SortOrderEnum.DESC).setParamName(Patient.SP_RES_ID))
.execute();
Any help is much appreciated
I had to use Fhir Client operation instead of search. This will return all the reference resources for the given patientId.
Parameters outParams = myFhirClient
.operation()
.onInstance(new IdType("Patient", patientId))
.named("$everything")
.withNoParameters(Parameters.class) // No input parameters
.execute();

How to use the function transaction.retrieve() to get receipt data?

I am developing a transaction workflow capsule, and I use the function transaction.retrieve() to get order data from the platform. But it returns only part of the order data.
MyReceipt is a structure stored the order informations, it is defined like this:
structure (MyReceipt) {
description (order info)
// properties
features { activity}
}
And it is built as a output concept of Commit Action, like this
action (CommitRequest) {
type (Commit)
description ()
collect {
// MyRequest
}
output (MyReceipt)
}
I try to get data like this
transaction.retrieve("bixby.MyCapsule.MyReceipt")
It is supposed to return all the MyReceipt Data. But it return only part of the Receipt data.Is it right to get all the orders? Or is there other ways to get all the receipt data?
And I have found the sample code use it just like this to get the last Receipt data
transaction.retrieve("bixby.MyCapsule.MyReceipt", "ALL", 1)
but it doesn't explain what these two parameter "ALL" and 1 represent for. And I want to get more details about the usage of this function.
Could you plz tell me how to use the function transaction.retrieve() or other function to get all the Receipt historical data, and How can I check out the transaction data for someone when I try to find the cause of the issue.
Copy the answer from dogethis. (Thanks, man! You do the hard work, I took credit)
We have the DOC ready online here
Basically, ALL is the default to get all state of transaction data, and 1 means only one record. The API page was not there before, so thanks for let us know.
I think it's the 1 cause you not get all record, but it does has a limit 20...
Have fun with Bixby!

Azure Application Insight. Custom attribute length restriction

I'm using Azure App Insight as a logging tool and store log data by the following code:
private void SendTrace(LoggingEvent loggingEvent)
{
loggingEvent.GetProperties();
string message = "TestMessage";
var trace = new TraceTelemetry(message)
{
SeverityLevel = SeverityLevel.Information
};
trace.Properties.Add("TetstKey", "TestValue");
var telemetryClient = new TelemetryClient();
telemetryClient.Context.InstrumentationKey = this.InstrumentationKey;
telemetryClient.Track(trace);
}
everything works well. I see logged record in App insight as well as in App insight analytics (in trace table). My custom attributes are written in special app insight row section - customDimensions. For example, the above code will add new attribute with "TestKey" key and "TestValue" value into customDimensions section.
But when I try to write some big text (for example JSON document with more then 15k letters) I still can do it without any exceptions, but the writable text will be cut off after some document length. As the result, the custom attribute value in customDimensions section will be cropped too and will have only first part of document.
As I understand there is the restriction for max text length which is allowed to be written in app insight custom attribute.
Could someone know how can I get around with this?
The message has the highest allowed limit of 32768. For items in the property collection, value has max limit of 8192.
So you can try one of the following options:
Use message field to the fullest by putting the big text there.
Split the data into multiple, and add to properties collection separately.
eg:
trace.Properties.Add("key_part1", "Bigtext1_upto8192");
trace.Properties.Add("key_part2", "Bigtext2_upto8192");
Reference: https://github.com/MicrosoftDocs/azure-docs/blob/master/includes/application-insights-limits.md

Not able to log lengthy messages using application insights trackEvent() method in Node.js

We are trying to log some lengthy message using AppInsights trackEvent() message. But it is not logging into AppInsights and not giving any error.
Please help me in logging lengthy string.
Please let us know the max limit for the trackEvent()
if you want to log messages then you should be using the trackTrace methods of the AI SDK, not trackEvent. trackTrace is intended for long messages and has a huge limit: (32k!) See https://github.com/Microsoft/ApplicationInsights-dotnet/blob/develop/Schema/PublicSchema/MessageData.bond#L13
trackEvent is intended for named "events" like "opened file" or "clicked retry" or "canceled frobulating", where you might want to make charts, and track usage of a thing over time.
you can attach custom properties (string key, string value) and custom metrics (string key, double value) to anything. and if you set the operationId field on things in the sdk, anything with the same operationId can be easily found together via queries or visualized in the Azure Portal or in Visual Studio:
There are indeed limitation regarding the length. For example, the limit of the Name property of an event is 512 characters. See https://github.com/Microsoft/ApplicationInsights-dotnet/blob/master/src/Core/Managed/Shared/Extensibility/Implementation/Property.cs#L23
You can split it on substrings and put in Properties collection, each collection value length is 8 * 1024. I got this as a tip when I asked for it. See https://social.msdn.microsoft.com/Forums/en-US/84bd5ade-0b21-47cc-9b39-c6c7a292d87e/dependencytelemetry-sql-command-gets-truncated?forum=ApplicationInsights. Never tried it myself though

Best practice to pass query conditions in ajax request

I'm writing a REST api in node js that will execute a sql query and send the results;
in the request I need to send the WHERE conditions; ex:
GET 127.0.0.1:5007/users //gets the list of users
GET 127.0.0.1:5007/users
id = 1 //gets the user with id 1
Right now the conditions are passed from the client to the rest api in the request's headers.
In the API I'm using sequelize, an ORM that needs to receive WHERE conditions in a particular form (an object); ex: having the condition:
(x=1 AND (y=2 OR z=3)) OR (x=3 AND y=1)
this needs to be formatted as a nested object:
-- x=1
-- AND -| -- y=2
| -- OR ----|
| -- z=3
-- OR -|
|
| -- x=3
-- AND -|
-- y=1
so the object would be:
Sequelize.or (
Sequelize.and (
{x=1},
Sequelize.or(
{y=2},
{z=3}
)
),
Sequelize.and (
{x=3},
{y=1}
)
)
Now I'm trying to pass a simple string (like "(x=1 AND (y=2 OR z=3)) OR (x=3 AND y=1)"), but then I will need a function on the server that can convert the string in the needed object (this method in my opinion has the advantage that the developer writing the client, can pass the where conditions in a simple way, like using sql, and this method is also indipendent from the used ORM, with no need to change the client if we need to change the server or use a different ORM);
The function to read and convert the conditions' string into an object is giving me headache (I'm trying to write one without success, so if you have some examples about how to do something like this...)
What I would like to get is a route capable of executing almost any kind of sql query and give the results:
now I have a different route for everything:
127.0.0.1:5007/users //to get all users
127.0.0.1:5007/users/1 //to get a single user
127.0.0.1:5007/lastusers //to get user registered in the last month
and so on for the other tables i need to query (one route for every kind of request I need in the client);
instead I would like to have only one route, something like:
127.0.0.1:5007/request
(when calling this route I will pass the table name and the conditions' string)
Do you think this solution would be a good solution or you generally use other ways to handle this kind of things?
Do you have any idea on how to write a function to convert the conditions' string into the desired object?
Any suggestion would be appreciated ;)
I would strongly advise you not to expose any part of your database model to your clients. Doing so means you can't change anything you expose without the risk of breaking the clients. One suggestion as far as what you've supplied is that you can and should use query parameters to cut down on the number of endpoints you've got.
GET /users //to get all users
GET /users?registeredInPastDays=30 //to get user registered in the last month
GET /users/1 //to get a single user
Obviously "registeredInPastDays" should be renamed to something less clumsy .. it's just an example.
As far as the conditions string, there ought to be plenty of parsers available online. The grammar looks very straightforward.
IMHO the main disadvantage of your solution is that you are creating just another API for quering data. Why create sthm from scratch if it is already created? You should use existing mature query API and focus on your business logic rather then inventing sthm new.
For example, you can take query syntax from Odata. Many people have been developing that standard for a long time. They have already considered different use cases and obstacles for query API.
Resources are located with a URI. You can use or mix three ways to address them:
Hierarchically with a sequence of path segments:
/users/john/posts/4711
Non hierarchically with query parameters:
/users/john/posts?minVotes=10&minViews=1000&tags=java
With matrix parameters which affect only one path segment:
/users;country=ukraine/posts
This is normally sufficient enough but it has limitations like the maximum length. In your case a problem is that you can't easily describe and and or conjunctions with query parameters. But you can use a custom or standard query syntax. For instance if you want to find all cars or vehicles from Ford except the Capri with a price between $10000 and $20000 Google uses the search parameter
q=cars+OR+vehicles+%22ford%22+-capri+%2410000..%2420000
(the %22 is a escaped ", the %24 a escaped $).
If this does not work for your case and you want to pass data outside of the URI the format is just a matter of your taste. Adding a custom header like X-Filter may be a valid approach. I would tend to use a POST. Although you just want to query data this is still RESTful if you treat your request as the creation of a search result resource:
POST /search HTTP/1.1
your query-data
Your server should return the newly created resource in the Location header:
HTTP/1.1 201 Created
Location: /search/3
The result can still be cached and you can bookmark it or send the link. The downside is that you need an additional POST.

Resources