Storing input parameters - Forum - OpenEdge Development - Progress Community
 Forum

Storing input parameters

This question is not answered

Need some input and/or good ideas.  

I've got an appserver program that returns our products in a large number of ways depending on input.  It's got something like 25 differnt input parameters, CHARS, DATES and INTEGERS. 

This program is called from a web front that collect various data from the user and then renders a view of our products. Works like a charm!

Roughly what I've got:

RUN returnProducts.p ON ghServer 
( INPUT productTypes , INPUT fromPrice , INPUT toPrice , INPUT fromGrade , INPUT toGrade , INPUT parameter1 , INPUT parameter2 , INPUT parameterN , INPUT sortingOption , INPUT pageToShow , INPUT resultsPerPage , OUTPUT ttFilteredProducts).

Now I want to specify certain fixed parameter settings to use at various points, for instance for background jobs generating xml-feeds with our products as well as webpages returning specific products on sale. Something like 50-100 different such settings will exists. The final goal is for our sale managers to be able to set up these parameters themselves and then make that collection of products into a webpage, xml-feed, rss-feed etc.

What I need is a table in which to store all parameter settings together with some metadata. I can see some options here:

1) Store parameters in a table with one field for each input parameter. Positive: easy to do. Negative: changing parameters will lead to schema changes.

2) Store all parameters in a single character field with some kind of delimiter. For instance first entry in a pipe delimited value is the first parameter, second entry is second parameter etc. Positive: easy and flexible schema . Negative:  harder to maintain, require a more complicated UI to make sure data types are correct etc. 

3) Rewrite the server-side program to take a value-pair TEMP-TABLE (ie tt.parameterName + tt.parameterValue) as input instead. Positive: easy to translate into a matching db table and flexible. Negative: lots of work to redo server-side program as well as existing UI.

Oh, and not OO!

Any better ideas? 

All Replies
  • Other ideas – not sure if better.
     
    A question: what are you planning on storing? Both the metadata (ie "returnProducts" has these N parameters) and arguments (this particular call is for "returnProducts" and the N parameters have M values)?

    1) Store parameters in a table with one field for each input parameter. Positive: easy to do. Negative: changing parameters will lead to schema changes.

    For storing the meta-data, a variant of this:
    A table for the call (ie name = returnProducts)
                    Field CallName
    You can also add other stuff like access control and visibility (public, public-to-abl, public-to-web etc)
     
    And then a table for the arguments
                    Field parentCall
                    Field paramOrder
                    Field paramName
                    Field paramType (CHAR, INT, ...)
                    Field paramIOMode (IN, OUT, IN-OUT, ...
    No schema changes when you add new calls.
     
    For runtime, a variant of 3):

    3) Rewrite the server-side program to take a value-pair TEMP-TABLE (ie tt.parameterName + tt.parameterValue) as input instead. Positive: easy to translate into a matching db table and flexible. Negative: lots of work to redo server-side program as well as existing UI.

    4) Rewrite server to take a JSON argument. Pros: very flexible in the structure of the filter/argument; JSON is native to the web (so no translations to/from a TT. Cons: rewrite server code. But I suspect you have to do that anyway (although you could wrap the existing procedures around the new JSON-based procedure too)
     
     
     
    From: Jens Dahlin [mailto:bounce-Jensairtoursse@community.progress.com]
    Sent: Thursday, 09 April, 2015 09:20
    To: TU.OE.Development@community.progress.com
    Subject: [Technical Users - OE Development] Storing input parameters
     
    Thread created by Jens Dahlin

    Need some input and/or good ideas.  

    I've got an appserver program that returns our products in a large number of ways depending on input.  It's got something like 25 differnt input parameters, CHARS, DATES and INTEGERS. 

    This program is called from a web front that collect various data from the user and then renders a view of our products. Works like a charm!

    Rougly:

    RUN returnProducts.p ON ghServer 
                        ( INPUT productTypes
                        , INPUT fromPrice
                        , INPUT toPrice
                        , INPUT fromGrade
                        , INPUT toGrade
                        , INPUT parameter1
                        , INPUT parameter2
                        , INPUT parameterN
                        , INPUT sortingOption
                        , INPUT pageToShow
                        , INPUT resultsPerPage
                        , OUTPUT ttFilteredProducts).
                        

    Now I want to specify certain fixed parameter settings to use at various points, for instance for background jobs generating xml-feeds with our products as well as webpages returning specific products on sale. Something like 50-100 different such settings will exists. The final goal is for our sale managers to be able to set up these parameters themselves and then make that collection of products into a webpage, xml-feed, rss-feed etc.

    What I need is a table in which to store all parameter settings together with some metadata. I can see some options here:

    1) Store parameters in a table with one field for each input parameter. Positive: easy to do. Negative: changing parameters will lead to schema changes.

    2) Store all parameters in a single character field with some kind of delimiter. For instance first entry in a pipe delimited value is the first parameter, second entry is second parameter etc. Positive: easy and flexible schema . Negative:  harder to maintain, require a more complicated UI to make sure data types are correct etc. 

    3) Rewrite the server-side program to take a value-pair TEMP-TABLE (ie tt.parameterName + tt.parameterValue) as input instead. Positive: easy to translate into a matching db table and flexible. Negative: lots of work to redo server-side program as well as existing UI.

    Any better ideas? 

    Stop receiving emails on this subject.

    Flag this post as spam/abuse.

  • Thanks!

    Actual values is basically all I need. Metadata would be a bonus but I think both your ideas are good. This will require some thinking...

  • What version of OpenEdge?  It matters.
     
    Please don’t use single fields to pass multiple values.  Someone is going to want to use your delimiter in a value.  You’re also going to have to use positional based arguments which I’ll guarantee will eventually come back to bite you in the future when someone decides to re-use one of the fields. 
     
    Send a pair of arrays one with field name, one with field value, or a temp-table with nam-value pairs as  you suggest (in lieu of the ABL supporting proper Dictionary objects), or if you prefer OO, then pass an object which you can then extend with new fields as needed..
     
    Doing this in java or some other OO language, I would wrap this into a single object and pass that single object instead.  Martin in Clean Code (pg 43) argues that having more than 2- 3 parameters to a function is wrong.  The fix is to use a “parameter class” which encapsulates the data you need to pass, and then simply pass an instance of that one object.
     
    I ask what openedge version, because in recent version you can pass objects across appserver boundary.
     
    mattB
     
    From: Jens Dahlin [mailto:bounce-Jensairtoursse@community.progress.com]
    Sent: Thursday, April 09, 2015 9:20 AM
    To: TU.OE.Development@community.progress.com
    Subject: [Technical Users - OE Development] Storing input parameters
     
    Thread created by Jens Dahlin

    Need some input and/or good ideas.  

    I've got an appserver program that returns our products in a large number of ways depending on input.  It's got something like 25 differnt input parameters, CHARS, DATES and INTEGERS. 

    This program is called from a web front that collect various data from the user and then renders a view of our products. Works like a charm!

    Rougly:

    RUN returnProducts.p ON ghServer 
                        ( INPUT productTypes
                        , INPUT fromPrice
                        , INPUT toPrice
                        , INPUT fromGrade
                        , INPUT toGrade
                        , INPUT parameter1
                        , INPUT parameter2
                        , INPUT parameterN
                        , INPUT sortingOption
                        , INPUT pageToShow
                        , INPUT resultsPerPage
                        , OUTPUT ttFilteredProducts).
                        

    Now I want to specify certain fixed parameter settings to use at various points, for instance for background jobs generating xml-feeds with our products as well as webpages returning specific products on sale. Something like 50-100 different such settings will exists. The final goal is for our sale managers to be able to set up these parameters themselves and then make that collection of products into a webpage, xml-feed, rss-feed etc.

    What I need is a table in which to store all parameter settings together with some metadata. I can see some options here:

    1) Store parameters in a table with one field for each input parameter. Positive: easy to do. Negative: changing parameters will lead to schema changes.

    2) Store all parameters in a single character field with some kind of delimiter. For instance first entry in a pipe delimited value is the first parameter, second entry is second parameter etc. Positive: easy and flexible schema . Negative:  harder to maintain, require a more complicated UI to make sure data types are correct etc. 

    3) Rewrite the server-side program to take a value-pair TEMP-TABLE (ie tt.parameterName + tt.parameterValue) as input instead. Positive: easy to translate into a matching db table and flexible. Negative: lots of work to redo server-side program as well as existing UI.

    Any better ideas? 

    Stop receiving emails on this subject.

    Flag this post as spam/abuse.

  • And, if you want to make the solution technology neutral, consider passing JSON equivalent to the temp-table instead of the temp-table itself since then any kind of client can submit a request.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  •  
    Be careful not to mix “transport” concepts with “message encoding” concepts.  Using JSON as a message encoding is nice with working with HTTP.  But for appserver it isn’t a good thing.  Using JSON on the wire should be handled as the mapping layer on the edge of your application boundary (in your case into the appserver, and out of the appserver).  This is what REST Adapter (oe web server) is for.  It takes care of the message encoding, and tomcat deals with the transport (HTTP).
     
    Passing “raw” JSON inside a memptr or  longchar through a straight appserver call means your application is no longer transport or encoding neutral.  What you would end up with is taking care of both the encoding and the transport inside your application.  And then you are still stuck with an appserver run statement.
     
     
    From an application stand point use the encoding that makes your application maintainable.  But of course, also consider future encodings.  Sending raw JSON in a longchar means you have to either map that JSON back to objects or temp-tables on BOTH ends, or you have to write the code that consumes it to work purely with JSON on BOTH ends (client and appserver). 
     
    ABL doesn’t have good reflection or annotation support so you building a flexible framework to make this consumption easy isn’t possible yet. In java world we have libraries like Jackson and Jax-RS that handle this.  ABL isn’t there yet.
     
    Please don’t use JSON as message encoding format for appserver unless you are using REST adapter.  It isn’t appropriate.  If you are going to REST adapter in the future, consider using a data type that can be consumed by the REST adapter.  OOABL cannot be right now, but temp-tables and arrays can be.
     
     
    From: Thomas Mercer-Hursh [mailto:bounce-tamhas@community.progress.com]
    Sent: Thursday, April 09, 2015 12:45 PM
    To: TU.OE.Development@community.progress.com
    Subject: RE: [Technical Users - OE Development] Storing input parameters
     
    Reply by Thomas Mercer-Hursh

    And, if you want to make the solution technology neutral, consider passing JSON equivalent to the temp-table instead of the temp-table itself since then any kind of client can submit a request.

    Stop receiving emails on this subject.

    Flag this post as spam/abuse.

  • Well, Matt, I would question a couple of points.  It is fine to deal with things as a TT on the AppServer and, at the last minute, use WRITE-JSON to provide a parameter to pass.   Likewise, at the ABL client end, a single READ-JSON should turn that back into a TT so there is no need to write JSON handling code at either end.   And, a number of the possible consuming clients are not REST, but rather Java, .NET, or Web clients calling to the AppServer.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Thomas, which client that can communicate with the AppServer can't handle Temp-Table parameters?

    - Progress Client, check
    - .NET Client, check
    - Java Client, check
    - SOAP Client, check
    - Java Client, Check

    Did I miss one?

    Jens question was about storing parameters for later redo.

    What I dislike about name/value temp-tables is they are not strong typing the method call.

    A specific temp-table is strong typed but can have 0, 1 or many parameters. And you can't enforce that on the methods signature.

    So I would build my own concept of serializable objects. Pick XML, Json or whatever format you like. That allows you to store them in DB or flat file and also pass them from those clients that do not support the native object serialization of 11.4

    My preference was JSON as the format.

    Von meinem Windows Phone gesendet

    Von: Thomas Mercer-Hursh
    Gesendet: ‎09.‎04.‎2015 18:44
    An: TU.OE.Development@community.progress.com
    Betreff: RE: [Technical Users - OE Development] Storing input parameters

    Reply by Thomas Mercer-Hursh

    And, if you want to make the solution technology neutral, consider passing JSON equivalent to the temp-table instead of the temp-table itself since then any kind of client can submit a request.

    Stop receiving emails on this subject.

    Flag this post as spam/abuse.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • In ABL you don't know the serialization format for temp-tables.  You don't care.  It just works as the run statement takes care of it for you.  The RUN statement in this case is your boundary.  

    As Mike points out, the open clients, ABL clients, appserver, and REST adapter all deal with it with varying degrees of transparency.  So from the ABL application developer perspective the message encoding is a black box and you don't worry deal with it.

    I also agree with his point about strong typing.  You lose that when you use name-value pairs.  BUT...

    When straight ABL (ignoring open clients and rest adapter for the moment) you cannot do this with objects.  11.5 introduced ABL object serialization across appserver boundary, but support wasn't added for the open clients and rest adapter, files and so on.  So the serialization format isn't technology neutral yet, your application has to deal with it.  I speculate that eventually this will be addressed.

    If you pick JSON and bundle it into a longchar variable you've chosen your message encoding  at the application layer instead of at the transport layer.  You can no longer change it.  You want XML?  That's a new parameter to request XML. Ignore the "efficiency" arguments for the moment.  You still haven't transported it yet, you have merely changed the encoding from say "object" to "string".

    So for future proof you need a technology (read: transport) neutral solution that doesn't burn the message encoding into the application layer, allows easy additions of new name-value pairs so API signatures don't have to change (read: the .p running on the appserver), and allows for new future encodings.

    The choice is based on the technologies and future technologies in play.  If you'll never use open client, and always use OOABL (for the moment), then objects are a first place choice.  Or you can bet in the future that additional OOABL serialization options become available to support those other transports.  If you are using/going open client, or REST adapter, then and you need it now, then this isn't a good choice.

  • I agree with all your point s, Matt!

    But all relevant client technologies today either work well with JSON or XML... Our deserialization routine checks the first char to know if the one parameter object was passed as XML or JSON. So I can pass XML Serializable from .NET or JSON from Java Script through JSDO. And I also feel future proof as there is only a small set of code that deals with Serialization and Deserialization. When a new format become en vougue I trust I can incorporate that without impacting any application code.

    Von meinem Windows Phone gesendet

    Von: Matt Baker
    Gesendet: ‎09.‎04.‎2015 19:22
    An: TU.OE.Development@community.progress.com
    Betreff: RE: [Technical Users - OE Development] Storing input parameters

    Reply by Matt Baker

    In ABL you don't know the serialization format for temp-tables.  You don't care.  It just works as the run statement takes care of it for you.  The RUN statement in this case is your boundary.  

    As Mike points out, the open clients, ABL clients, appserver, and REST adapter all deal with it with varying degrees of transparency.  So from the ABL application developer perspective the message encoding is a black box and you don't worry deal with it.

    I also agree with his point about strong typing.  You lose that when you use name-value pairs.  BUT...

    When straight ABL (ignoring open clients and rest adapter for the moment) you cannot do this with objects.  11.5 introduced ABL object serialization across appserver boundary, but support wasn't added for the open clients and rest adapter, files and so on.  So the serialization format isn't technology neutral yet, your application has to deal with it.  I speculate that eventually this will be addressed.

    If you pick JSON and bundle it into a longchar variable you've chosen your message encoding  at the application layer instead of at the transport layer.  You can no longer change it.  You want XML?  That's a new parameter to request XML. Ignore the "efficiency" arguments for the moment.  You still haven't transported it yet, you have merely changed the encoding from say "object" to "string".

    So for future proof you need a technology (read: transport) neutral solution that doesn't burn the message encoding into the application layer, allows easy additions of new name-value pairs so API signatures don't have to change (read: the .p running on the appserver), and allows for new future encodings.

    The choice is based on the technologies and future technologies in play.  If you'll never use open client, and always use OOABL (for the moment), then objects are a first place choice.  Or you can bet in the future that additional OOABL serialization options become available to support those other transports.  If you are using/going open client, or REST adapter, then and you need it now, then this isn't a good choice.

    Stop receiving emails on this subject.

    Flag this post as spam/abuse.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • What I dislike about passing TT's across the AppServer boundary is the coupling it creates between subsystems.  A TT is a very specific implementation.  The JSON corresponding to that implementation is just a message ... a message which seems to be understood by all current technologies in a native way.  Put the translation in an interface layer, if you wish.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Why can’t you create decoupled systems using temp-tables? Why is a TT a very specific implementation and a JSON string not? Why can’t a temp-table not be just a message?

    Gesendet von Windows Mail

    Von: Thomas Mercer-Hursh
    Gesendet: ‎Donnerstag‎, ‎9‎. ‎April‎ ‎2015 ‎20‎:‎15
    An: TU.OE.Development@community.progress.com

    Reply by Thomas Mercer-Hursh

    What I dislike about passing TT's across the AppServer boundary is the coupling it creates between subsystems.  A TT is a very specific implementation.  The JSON corresponding to that implementation is just a message ... a message which seems to be understood by all current technologies in a native way.  Put the translation in an interface layer, if you wish.

    Stop receiving emails on this subject.

    Flag this post as spam/abuse.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Because a TT is a very specific ABL implementation whose definition has to be shared by both ends of the communication.  A JSON string is just a string.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • But a JSON string without agreement on the content/structure is pointless.
     
    Temp-Tables can also be passed dynamically. With random schema.
     
    I don’t get your point!

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Naturally, both ends have to agree on message format or meaning or the message would make no sense.  The point is that a JSON string is physically just a string and the interpretation of that string makes no assumption about technology, structures, anything.  Whereas, a TT is a very specific ABL implementation artifact which has to be translated into a very specific implementation artifact in the target language.  That is strong coupling at the level of implementation.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • And – I repeat my questions from an earlier response  - which target system that can communicate with the AppServer has a problem with Temp-Tables?

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.