After eagerly waiting for appmaker its finally here! I immediately started diving into it and i love it.
I want to make a basic app to track the status of our chromebooks from a spreadsheet, which i think appmaker is quite a good option for.
Well, i followed the database connection screen and got everything hooked up, but when i try to load it in via a widget is gives me a error when i run the app
I get the following error:
E
Fri Jun 15 12:40:08 GMT+200 2018
The function queryRecords returned undefined, please make sure a value was explicitly returned. Error: The function queryRecords returned undefined, please make sure a value was explicitly returned.
E
Fri Jun 15 12:40:08 GMT+200 2018
Executing query for datasource InventorySheet: (Error) : The function queryRecords returned undefined, please make sure a value was explicitly returned.
E
Fri Jun 15 12:40:08 GMT+200 2018
Executing query for datasource InventorySheet failed.
How do we fix this?
Greetings,
Luuk
Related
Im trying to update an entity using the PATCH /v2/entities/id/attrs endpoint. The service of the id is known; however, the servicepath is not.
My first attempt was to leave the header empty or rather not send it at all. For a GET query, this does the job right, however for a PATCH, this returns me a 200. First question, is this the expected behavior?
Second try was to use a wildcard. I know that my entity is at SP /automatization/<something>. I tried PATCHing to /automatization/# and got a 204, but the entity did not change.
My last try was to use a list of known SPs: I know the entity I want is in one of a number of SPs, so a used a comma separated list as the SP header. Same as above: 204 but no change.
Am I missing something?
Orion version:
{
"orion": {
"version": "2.3.0-next",
"uptime": "2 d, 1 h, 50 m, 52 s",
"git_hash": "c99fef1b5c93bf1673d407968c2c101f01b95980",
"compile_time": "Tue Mar 10 09:46:52 UTC 2020",
"compiled_by": "root",
"compiled_in": "0a42bdf43030",
"release_date": "Tue Mar 10 09:46:52 UTC 2020",
"doc": "https://fiware-orion.rtfd.io/"
}
}
It's unfortunate that the service path isn't returned in the payload data of the queries. That would have solved your problem. If I were you (and if you have access to the DB) I'd use the mongo shell to find the service path of your entity.
About getting a 204, that seems like a bug. The entity you want to patch isn't found (as you put in the wrong service path) and a 404 should be returned.
Lists and wildcards as service paths are only for queries, never for creation/updates. The broker should complain there too, with a 400 and 'Invalid Service-path', if you ask me ...
Seems like we have two issues here, apart from the one to include service path in the response ...
I am trying to re-use a class and run it in a job to prove something out. Here is the job code:
InventQuarantineOrder_Scrap scrap = new InventQuarantineOrder_Scrap();
;
scrap.parmInventQuarantineId('00016749_077');
scrap.parmScrapQty(360);
scrap.parmTransDate(Today());
scrap.run();
When I run this code, I get the error:
The cursor is invalid for instantiating recordViewCache
Researching this error led to me this link, which I tried to implement but I got syntax errors I'm not sure how to fix. I copied the class and created a new runOnServer method. But then a validate method doesn't work. So I modify the validate method to run on the server:
static server boolean validate()
{
InventQuarantineOrder inventQuarantineOrder = InventQuarantineOrder::find(inventQuarantineId);
;
....
}
Which gave me this error:
Variable inventQuarantineId has not been declared.
If I comment out the validate() call from the runOnServer method, I get the same error/problem with the inventQuarentineId variable not being declared (it's also used in the run method).
From here, I am not sure how to continue. What am I doing wrong? Is it possible to use these methods inside a server method? Another thing worth noting I think is that I think the job code actually worked, but it did throw 3 lines those "cursor is invalid for instantiating recordViewCache." info alerts.
As you already found out, a RecordViewCache can only be used on the server tier. By starting your process in the job on the client tier, the method that creates the RecordViewCache (method viewCacheInventTransId of table InventTrans) is also executed on the client tier, which causes the error. If you put a breakpoint in this method, the call stack in the debugger shows you this:
Tier Method Line
[c] \Data Dictionary\Tables\InventTrans\Methods\viewCacheInventTransId 9
[c] \Classes\InventMovement\viewCacheInventTransId 7
[s] \Classes\InventUpd_Financial\initUpdate 14
[s] \Classes\InventUpd_Financial\newVirtuelQuarantineLoss 19
[c] \Classes\InventQuarantineOrder_Scrap\run 76
[c] \Jobs\Job4
The solution in the link you gave is for your case a bit more complicated than it needs to be (my comment was my first idea to fix this solution). You just need to create a class with a static server method that executes your job code. You can then call this static server method in your code. Now the debugger will show you the following call stack:
Tier Method Line
[s] \Data Dictionary\Tables\InventTrans\Methods\viewCacheInventTransId 9
[s] \Classes\InventMovement\viewCacheInventTransId 7
[s] \Classes\InventUpd_Financial\initUpdate 14
[s] \Classes\InventUpd_Financial\newInventQuarantineOrder 21
[s] \Data Dictionary\Tables\InventQuarantineOrder\Methods\startFinancial 12
[s] \Classes\InventQuarantineOrder_Scrap\run 54
[s] \Classes\Class1\jobOnServer 10
[c] \Jobs\Job4 5
Is there a definition what values should be send in OData Edm:DateTime of a SAP Netweaver Gateway service?
Especially should it always be interpreted as UTC?
I assume the SAPUI5 library is smart enough to handle all this time zone problems automatically if the interface is correct defined -- question is, what is correct?
I would prefer to use some code like this, at client side:
new sap.m.DatePicker({
value : {
path : "BirthDate",
type : new sap.ui.model.type.Date
}
}),
How do you solve these problems?
Edit
Time zone handling seems still to be strange to me.
SAP Gateway Server sends in an Edm:DateTime following: 2015-04-16T00:00:00
Any time zone information is missing.
If I bind a date picker like this:
var oContent = new sap.m.DatePicker({
value : {
path : "Date",
type : new sap.ui.model.type.Date({
style: "short",
})
}
})
I got the following output: 16.04.15 (seems to be correct).
Binding a date picker without type information shows: Thu Apr 16 2015 02:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)
If I change the date with the date picker to 17.04.15 the second line is:
Fri Apr 17 2015 00:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)
Please note the difference in time (2 hours missing).
If I send it to the server I got Edm.DateTime == 2015-04-16T00:00:00
Control shows:
Thu Apr 16 2015 02:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)
If I use
new sap.m.DatePicker({
value : {
path : "Date",
type : new sap.ui.model.type.Date({
style: "short",
UTC: true
})
}
})
Data seems to be correct (the 2 hours are not missing after picking a new date).
I am asking me, is there any definition what type of data gateway will send?
If the timezone is missing inside the Edm.DateTime information how should a client work correct? Especially if clients are in different time zones available?
Strange enough I have a similar problem by using a filter. But there the UTC flag seems not working.
Anyone with some experience on that topic? Or any hints to a good documentation?
* https://sapui5.netweaver.ondemand.com/sdk/#docs/guide/91f3070d6f4d1014b6dd926db0e91070.html
Says more or less "take care" but not how :-/
Further information
I detected the same question on SAP network (http://scn.sap.com/thread/3574419). Not sure if the given answer is correct. Looks like hacking around in meta-data which should not be required?
I am still searching for a solution to this problem
I detected different handling of data in case of binding and filter usage.
I can't answer with regard to SAP, as I am not familiar. But I can provide some insights based on OData.
The Edm:DateTime type is based on the W3C XML Schema xs:dateTime, which is in-turn based on ISO8601. Both XML Schema and ISO8601 state that times without a time zone are to be considered "local time". That is, local to someone. Whose "local" it is intentionally undefined.
From W3C XML Schema §3.2.7:
"Local" or untimezoned times are presumed to be the time in the timezone of some unspecified locality as prescribed by the appropriate legal authority
From ISO 8601 3rd Edition §4.3.2:
The zone designator is empty if use is made of local time ...
Consider your example of 2015-04-16T00:00:00. The only way to know what exact moment in time this refers to is to have some additional context applied. In the case of a birthday, this could be the time zone where the person is currently located (where they celebrate their birthday, not where they are born). Or, it could be some arbitrary location if the person's location is unknown - perhaps the time zone of the person using the system.
Therefore, the interpretation of the value is where the time zone is being applied. In your case, it would appear that some local time zone is being applied during deserialization.
Also consider that a birthday is better represented by just a calendar date, rather than midnight on a date. The Edm:Date type is better suited for this. For other types, especially if you know that the value is UTC or in a specific time zone, then Edm:DateTimeOffset is more appropriate.
Also recognize that the Edm:DateTime type was dropped from OData spec in version 4.0. Many (including myself) consider this a mistake. I'm not sure if this affects you or not, but you should be aware.
Hope that helps.
Use type sap.ui.model.type.Date({ oFormatOptions:{ style: "short", UTC: true} }) this will retain your date as it is sent by server
Could you try binding the date path to dateValue instead of value.
It should automatically interpret Edm:DateTime.
new sap.m.DatePicker({
dateValue : "{BirthDate}"
})
I am using Moment.js and manipulating a date using moment.hour(xx) moment.minute(xx).
When i console.log the moment i see that the object contains a _d and _i:
the _d contains the correct changed moment.hour() or moment.minute() changes however the _i object contains the original?
k {_isAMomentObject: true, _i: Thu Dec 11 2014 20:34:00 GMT+0200 (South Africa Standard Time), _isUTC: false, _pf: Object, _locale: j…}
_d: Thu Dec 11 2014 14:00:00 GMT+0200
_i: Thu Dec 11 2014 20:34:00 GMT+0200
Could anyone enlighten me?
Pay no attention to those. Use the various output functions, such as .format() instead. See the Moment.js guidance on this topic. In short, all fields that are prefixed with an underscore (_) should be considered off limits.
The moment internals have some quirks due to how the Date object works. All of the functions in the public API take them into account, but you probably don't want to figure them out yourself.
Just to be complete though, I'll elaborate on their purpose:
_i is the input used when create the moment object. It can be a string, a number, an array, or a Date object.
However, if another moment object is passed in, the _i will be copied to that moments _i, and other properties will also be copied over. _i will never be a moment object.
_i can also be undefined, in the case of creating the current moment with moment().
_d is the instance of the Date object that backs the moment object.
If you are in "local mode", then _d will have the same local date and time as the moment object exhibits with the public API. The timestamps returned by getTime or valueOf will also match.
If you are in "UTC mode", then _d will still have the same UTC date and time as the moment object exhibits with the public API. This may be confusing, as you'd need to look at getUTCDate and other UTC-based functions on _d in order to see them match. The timestamps will still match here as well.
If you've changed the time zone offset, with the utcOffset, zone, or tz functions, then the _d value cannot stand alone. It must also consider if _offset is defined. If it is, then the timestamp backing the _d object has to first be adjusted by the amount of the offset. You can see this behavior in the implementation of the valueOf method here.
Also, if you look at the string output of _d when a different offset or time zone has been applied, it will appear that _d is using the local time zone. However, that conversion to local time is simply a side effect of the toString function of the Date object. Moment does not use that result in its functions.
This is the behavior for these two fields as of the current version (2.10.6 as I'm writing this). However, there are other fields as well, and since these are internal fields, it's entirely possible the behavior could change in a future version. In particular, see issue #2616.
As a complement to #Matt's answer:
Checkout this result from the chrome's console:
date1 is a moment's valid object:
As you can see, ._d and ._i have different values. So you better use the format() function (as #Matt Johnson wrote) inside your source code.
I am creating a new Entity and inside constructor I set the datetime like
function Project() {
this.created = moment().format();
}
which produce a result in console the current date and time
Sat Jun 07 2014 18:48:41 GMT+0500 (Pakistan Standard Time)
As soon as I call save changes and see the posted date in the network tabe it changes the hour part of datetime 2014-06-07T13:48:41.000Z
It looks like Breeze does this, may be I am wrong, Any suggestion how can I prevent this to happen?
Breeze is just serializing the date for transport It is not transformed at all. If you look it is 5 hours different in UTC meaning it will localize out the same when you moment.format it again.
If you want to re-localize it just use moment(yourDate).format(LL) or something similar.
http://momentjs.com/ and go to Internationalization section