Some Background.
Have been developing in UV  platform since VB6 and asp class

Now I would like to move on to the latest .NET 5.0 (and future)

2 Issues/Question:

1. Which client/connectivity should I use..?

2. Is there any tool/library where I can convert UniVerse Dynamic String to/from Poco (Plain old Clr Object) or JSON string ? 


Thank you.


------------------------------
Koon MIng Fong
Mr
Rocket Forum Shared Account
------------------------------

Hi Koon MIng Fong

I suggest you looks to Rocket U2 Toolkit for .NET

Rocket Software		remove preview
Rocket U2 Toolkit for .NET Speed development efforts Rocket U2 Toolkit for .NET Developer speeds development efforts. Use Microsoft Visual Studio to build applications and take advantage of the Microsoft .NET Framework and CLR. U2 Connection Pools, designed for high-performance web applications, complete the solution. View this on Rocket Software >

Another option is the MVIS interface 
Rocket MultiValue Integration Server

Rocket Software		remove preview
Rocket MultiValue Integration Server Leverage modern languages and frameworks to access MultiValue data and business logic with the new Rocket® MultiValue Integration Server (MVIS). Rocket MVIS is the next step on the upgrade path for Web DE and U2 REST users, and comes loaded with new features that make your job easier. View this on Rocket Software >

 

------------------------------
Manu Fernandes
------------------------------

---

Hi Koon MIng Fong

I suggest you looks to Rocket U2 Toolkit for .NET

Rocket Software		remove preview
Rocket U2 Toolkit for .NET Speed development efforts Rocket U2 Toolkit for .NET Developer speeds development efforts. Use Microsoft Visual Studio to build applications and take advantage of the Microsoft .NET Framework and CLR. U2 Connection Pools, designed for high-performance web applications, complete the solution. View this on Rocket Software >

Another option is the MVIS interface 
Rocket MultiValue Integration Server

Rocket Software		remove preview
Rocket MultiValue Integration Server Leverage modern languages and frameworks to access MultiValue data and business logic with the new Rocket® MultiValue Integration Server (MVIS). Rocket MVIS is the next step on the upgrade path for Web DE and U2 REST users, and comes loaded with new features that make your job easier. View this on Rocket Software >

 

------------------------------
Manu Fernandes
------------------------------

Hi Manu,

I have tested the U2 Toolkit on .NET core 3.1, the connectivity works, but unfortunately the DynArray is not working. I understand from Rocket support that it only supports .NET framework 4.X.




------------------------------
Koon MIng Fong
Mr
P & O GLOBAL TECHNOLOGIES SDN BHD
KUALA LUMPUR Malaysia
------------------------------

---

Hi Manu,

I have tested the U2 Toolkit on .NET core 3.1, the connectivity works, but unfortunately the DynArray is not working. I understand from Rocket support that it only supports .NET framework 4.X.




------------------------------
Koon MIng Fong
Mr
P & O GLOBAL TECHNOLOGIES SDN BHD
KUALA LUMPUR Malaysia
------------------------------

Hello
Please have a look at these thread. 

https://community.rocketsoftware.com/forums/forum-home/digestviewer/view-question?ContributedContentKey=a9e117bc-35a8-4c02-8726-6448c77a13d0&CommunityKey=dd45d00d-59db-4884-b3eb-2b0647af231b&tab=digestviewer​

Rocket U2 | UniVerse & UniData

Rocketsoftware		remove preview
Rocket U2 | UniVerse & UniData View this on Rocketsoftware >

------------------------------
Manu Fernandes
------------------------------

---

Hello
Please have a look at these thread. 

https://community.rocketsoftware.com/forums/forum-home/digestviewer/view-question?ContributedContentKey=a9e117bc-35a8-4c02-8726-6448c77a13d0&CommunityKey=dd45d00d-59db-4884-b3eb-2b0647af231b&tab=digestviewer​

Rocket U2 | UniVerse & UniData

Rocketsoftware		remove preview
Rocket U2 | UniVerse & UniData View this on Rocketsoftware >

------------------------------
Manu Fernandes
------------------------------

Hello Manu,

Ok thanks for the info..

So they are targeting the 4th quarter of 2021..

To my 2nd Question.

Do you guys convert dynArray to JSON ? This is important..(I guess) cause most front end technology (JS) is using JSON now....

 Thank you again.

------------------------------
Koon MIng Fong
Mr
P & O GLOBAL TECHNOLOGIES SDN BHD
KUALA LUMPUR Malaysia
------------------------------

---

Hello Manu,

Ok thanks for the info..

So they are targeting the 4th quarter of 2021..

To my 2nd Question.

Do you guys convert dynArray to JSON ? This is important..(I guess) cause most front end technology (JS) is using JSON now....

 Thank you again.

------------------------------
Koon MIng Fong
Mr
P & O GLOBAL TECHNOLOGIES SDN BHD
KUALA LUMPUR Malaysia
------------------------------

Hello

Yes, we exchange and convert from/to json but we do it into UNIBASIC subr with udoObject/functions. 

Really useful. 

Have a look at the uniBASIC extensions chapter 10 (udoRead, udoWrite, etc...).

Regards

------------------------------
Manu Fernandes
------------------------------

---

Hello

Yes, we exchange and convert from/to json but we do it into UNIBASIC subr with udoObject/functions. 

Really useful. 

Have a look at the uniBASIC extensions chapter 10 (udoRead, udoWrite, etc...).

Regards

------------------------------
Manu Fernandes
------------------------------

Hi Manu,

Will this udoObject be slow?

Cause I plan to convert the whole record when reading out (and also in)..maybe will have few hundreds attributes...(and many more multivalues)

------------------------------
Koon MIng Fong
Mr
P & O GLOBAL TECHNOLOGIES SDN BHD
KUALA LUMPUR Malaysia
------------------------------

---

Hi Manu,

Will this udoObject be slow?

Cause I plan to convert the whole record when reading out (and also in)..maybe will have few hundreds attributes...(and many more multivalues)

------------------------------
Koon MIng Fong
Mr
P & O GLOBAL TECHNOLOGIES SDN BHD
KUALA LUMPUR Malaysia
------------------------------

is it slow ? 

So far, I evaluate it really quick.

I do not know the design of your app.

If you do it into uniBASIC you need to work node by node but you can target a businees transaction and/or specific json-schema.

Maybe the MVIS can be a solution to expose your db via webservice, MVIS works via a map definition (dicts from/to nodes) but you are limited to the 'record' level AM,VM,SVM. 

Have a nice day

------------------------------
Manu Fernandes
------------------------------

---

is it slow ? 

So far, I evaluate it really quick.

I do not know the design of your app.

If you do it into uniBASIC you need to work node by node but you can target a businees transaction and/or specific json-schema.

Maybe the MVIS can be a solution to expose your db via webservice, MVIS works via a map definition (dicts from/to nodes) but you are limited to the 'record' level AM,VM,SVM. 

Have a nice day

------------------------------
Manu Fernandes
------------------------------

Hi Manu,

During your evaluation roughly how many AM, VM or SVM are involved ?


I am trying to avoid webservices call...the latency will be too big..

------------------------------
Koon MIng Fong
Mr
P & O GLOBAL TECHNOLOGIES SDN BHD
KUALA LUMPUR Malaysia
------------------------------

---

Hi Manu,

During your evaluation roughly how many AM, VM or SVM are involved ?


I am trying to avoid webservices call...the latency will be too big..

------------------------------
Koon MIng Fong
Mr
P & O GLOBAL TECHNOLOGIES SDN BHD
KUALA LUMPUR Malaysia
------------------------------

hello Koon MIng Fong,

To expose the data in json format we have two methods, the first created in uniBASIC from scratch long before UDOs and secondly, the use of UDOs.

We are exposing views and not tables, which means that the exposed data comes from direct dynArray (am / vm / svm) but also from indirect IType / SBexpression values.  In addition, these views allow n-level nesting well beyond SVMs. We can aggregate data from multiple db files into a single json-schema.

So, in performance, we must consider on the one hand the selection into db, on the other hand the extraction and formatting of the data and finally the json serialization.

We find that the performance is impacted if the collections are very large (> 500 records ~ 50 nodes / record ~ ​​1kbytes / json record).

On a 'Support Ticket' application, we see, on average, per request 20 records of 50 nodes / 1k served in 200ms.
Requests on 1 record consume an average of 30ms.

We always try to stay below 500 milliseconds for a request. Then we have optimized in several ways:
- the data extractions are converted into basic which we compile,
- if necessary, the json representation of the dynArray is preconstructed (cached) in a db file on the db trigger, therefore, only the initial selection and aggregation of records in json array is to be done on demand.
- the collections are paginated by 250 records, or according to a parameter

At this stage, it is still in front of a webservice that we needed this format.

At this stage, I think that the serialization is not the heaviest but the overall processing of a request should be considered.
- selection
- extraction / transformation
- serialization
- transport

Hope these considerations help you in the decision.

------------------------------
Manu Fernandes
------------------------------

---

hello Koon MIng Fong,

To expose the data in json format we have two methods, the first created in uniBASIC from scratch long before UDOs and secondly, the use of UDOs.

We are exposing views and not tables, which means that the exposed data comes from direct dynArray (am / vm / svm) but also from indirect IType / SBexpression values.  In addition, these views allow n-level nesting well beyond SVMs. We can aggregate data from multiple db files into a single json-schema.

So, in performance, we must consider on the one hand the selection into db, on the other hand the extraction and formatting of the data and finally the json serialization.

We find that the performance is impacted if the collections are very large (> 500 records ~ 50 nodes / record ~ ​​1kbytes / json record).

On a 'Support Ticket' application, we see, on average, per request 20 records of 50 nodes / 1k served in 200ms.
Requests on 1 record consume an average of 30ms.

We always try to stay below 500 milliseconds for a request. Then we have optimized in several ways:
- the data extractions are converted into basic which we compile,
- if necessary, the json representation of the dynArray is preconstructed (cached) in a db file on the db trigger, therefore, only the initial selection and aggregation of records in json array is to be done on demand.
- the collections are paginated by 250 records, or according to a parameter

At this stage, it is still in front of a webservice that we needed this format.

At this stage, I think that the serialization is not the heaviest but the overall processing of a request should be considered.
- selection
- extraction / transformation
- serialization
- transport

Hope these considerations help you in the decision.

------------------------------
Manu Fernandes
------------------------------

Thanks Manu for the thorough explanation.

I am not so worried about the selection/extraction/transport all..cause we have been doing that for the pass 15 years.. What we did was we consume directly from the UniDynArray..(this is pretty fast)  in our classic ASP pages..

But with the modern asp.net and latest frontend components everything will be in json format..

IMHO, 500ms is a bit too long...(if includes the .net and HTML generation part) this could easily adds up to 1 sec...which is not so acceptable.

another way would be to construct the json in C#...what do you think ?




------------------------------
Koon MIng Fong
Mr
P & O GLOBAL TECHNOLOGIES SDN BHD
KUALA LUMPUR Malaysia
------------------------------

---

Thanks Manu for the thorough explanation.

I am not so worried about the selection/extraction/transport all..cause we have been doing that for the pass 15 years.. What we did was we consume directly from the UniDynArray..(this is pretty fast)  in our classic ASP pages..

But with the modern asp.net and latest frontend components everything will be in json format..

IMHO, 500ms is a bit too long...(if includes the .net and HTML generation part) this could easily adds up to 1 sec...which is not so acceptable.

another way would be to construct the json in C#...what do you think ?




------------------------------
Koon MIng Fong
Mr
P & O GLOBAL TECHNOLOGIES SDN BHD
KUALA LUMPUR Malaysia
------------------------------

Hi Koon MIng Fong, 

Our conclusions are to stay on UV to performs 100% of the server's operations, format the data to json and directly consume by client. We do not add a middel software to operate/transform  the data.
For web, we use angular client with direct request on uv (ajax/Restfull) 
I suppose you must do your hown expériences. 

Regards

------------------------------
Manu Fernandes
------------------------------

---