If you have defined a soap or rest service within your GeneXus 16u5 Knowledge Base, can you then create an external object for that service and invoke it from within the same KB?
I seem to remember in the past that this was not possible. If it is still the case, is it because of the tools that generate the external object?
Sure you can, it's not common but you have to be careful with the externals objects names. To avoid errors during the WSDL import, in the second step you've to:
1- Change the name of the "External Name Object" to something different of the "internal" object.
2- Keep or put something in the Prefix box. If you leave it blank, a conflict with the "internal" SDT will occur.
Regarding REST, I always consume them in a manually way, so I guess there would be no problem doing it that way.
Related
I am currently working on moving our rest api based go service to gRPC, using protobuf. it's a huge service with a lot of APIs and already in production so i don't want to make so many changes to ruin the existing system.
So i want to use my go models as source of truth, and to generate .proto messages i think i can manage with this - Generate proto file from golang struct
Now my APIs also expect the request and response according to the defined go models, i will change them to use the .proto models for request and response. but when request/response is passed i want to wrap them in my go models and then the rest of the code doesn't need any changes.
In that case if the request is small i can simply copy all the fields in my go model but in case of big requests or nested models it's a big problem.
1) Am i doing this right way ?
2) No, what's the right way ?
3) Yes, how i can copy the big proto messages to go model and vice-versa for response ?
If you want to use the go models as the source of truth, why you do want to use the .proto generated ones for the REST request/response? Is it because you'd like to use proteus service generation (and share the code between REST and gRPC)?
Usually, if you wanted to migrate from REST to gRPC, the most common way probably would be to use grpc-gateway (note that since around 1.10.x you can use it in-process without resorting to the reverse proxy), but this would be "gRPC-first", where you derive REST from that, while it seems you want "REST- first", since you have your REST APIs already in production. In fact for this reason grpc-gateway probably wouldn't be totally suitable, because it could generate slightly different endpoints from your existing ones. It depends on how much can you afford to break backward compatibility (maybe you could generate a "v2" set of APIs and keep the old "v1" around for a little while, giving time to existing clients to migrate).
I have a problem. I am creating a webAPI with ASP.NET MVC, I've got three different projects with three separate databases.
I have a method to do an Insert in one table. That table exists in three databases.
The client sends me the project in a String.
My question is:
1 - Should I divide the webAPI in three different URLS?
2- I don't want to create a switch or if-elseif in the controller this way:
switch (project) {
case project1:
objectdatabase1
case project2:
objectdatabase2
case project3
objectdatabase3
}
Because I think it breaks the OPEN CLOSED Solid principle.
3- Also I would like to inject de database object into de controller with Unity doing dependency injection.
Any ideas to do these in the best way possible?
Thank you!
Depending on what you are using to connect to those databases you might be able to just use named connectionStrings. Name them like the projects (whatever string the client sends) or have some convention (like param+"_connString").
Then have your DB access object open a connection using that particular connectionString and run whatever query you want.
Using specialized naming convention (like Project1_SomeKeyword_connectionString, Project2_SomeKeyword_connectionString etc.) just for this case will limit the potential security problems, in case someone would maliciously try and guess connectionString name that should not be used for that purpose (for your internal db or whatever).
If you are using plain SQL access object that will run whatever query you ask it to, it will be fine. If you are using some ORM that depends on a particular table-object mapping, you might need to create that ORM just for this purpose, if the rest of DB differs.
You were also mentioning that you might want to inject the database object. But wouldn't injection take place before the controller actions are being executed? That would mean that you must know which DB you are using beforehand, and you've said that the project name is provided during action call. You might need to inspect the request during injection and it makes it all kind of complicated.
How about create several EntityFramework models? So each model will connect to a different database.
I am developing a web service that will be invoked (using JSON) from client side each time the selection of a drop down changes.
The goal is to register each "intermediate" change (on client side) using the "OnSelectedIndexChanged" event and before submitting the form to the Server.
Each new selected value will be written to a shared txt file calling a relative web method via Ajax/JSON.
Would it be better to write these changes to a txt file (having to implement a lock/unlock policy to assure exclusive access) or rather define a DB table and save the changes there?
Everyday the web app will have around 10 to 20 active users that might potentially changes the DropDownLists and usually the right value will be selected at first, hence generally no more than one "intermediate" entry would be registered.
Thanks.
Don't use the filesystem. It's slow. Use mongodb via a node.js webserver.
http://howtonode.org/express-mongodb
Good Luck!
This sounds exactly like what you would want to use a database for, since ACID is already implemented there.
If you want a real headache (and a programming challenge!) trying to debug overlapping writes, resource starvation and deadlocks, by all means, go with a shared text file!
I have a WCF service with a namespace called:
MyCompany.MyApplication.Configuration.ConfigurationHelperService
On the client side I have an assembly called which consumes this service:
MyCompany.MyApplication.Core (this is the default namespace)
When I add the service reference, the namespace I'm asked to specify in the Add Service Reference dialogue ends up getting tacked on the end of the client assembly namespace:
MyCompany.MyApplication.Core.MyCompany.MyApplication.Configuration
.ConfigurationHelperService
Because I'm asked for a namespace at this time it seems natural to specify the name of the remote service namespace. i.e. I'd like to refer to my remote service classes using their namespace MyCompany.MyApplication.Configuration.ConfigurationHelperService because they're technically not part of the client.
My questions are:
What's the rationale behind this, is this something to do with semantics?
Should I try to resist changing this behaviour by modifying the client side generated source to get the namespace I want?
I've lived with this for a long time (you have the same problem with ASMX web service clients) but have never seen a written down explanation why Visual Studio (and I guess svcutil.exe) works this way.
Well, I think you have two choices, really:
if you control both ends of the wire, e.g. you write the server and the client, you could put all the shared items like service contracts, data contracts etc. into a separate assembly and share that between client and server. That way, nothing would be duplicated, and both ends of the communication would refer to the exactly identical items in a given namespace of your choice
get used to the fact that if you add a WCF service reference in Visual Studio, you're basically getting a whole slew of duplication - because if you're not controlling both ends of the communication, that's really all WCF can go on - the metadata exchanged between service and client (through the WSDL or the MEX endpoint on the service). And since this clearly is part of the client, which is completely separate from the service (all they share, typically, are the wire-formats defined in the XML schema - nothing else), its namespace will also be client-oriented. I think this is a (good) feature, and not something I'd try to combat.....
By default, in a SOA world using WCF, the client and the service are totally independant of one another. There's no "remote object" connection or anything like that between the two: the client proxy has a method call happen, bundles up those parameters passed in plus some information what method on the server to call, and serializes it all up into a serialized message (read: a text / XML message, basically). That message is sent across the wire to the server which then handles that message and returns a response.
So this is not just a .NET function call or something - those two pieces of your system are (by default) absolutely independent of one another. Considering that, to me at least, it makes sense that everything the client does will be placed in the client's namespaces - after all, the server could be something totally different, like Java, PHP, a IBM mainframe - you typically don't have any clue what it is (and don't need to).
What parts of your application are not coded?
I think one of the most obvious examples would be DB credentials - it's considered bad to have them hard coded. And in most of situations it is easy to decide if you want something to be externalized or coded.For me the rules are simple. Some part of the application should be externalized if:
it can and should be changed by non-developer, but not so often to be included in application settings defined in UI (DB credentials, service URLs, etc)
it does not require programming language and seems unnatural being coded (localization)
Do you have anything to add?
This is a little related to this question about spring cfg.
Spring configuration seems less obvious example for me, because in my practice it is never modified by anyone except the developer. And the road of externalizing can take you far away, to the entire project being "configured", not coded - so where to stop?
So please post here some examples from your experience, when you got benefit from having something configured, not coded - like dependency injection configuration in spring, etc.
And if you use spring - how often is configuration changed without recompiling?
Anything that needs to differ between different deployments of your application. That is, anything specific to the environment.
Examples include:
Database connection strings
URLs for web or WCF services
Logging configuration
Any information your application uses that is "data" and that could change depending on where it is installed. Things like:
smtp mail server used to send e-mails
Database connect strings
Paths to file locations / folders used by the app
FTP servers & connect info
Active Directory servers used for authentication
Any links displayed in the application to external information
sources
Warning limit values
I've even put the RegEx filters used to limit the allowable characters
for data entry fields.
Besides the obvious changing stuff (paths, servers, ports, and so on), some people argue that you should be able to easily change whatever might reasonably change, for instance, say you have a generic engine which operates on the business logic (a rule engine).
You would then define the rules on a "configuration file" which ends up being is no less than programming in a DSL instead of in the generic purpose language. Benefits being it's closer to the domain so it's easier and more maintainable, and that you can easily change things that otherwise would demand a new build.
The main argument behind this is that things you assumed would never change always end up changing nonetheless, so you better be prepared.
paths and server names/addresses come to mind..
I agree with your two conditions, which is why I:
Rarely include a config file as part of a Windows or Windows Mobile application (web apps yes).
If I did include a config file meant to be tweaked by end users, it certainly wouldn't be XML.
Employee emails/names since employees can come and go... (you should typically try to keep them out of an application though)
Configuration files should include:
deployment details
DB credentials
file paths
host names
anything that is used in many places but that may change
contact email addresses
options that aren't in the GUI
The last one is a bit open-ended, but very important. I've found it very useful to foresee variables that the client may, in the future, want to change. If changes are infrequent, I or they can edit the config file. If it becomes a frequent thing, it's trivial to add the option to the GUI, which isn't hardcoded.
I would also add encryption keys (which themselves should be encrypted)...
Basically the rule of thumb is information the application needs BEFORE it's regular, functional operation, data that it MUST have on-hand (i.e. local and not networked).
Note that this data should not be dynamically changing or large amounts of it, otherwise it should be in the database.
With Spring apps I actually distinguish between two types of configuration:
Items externalized into property files which are "deploy time" concerns or "environment-specific": server IP's / addresses, file system locations, etc etc
Spring XML configuration which can do lots of things, like indicate the overall application structure, apply behavior via AOP, etc.
I use Spring to wire all the beans in a J2SE application that has no GUI (a transactional switch). That way it's very easy for me to have different configurations in each deployment (we have this thing running in different countries), without having to code anything different.
Another thing I like to have is to manage all the SQL statements separately from the code, when I use plain JDBC (or Spring JDBC). Like in a properties file or XML or something, sometimes even as String properties in the beans that will use the statement (when there is only one bean that will use the statement, such as a DAO).
I am going to use spring JDBC or vanilla JDBC for data persistence, here we have decided to externalize all the SQL from the Java code, so can be better mangable in terms of SQL query tuning and optimization, we don't need to disturb the java code.