E9.2 Logic Extension - {28=DD validation failed for value null}

[dtujo2022]

I have an Orchestration that has an input of a UKID that is then using a data request to fetch a record from a table. Two of the columns it is fetching are Date Fields where one or the other is populated with a date and the other is populated with a zero. I can confirm this is the case with Oracle SQL developer where the column is 0. When sending the data from the DREQ into a logic extension I receive the errors {28=DD validation failed for value null} or {29=DD validation failed for value null} depending on which field is populated with a date and which field is zero. I have also tried setting a default value in the Logic Extensions transformations and setting it to 0 as well as making sure those inputs are not required. Am I missing something here? Is JDE automatically assigning 0 as null for transformations in the Orchestrator?

 

[DaveWagoner]

Logic extensions and orchestrations are weird with data types in my experience.

There's what we see if we browse data directly (0 = blank date for a julian date field, which is really just a db numeric), what we see on the frontend, and then whatever orch/lex sees and translates on the "low code" end

Short of seeing exactly what you're looking at, I think if you treat LEX lookups of date fields such as DREQ as a "true date" within your LEX, and do logic based on that, rather than look for what you're seeing via db data tool, you'll be good to go.

Bring DREQ into the LEX via a Fetch, then check that or do operations on that within the LEX using the built-in date functions. If you ever did Named Event Rules, or even just Event Rules, it is much the same concept.

Hope that's a bit helpful

 

[dtujo2022]

Logic extensions and orchestrations are weird with data types in my experience.

There's what we see if we browse data directly (0 = blank date for a julian date field, which is really just a db numeric), what we see on the frontend, and then whatever orch/lex sees and translates on the "low code" end

Short of seeing exactly what you're looking at, I think if you treat LEX lookups of date fields such as DREQ as a "true date" within your LEX, and do logic based on that, rather than look for what you're seeing via db data tool, you'll be good to go.

Bring DREQ into the LEX via a Fetch, then check that or do operations on that within the LEX using the built-in date functions. If you ever did Named Event Rules, or even just Event Rules, it is much the same concept.

Hope that's a bit helpful

I ended passing in the UKID and did a fetch next with UKID. I would rather not do it this way which defeats the purpose of the DREQ that I created and in my opinion the DREQ is easier to manage outputs than the fetch single.

 

[DaveWagoner]

I ended passing in the UKID and did a fetch next with UKID. I would rather not do it this way which defeats the purpose of the DREQ that I created and in my opinion the DREQ is easier to manage outputs than the fetch single.

I look forward to when we can call orchs and/or orch components via LEX. (I know about the B98ORCH trick, but it's so blah. I want my dstrs to come thru proper-like)

 

[Kevin Long]

It is a bit of a worlds colliding situation. A data request, even though it is querying a JDE database, is going to return the date as either a string ("12/19/2023") or a numeric such as a UTC value (1703013927) as part of a JSON object. If there is no date value in JDE (i.e. the date field equals zero), no value is returned (i.e. null). This makes sense when you are working with external systems because that would be how you would represent the absence of a value.
{
"fs_DATABROWSE_F4211": {
"title": "Data Browser - F4211 [Sales Order Detail File]",
"data": {
"gridData": {
"id": 54,
"fullGridId": "54",
"columns": {
"F4211_DOCO": "Order Number",
"F4211_LNID": "Line Number",
"F4211_IVD": "Invoice Date"
},
"rowset": [
{
"F4211_DOCO": 13,
"F4211_LNID": 1,
"F4211_IVD": null
}
],
"summary": {
"records": 1,
"moreRecords": true
}
}
},
"errors": [],
"warnings": []
},
"currentApp": "DATABROWSE_F4211",
"timeStamp": "2023-12-19:13.53.57",
"sysErrors": []
}
However, when you pass a null into a logic extension, you are actually going back into the JDE world where the data structure is defined by JDE data dictionary items, nulls do not exist, and the absence of a date is zero. In my opinion, I think what you are experiencing is a bug and the logic extension should convert the null into a Blank Date.

I think @DaveWagoner's approach to look up the date in the LEX is a good work around. Depending on what you are trying to do in the LEX, another alternative would be to build your logic in a custom request where both Groovy and JRuby can accommodate nulls.