According to the Floorplan Manager for Web Dynpro ABAP Developer's Guide since at least version 7.0 EHP3, the Object Instance Floorplan (OIF) 'has been superseded by the Overview Page (OVP) floorplan' and it provides the additional recommendation that 'all new applications for object instances should be built using the OVP floorplan'.
I'm fairly new to OIF as it is and am about to start work on a large FPM application that will display various dynamic tables, text fields and input sections. Should I forget about OIF entirely and create an OVP application?
Are there certain caveats I should be aware of before beginning with OVP?
Or is creating an OIF application ill-advised considering the technology is now deprecated?
Related
I am redesigning a Reman service, which currently exists as a thick client application that receives SAP Optimization Jobs (from SAP), calculates the best way to optimize product use (Optimizer) and display the best optimization on the client. They can either edit or submit the optimization back to SAP
I am trying to create a SAPUI5 application that either:
Reaches out to an external web server to run a small application (Optimizer) and returns the data back to the UI5 application.
or
Load the third party dll into SAP UI5 and call the Optimizer that way.
Is this possible? Can you use third party dlls in UI5?
SAPUI5 - as the name says - is a UI framework. From your description, I understand that you're trying to pull business/processing logic into the UI. This is usually considered a bad idea. You should rather put the business logic (i. e. your optimizer) into a server-side component (anything that would ideally provide OData services) and use UI5 to create a front-end for that.
It appears that in both solutions you proposed, the business logic is on the server, which is a good practice.
Although it isn't impossible to call a DLL from Javascript, it isn't a very good idea, because there is no possibility to make this browser-independent. There may even be incompatibilities between various versions of the same browser when calling DLLs.
It would by far be the preferred way to call the optimizer webservice from the UI5 application. In fact, UI5 is completely designed to facilitate calling web-services and provides various components that will help you to make the actual call and bind the returned data to user-interface controls.
it is possible as long you have the dll registered in the machine which is running the UI5 Application and you're using JScript for such.
I'm working with my team on the "core" domain of our job, we have several DBs, Webservices, importer, etc... We expose the domain services to other teams through a backend WCF webservice. This webservice is cut in several api (or areas).
We deploy this on several production server (~ 80) (1 server <-> 1 customer).
Problem is: Some api goes public and we must maintain the same contract throught many releases. Others team want more flexibility (3 internal api contract version) as they can't follow our delivery rate (longer cycle)
Actually we are only serving this as a whole, and we are using a classic three branch branching (DEV/MAIN/RELEASE'n')
I'm trying to upgrade my TFS Team collection organization to handle a defined version range of each API version:
API Foo v2 (hxxp://-host-/api/foo/v2/...)
API Foo v3 (hxxp://-host-/api/foo/v3/...)
API Bar v1 (hxxp://-host-/api/bar/v1/...)
API Bar v2 (hxxp://-host-/api/bar/v2/...)
Currently we have the following branching schema:
$\MyTeamCollection
|___\DEV {Branch}
|___\Databases
|___\MyDBProj (SSDT)
|___\Documents
|___\MyWebService\MyWebSvc.Usage.docx
|___\Projects
|___\MyWebService.Core
|___\MyWebService.API.Bar
|___\MyWebService.API.Foo
|___\Shared
|___\MyDB\MyDB.DacPac, etc...
|___\MyWebService\MyWebsvc.Bar.Contract.Dll <-- WCF DataContract/ServiceContract
|___\MyWebService\MyWebsvc.Foo.Contract.Dll
|___\MAIN {Branch} <-- This one is what is on the integration server
|___\R1 {Branch} <-- This one went on a production server and is kept aside
|___\R2 {Branch}
|___\Archive
|___\R0 {Branch} <-- This one is obsolete but is archived here
Actually it handles a group of single api versioning. => Each release ship with a set of latest api version (Foo, Bar)
My question is how can I evolve this to handle multiple Api Version in each release (Foo-v1, Foo-v2, bar-v3, bar-v4)
Should i create branch inside branch? Won't this be a nightmare?
Any actual working teamcollection organization on your side?
Thanks,
-Jeremy.
Some additions:
All my clients are .Net, we provide them the assembly named MyWebsvc.Foo.Contract.Dll. This assembly contains:
ServiceContract interface which is implemented by a proxy pattern
[ServiceContract]
public interface IFooService {
Foo Get(int Id);
}
And all data contract needed (DTO + Serialization)
[DataContract]
public class Foo {
// ...
}
On the web service side there is the actual implementation
public class FooServiceImpl : FooApi.IFooService { ... }
For the purpose of this answer, I imagine that you have thoroughly reviewed the abundance of version control branching and merging guidance available online. As such, I suspect that the answer may not be found in “more” version control, but rather in a modest shift in the way features are enabled and available for customer use. Therefore, you may find that implementing a feature toggle solution will reduce the number of release versions that you need to maintain. The following article by Martin Fowler provides a good overview of feature toggles.
http://martinfowler.com/bliki/FeatureToggle.html
Our development team has utilized the concept of feature toggles, in our self-hosted WCF Windows Services, to provide a fully configurable set of endpoints that can be enabled/disabled (and adjusted) via configuration. In such scenarios, we typically utilize the customers’ data repository (database, ldap, etc) to store the configuration values and toggle switches, then when the service runs, it searches the repository for the configuration and then sets up and enables the interfaces in the manner the customer needs/wants.
Hope this helps.
Regards.
Jeremy,
there are a few questions you need to consider.
a) are your clients .Net as well or can they be in any technology? WCF has a really nice "compatible" versioning mechanism, but unfortunately it's non standard and only works with .Net clients
b) do you have the ability to give some guidance as to how the clients consume the services?
The only way to keep this problem under control is to adopt a "compatible" versioning strategy. As you pointed out, you want to have several (max 3) major releases in production and each time you evolve one or more major release you want to create a compatible (minor) version such that there is always one and only one release for each major version of the service running.
From a TFS perspective, I would consider each major version independent from each other, as in essence, they are somewhat independent services. I understand that creates a bit more work since you could have some update that applies to more than one major release, but IMHO, it's not worth the trouble to try to optimize that, unless you are actively working on all major versions simultaneously.
Achieving "compatibility" from one version to the next is not that hard, there are number of guidelines you want to follow both on the service side and the client side. I co-authored this article way back in 2008. http://www.infoq.com/articles/contract-versioning-comp2
I also wrote that blog post recently specifically for HTTP based APIs: http://www.ebpml.org/blog2/index.php/2013/04/13/formalizing-the-api-style
I want to emphasize that it's generally a good idea to use a minor version that is provided by the client to indicate which version of the service was in effect when it was built. The reason for that is that you can handle small breaking changes in a compatible way by knowing which minor version of the service it is compatible with. You still have a single release per major version and the variants are directly handled by the latest (minor) version of the service.
Versioning is key to a healthy API that allows clients to upgrade on their own terms (risk, budget, resources,...) and to the best of my knowledge, a "compatible versioning" strategy is the one that works best.
At work (bank) we are re-designing our MW / Web services. We are using bottom-up approach to build those services. We are using Java, jax-ws. So I need to create rules to be followed. So I have 2 questions so far:
Should we create types to our objects fields, i.e. in class Client, should we create a CellPhone object or use simply string for that. I can see the pros & cons , object will be become heavy weight, but easy to validate & control.
Any other ideas ?
Should we be using SOAP built-in fault or create our own error status code (maybe in the SOAP header). I really like the SOAP fault because of the direct mapping to Java Exception.
Thanks in advance
Some answers:
1. Bare in mind that Web Services (I assume you're talking about SOAP-based WS, as you mentioned jax-ws and not jax-rs) use SOAP which is an XML based protocol.
2. For every class you create, you will have a type in your WSDL file.
3. The SOAP envelope (which holds the "body" of your message will also hold additional XML element to denote the cellphone - you're creating more traffic.
To conclude 1 - 3 and the fact you're talking about CellPhone, I don't understand why you need to have class for this.
Are you taking about a CellPhoen class that actually models a CellPhone (i.e - the cell-phone device, with properties like "vendor", "operator" ,etc..) or are you talking about the cell phone number? If this is just Cell-Phone number, then my recommendation, based on 1-3 is still valid.
To handle validation:
You can use many validator fameworks in order to validate phone number.
There is even a JSR in Java for validation.
I recommend you to look at here to read about the Hibernate-Validator framework which conforms to JSR 303.
You can also download the source of oVirt open source project ,
and take a look at oVirt-engine (look at ovirt-engine/backend/manager/modules/common) at our BusinessEntiies and see some "real life" examples on how to use these validators.
Regarding fault - you can create your own Faults, and map them to Java exceptions, I see no harm there.
I was thinking about the architecture of a web application that I am planning on building and I found myself thinking a lot about a core part of the application. Since I will want to create, for example, an android application to access it, I was already thinking about having an API.
Given the fact that I will want to have an external API to my application from day one, is it a good idea to use that API as an interface between the interface layer (web) and the business layer of my application? This means that even the main interface of my application would access the data through the API. What are the downsides of this approach? performance?
In more general terms, if one is building a web application that is likely to need to be accessed in different ways, is it a good architectural design to have an API (web service) as the interface between the interface layer and business layer? Is REST a good "tool" for that?
Sounds like you've got two questions there, so my answer is in two parts.
Firstly, should you use an API between the interface layer and the business layer? This is certainly a valid approach, one that I'm using in my current project, but you'll have to decide on the benefits yourself, because only you know your project. Possibly the largest factor to consider is whether there will be enough different clients accessing the business layer to justify the extra development effort in developing an API? Often that simply means more than 1 client, as the benefits of having an API will be evident when you come to release changes or bug fixes. Also consider the added complexity, the extra code maintenance overhead and any benefits that might come from separating the interface and business layers such as increased testability.
Secondly, if you implement an API, should you use REST? REST is an architecture, which says as much about how the remainder of your application is developed as it does the API. It's no good defining resources at the API level that don't translate to the Business Layer. Rest tends to be a good approach when you want lots of people to be able to develop against your API (like NetFlix for example). In the case of my current project, we've gone for XML over HTTP, because we don't need the benefits that Rest generally offers (or SOAP for that matter).
In general, the rule of thumb is to implement the simplest solution that works, and without coding yourself into a corner, develop for today's requirements, not tomorrow's.
Chris
You will definitely need need a Web Service layer if you're going to be accessing it from a native client over the Internet.
There are obviously many approaches and solutions to achieve this however I consider the correct architectural guideline to follow is to have a well-defined Service Interface on the Server which is accessed by the Gateway on the client. You would then use POCO DTO's (Plain old DTO's) to communicate between the endpoints. The DTO's main purpose is to provide optimal representation of your web service over the wire, it also allows you to avoid having to deal with serialization as it should be handled transparently by the Client Gateway and Service Interface libraries.
It really depends on how to big your project / app is whether or not you want want to go through the effort to mapping your DTO's to the client and server domain models. For large applications the general approach would be on the client to map your DTO's to your UI Models and have your UI Views bind to that. On the server you would map your DTO's to your domain models and depending on the implementation of the service persist that.
REST is an architectural pattern which for small projects I consider an additional overhead/complexity as it is not as good programattic fit compared to RPC / Document Centric web services. In not so many words the general idea of REST is to develop your services around resources. These resources can have multiple representations which your web service should provide depending on the preferred Content-Type indicated by your HTTP Client (i.e. in the HTTP ACCEPT HEADER). The canonical urls for your web services should also be logically formed (e.g. /customers/reports/1 as opposed to /GetCustomerReports?Id=1) and your web services would ideally return the list of 'valid states your client can enter' with each response. Basically REST is a nice approach promoting a loosely-coupled architecture and re-use however requires more effort to 'adhere' to than standard RPC/Document based web services whose benefits are unlikely to be visible in small projects.
If you're still evaluating what web service technology you should use, you may want to consider using my open source web framework as it is optimized for this task. The DTO's that you use to define your web services interface with can be re-used on the client (which is not normally the case) to provide a strongly-typed interface where all the serialization is taken for you. It also has the added benefit of enabling each web service you create to be called by SOAP 1.1/1.2, XML and JSON web services automatically without any extra configuration so you can choose the most optimal end point for every client scenario, i.e. Native Desktop or Web App, etc.
My recent preference, which is based on J2EE6, is to implement the business logic in session beans and then add SOAP and RESTful web services as needed. It's very simple to add the glue to implement the web services around those session beans. That way I can provide the service that makes the most sense for a particular user application.
We've had good luck doing something like this on a project. Our web services mainly do standard content management, with a high proportion of reads (GET) to writes (PUT, POST, DELETE). So if your logic layer is similar, this is a very reasonable approach to consider.
In one case, we have a video player app on Android (Motorola Droid, Droid 2, Droid X, ...) which is supported by a set of REST web services off in the cloud. These expose a catalog of video on demand content, enable video session setup and tear-down, handle bookmarking, and so on. REST worked out very well for this.
For us one of the key advantages of REST is scalability: since RESTful GET responses may be cached in the HTTP infrastructure, many more clients can be served from the same web application.
But REST doesn't seem to fit some kinds of business logic very well. For instance in one case I wrapped a daily maintenance operation behind a web service API. It wasn't obvious what verb to use, since this operation read data from a remote source, used it to do a lot of creates and updates to a local database, then did deletes of old data, then went off and told an external system to do stuff. So I settled on making this a POST, making this part of the API non-RESTful. Even so, by having a web services layer on top of this operation, we can run the daily script on a timer, run it in response to some external event, and/or have it run as part of a higher level workflow.
Since you're using Android, take a look at the Java Restlet Framework. There's a Restlet edition supporting Android. The director of engineering at Overstock.com raved about it to me a few years ago, and everything he told us was true, it's a phenomenally well-done framework that makes things easy.
Sure, REST could be used for that. But first ask yourself, does it make sense? REST is a tool like any other, and while a good one, not always the best hammer for every nail. The advantage of building this interface RESTfully is that, IMO, it will make it easier in the future to create other uses for this data - maybe something you haven't thought of yet. If you decide to go with a REST API your next question is, what language will it speak? I've found AtomPub to be a great way for processes/applications to exchange info - and it's very extensible so you can add a lot of custom metadata and yet still be eaily parsed with any Atom libraries. Microsoft uses AtomPub in it's cloud [Azure] platform to talk between the data producers and consumers. Just a thought.
For a project I have to implement a communication between a database hosted on a web server and several clients out there in the internet.
After reading a bit and watching a few introductory videos about possible (Microsoft) technologies I figured out that I seem to have (at least) three options:
1) Windows Communication Foundation (WCF)
2) ASP.NET Web services
3) ADO.NET Data services
Because I am not familiar with any of those three technologies I have to learn (hopefully only) one of them in depth - and the question is: Which one?
Or to be more precise: Which one for the following task?
Data need to be uploaded from a client to the server/database and some other data need to be downloaded as well. On client side this will not happen interactively by an user who works in a browser but rather as an automatic process on the client which will run periodicly (every 2 hours for instance).
a) On web server side there will be:
A SQL Server database
.NET Framework 3.5 SP1
A class library representing the database structure and modeled with ADO.NET Entity Framework
(An ASP.NET web application which will present the data in the database in a browser: I put this in brackets here because this web application doesn't really matter since the mentioned data up/download won't be triggered through a browser GUI.)
b) The client side is less clear and must be more flexible. Here I have to distinguish between two requirements:
i) Priority One (in terms of the time I have available for development):
The client side is under my control, it means: I have any Windows OS on the client, I can install .NET Framework and I can decide to develop a Windows service, a Console Application, a Windows Forms application or whatever. And I have knowledge about and access to the class library mentioned above.
ii) Lower Priority, but must be a future option:
I need to expose any kind of interface description which allows other developers to build their own applications to upload/download data.
The clients which others will develop for can be operated with any kind of OS (Windows, UNIX, MacOS and more). Also they shall be as free as possible to select their own prefered programming language.
Due to the last point forcing developers to use the .NET Framework on client side is not an option. The communication on client side must be any kind of "standard" technology accessible from various platforms and languages. I was reading terms like "SOAP", "REST" or "AtomPub" during my little research and these seem to be a kind of standard protocol or communication technology (not a proprietary Microsoft invention). But I am not sure nor do I know which technology is "up to date", has the "best future", is most common and well known, is the most powerful or is the easiest to use (from a viewpoint of those other possible developers! So the question is what I have to support to make most client side developers happy).
One last point: Security is important! Uploading/Downloading data must be restricted to dedicated persons. It should not be possible to use or explore the interface without appropriate credentials.
What technology is the best to use now? (1), (2) or (3)? And why would you recommend it?
Thank you very much in advance for any advice!
Well, no. (2) old-style ASP.NET webservices is on its way out - it's old, no longer being developed - it's been replaced by WCF.
So this leaves options 1 (straight WCF) and 3 (ADO.NET Data Services - renamed WCF Data Services recently).
Both use WCF as their basic technology - so learning and knowing about WCF is a must in both cases.
With straight WCF (Option 1) you have more options - you can self-host, host your service in IIS, use different protocols and bindings and so on. But with choice comes complexity - you need to learn and know all that stuff - at least to some degree. Your client needs to be able to talk SOAP to you - just about any language (.NET of course, Java, Ruby, PHP - you name it) can talk SOAP in one way or another.
If you're mostly interested in exposing data from databases onto outside clients, I think WCF Data Services is indeed quite a good choice. It's based on REST, so you can hit your WCF Data Service with a browser and just see what happens. It's quite powerful, and even offer a LINQ client side support - you formulate a LINQ query and this gets translated into your appropriate REST call to your data service.
With WCF Data Services, your client needs nothing but a HTTP stack - even the iPhone has that :-) But with a .NET client, things are of course nicer and more comfortable and more efficient.
I'd say check out the WCF Data Service first and see if that satisfies your needs - and if not, dig deeper into WCF. Also check out WCF Data Service at a glance for an intro.
UPDATE:
Marc, do I understand you correctly
that WCF on the server fulfils this
requirement? And ADO.NET (WCF) Data
services too?
Absolutely. WCF (plain or with Data Services) on the server side does NOT dictate the client in any way, shape or form. You can hook up an iPhone to a WCF Data Service, if you really feel like it :-) WCF has been designed from the ground up to be very interoperable - actually, it's the one platform out there that implements the most WS-* industry standards for cross-platform communications.