Hi,
Due to the discussion about powerEXT in this forum, here is a little
clarification on some of the discussed matters:
powerEXT use of CGIDEV2
powerEXT uses 7 subprocedures from CGIDEV2 in its basic api (PXAPICGI).
This is only one out of eight powerEXT API's that adresses the following
mainareas:
- Http connection and productivity tools (PXAPICGI that uses CGIDEV2
subprocedures)
- Environment and Security Management (User's, Sessions and Request
control)
- Central Metadata Model, that stores any information about fields,
functions, menues and screendesigns (menu's, grid's and form's)
- EXT JS JSON Generators for dynamic menu, grid and form configurations
- Database Connectors RPC's (Remote Procedure Call)
powerEXT implementation of CGIDEV2 is modified in the following main areas
- True CCSID support when writing streamfiles (written by Scott Klement)
- Enhanced debug facilities
- Support for CGIDEV2 Buffer Address and Buffer Length
The basic powerEXT API's may run concurrently with build in CGIDEV2
version within a program sharing the serviceprogram and outputbuffer.
powerEXT security and session management
powerEXT offers a complete and one of the best serverside side security
and session management on the marked. The system is proven and comes from
powerEXT's predecessor WAY2TRADE developed in 2001 and revised several
times by major heavy security companies and has, by the way, never been
broken.
The security is based on two 32 bytes randomgenerated keys that are
generated for every possible program call and stored on the server and
checked every time a program is called.
The system can hold session variables in several layers ... general on the
session or to a specific request to a specific program so it is impossible
to switch customer number eg. by tampering with the browsers DOM during a
session.
For at further description - see the documentation for the API.
And yes, powerEXT runs stateless (nonpersistent) on the server, this for a
good reason - EXT JS uses AJAX where a single page can fire from 1-20 hits
back to the server simultaniusly (bacause AJAX is asyncrone) - with 1000
concurrent users this means in worst case 20.000 jobs under the apache
server, so both holding state or running under Apache OS/i security gives
a devastating performance problem.
powerEXT processes
powerEXT introduces generic processes, "a configurable program code that
is specially made for a common task".
We have a number of generic processes already in 5250, take a Work With
function - if stripped in the RPG and DDS code for file specific fields we
end up with some code that is identical from program to program.
The OPM used in both 5250, CGIDEV2, PHP and .NET is to make Function A,
then copy it to Function B, then copy it to Function C etc. eventually
ending up with hundres of program that in basic's holds the same code and
in the same time making change management very difficult.
Actually, in a modernization perspective, it is a bit like making 100
dishes with spaghetti mixed with ketchup and then try to divide the
spaghetti from the ketchup in order to replace the spaghetti with
macaroni.
powerEXT has solved this by introducing generic configurable processes,
the Central Metadata Model and XML based configuration objects, so you
will not find a lot of HTML or JS files, the entire system runs in one
single generic HTML page and three generic processes - one for Menu's
(Viewport), one for Work With functions (Grid/Form) and one for Form
Submit functions (Form).
The Structure of the stack code loaded are:
< powerEXT Generic HTML Container >
< EXT JS UI Components >
< EXT JS User Extensions (ux) >
< powerEXT Generic Processor >
< powerEXT Configurations >
All configuration of this processes is done based on simple design XML
templates and API's that based on the XML configuration mixes Metadata
from the Central Metadata Model with predefined generic EXT JS templates.
Because of this structure common programs becomes very simple to write
(<100 RPGLE stmt) and dosn't require javascript/EXT JS skills, a common
Work With function is written in a matter of minutes and 95% of a
modernization process is done within weeks.
Besides that and because of the EXT JS API layer in powerEXT is a seperate
layer from the rest of the system, this layer can be rewritten if or when
the next technology hype comes along this by just extending the system and
without loosing or having to convert the real values of a system hidden in
the Central Metadata Model.
powerEXT node support
powerEXT has node and encoding support for generating HTML, XML, JSON, CSV
and javascript. powerEXT provides a generic efficient way of doing nodes
without templates to both CGIDEV2 and HTTPAPI and extends HTTPAPI with
CGIDEV2's "ILOB" facility.
Most of the node support is used in the API's and the RPC's (Remote
Procedure Calls) that is autogenerated and handles all RDBS I/O so the
need for node support is only actual if you has to make specific files.
The node support has another important feature, the ability to either
produce tabulated code for readability and compress code for performance.
The node support is constructed based on cooporation with LEAN experts and
analizies of lots of coding examples posted in CGIDEV2 and HTTPAPI. A LEAN
project means focus on long term efficiency of repeatly done processes and
covers areas as number of characters written, readability, redundancy,
human process time etc.
- to give a little example: JSON nodes are separated by a ",", should it
be in front of the line or after a line ? Timestudies shows that the human
brain processes (read) code 3-4 times faster if the "," is in front of a
line instead of in the end! A small detail, but if you have to read JSON
in 600 hours in a 5 years period you can save aprox 350-450 hours.
powerEXT Database Connection via RPC's (Remote Procedure Calls)
In a normal powerEXT program there is no DB I/O, only references to RPC's
that is dedicated programs that handles all DB I/O in a similar but
extracted function to the previously mentioned jsoGetRec. The system has
tools to generate a standard RPC per physical file There is however som
big differencies:
A standard powerEXT RPC program is a SQLRPGLE program that are generated
based on a DSPFFD. But because powerEXT has a Central Metadata Model the
program generated will contain %BIF's specified in the Central Metadata
Model to handle special functionallity such as different date and time
formats, date and times in numeric fields, initialization of fields,
update counter control etc. etc. and in the same time it facilitates
server side paging and searching, primary search field and direction etc.
Internally the RPC's always runs in *ISO date/time formats and with
decimal char ".". Conversion in the EXT JS userinterface is done according
to parameters on the selected language group and by s number of EXT.UX's
in the client.
Because the RPC's is straight forward programs they can be modified to
make special selection and even to make I18N translations of referential
data and they can be reused so one program can cover any combobox
searchfacility in any screen by just defining a field in the Central
Metadata Model as a "Remote Combo Box" and then pointing to the RPC, this
without coding a single statement.
The RPC's is furthermode technology independent, so it can be used in any
AJAX call in any UI and because it's not a "blackbox" it can both be
modified in the sql (join other files) or by traditional RPGLE code (CHAIN
etc) as weel as fields can be omitted or computed.
The RPC is as standard able to output data as HTML table, XML document or
JSON object and due to modifications in the getExtVar fields there may be
omitted in the Input Form are defaulted back to the origin value without
any special coding or without any need to know wich fields that are
dynamically placed in the form by the user design, that is allowed to
update data.
powerEXT project status
Currently I have 4 project running in Denmark, one modernization of aprox.
150 programs and 3 new applications. This bring hard needed butter on the
bread after 1 1/2 year of development, but it also ensures the the final
V1 production system is "ready to roll" so I can concentrate my efforts on
making applications instead of correcting errors.
Currently I'm also in the process of upgrading the EXT JS environment from
version 2.3.0 to 3.1.0 and this is not a simple task because most of the
memorymodel in EXT JS core has changed, but starting out on an old EXT JS
release would be shooting myself in the foot and introduce a change
management task immediatly.
The first production version is now scheduled to come out about february
and in the same time the supportforum will open or rather I will be in
there for support.
powerEXT demo
I have placed a running demo version based on EXT 3.1.0, it can be reached
by the project homepage
http://www.powerEXT.com
Regards
Henrik
midrange.com
