I have asked an SAP PI vendor developer to create a single web service with multiple operations ,where each operation would call an RFC , I am being told it will need to be a single RFC and single operation , is it not possible to have single web service with multiple operations where each operation calls an RFC ?
I'm not a PI or RFC expert, but I believe this is correct. Multiple RFC calls will not be made in the same session. You should build a custom RFC that calls each of the functions you need in turn, so that PI can make a single call.
The simple answer is yes you can. You can develop as many operations as you want for a web service and each calling a separate RFC. For example I have a WebSalesOrder WebService with Create, Change, Confirm operations and of course, each works differently. If you are trying to develop an operation that calls multiple RFCs that is also possible but more complex to develop, you can query Integration processes in PI and you will see one way this is accomplished. Not knowing specifically what you are trying to accomplish I would make sure the requirement is understood and maybe there is something more specific that causes your specific requirement to not be possible.
Later........
Yes it is possible. As of SAP PI 7.1 it is possible to create a service interface with multiple operations and each of these operations can be calling a different RFC in the back-end SAP system.
Related
I have a requirement to publish Siebel inbound web service with only one port, at the same time WS has to receive three different operations.
My WS's are based on workflow.
As I could read in the bookshelf the only one operation is possible to add in the one port of WS based on WF:
https://docs.oracle.com/cd/E14004_01/books/CRMWeb/CRMWeb_Overview12.html
(see p.5)
However I've found vanilla WS that looks as I need:
FinancialAssetService
Could anyone give me some tips how to create such WS?
Is it possible to receive different IO by different operations of this WS?
Thanks in advance!
Well, if your web service provides 3 operations, you must be invoking 3 different workflows, right? (It says so in the page you linked: a workflow corresponds to a single Web service operation). Then, yes, you'll need to define 3 "service ports" in your web service.
However, I don't see why that would be a problem at all. I've never done this myself, but you can define the same endpoint URL and HTTP port for each one of the 3 service ports. The external application consuming your service would never notice any difference.
As for your second question, yes, having 3 different workflows would obviously allow you to choose different integration objects for each operation.
On the other hand, if you only have one workflow and need 3 operations because you want it to accept different input structures, then you might want to rethink your solution. Perhaps create 3 tiny workflows (or a BS with 3 operations) to just transform the data to a common IO (using Siebel data mappings), and then pass it to your existing WF.
I have read a tutorial "web-service-php-mysql-xml-json".
It seems everything is ok. But then why we should use soap for web services?
When building web services you can go two ways:
SOAP
REST
Most people choose the path of less resistance, which is REST. This means simplicity, ease of development, using HTTP the way it's meant to be used, make good use of cache proxies, more human readable results etc.
SOAP on the other end is more heavyweight than REST and is also backed up by a large set of specifications. But because it is more complex (SOAP used to be the acronym for Simple Object Access Protocol – which proved to be... NOT) SOAP is not liked by lots of people.
Both approaches work and both have advantages and disadvantages.
For example, SOAP can make use of any transport protocol not just HTTP(S), SOAP offers more options when security is concerned, SOAP offers reliable messaging etc etc. REST on the other hand permits many different types of data formats, REST allows better support for browsers because of the JSON format, REST has better performance etc etc etc.
I’m not going to go into more details since you can find a lot of comparisons SOAP vs REST on the web. The thing that I want to emphasize is the fact that in some cases one works better than the other and it is up to you to determine and choose which one to implement given your particular case.
EDIT: To answer your question:
why use SOAP or REST? we can have web service without them?
Well, the W3C defines a web service as "a software system designed to support interoperable machine-to-machine interaction over a network".
OK... that's nice for a definition. But this is not the definition for SOAP/REST, this requirement can be successfully thrown at a communication protocol to handle.
So basically you could have a web service using whatever communication protocol you want (even creating your own) as long as is supports the "interoperable machine-to-machine interaction". This also means something else than SOAP or REST (OK... REST is not a protocol, I just use it here as reference to prove my point... so bear with me).
But you create a web service because you want some clients to use your service. And your clients are out there in the wild wild west (i.e. the web :D) and people there speak SOAP/REST. An there you come and say: "We relly don't like SOAP and REST here in our shop, we like stuff like RPC, CORBA and our own unique creation the "Bone Crusher 10000" protocol. If you want to do business with us, you go learn the "Bone Crusher 10000"". And your clients will say (eyebrow raised) "Yeaaaaah righttttt.....".
(I'm assuming here that your protocol won't be something ground shacking that will totally outclass SOAP/REST :D)
So, if you don't use SOAP/REST you will limit your target audience. It's like English for example. I'm not a native English speaker, are you? Well, it does not really matter since we are able to communicate in English. Want to try this in Icelandic? . Will you wait for me while I learn Icelandic, cause that's not my native language either?
As I already said, it is up to you to determine and choose what to implement given your particular case, but if you move away from known technology stacks you throw away what comes with that: lots of experience, resources, tools and communication options.
As a closing example, there's a lot of support for the SOAP protocol today and you can generate clients very easily starting from the WSDL file. And presto... your clients can communicate with your web service. Will it go as easy as this with "Bone Crusher 10000"? If you write the tools, provide the resources, support etc... Yes! But that will cost you time and money to create something that was already invented and is in wide use today.
An important point user159088 mentions in her/his answer is "[...] you can generate clients very easily starting from the WSDL file [...]"!
I'd like to further elaborate on this:
You can use SOAP in conjunction with WSDL which is standardized what means that people who know the standard (WSDL) can learn from it what operations a webservice offers and how data is exchanged.
This knowledge can be used f.e. to create tools that generate type safe binder classes/objects out of the WSDL file. You can make use of those generated classes (to make RPCs) without manually implementing the requests and encoding/parsing of the data that is exchanged.
Whereas for REST there is no standard (like a WSDL schema) on how the exchanged data looks like. As a result you often end up parsing the data on your own.
A second point is that REST works mainly with the HTTP(s) protocol (it is based on it). It uses the CRUD verbs (CREATE/READ/UPDATE/DELETE) of the HTTP(s) protocol. SOAP does not rely on it and can thus be used with other protocols as well.
What exactly is web service composition?
Composition refers to the way something is build, the new term at the moment is mash-up which basically means utilising a variety of different services in a composite application. So that functionality of disparate application can be used in one application.
I think your referring to service granularity - which means how much functionality a service exposes. a coarse grained service will expose a whole process as a consumable unit whereas a fine grained service will expose a specific unit of logic from a larger process. Obviously, it is up to the service architects to determine what granularity of service works best in the given environment.
This also, in a way has to do with the style of SOAP message you are using whether it is RPC style or document and that a service should be atomic and not hold external state. Meaning it does not need to know any more information other than that in the SOAP message to perform its function.
Hope this gives you a good starting point. The trouble with service-orientation is that it differs depending on who you read, but the main points stay the same!
Jon
Some web services which are provided for clients are abstract and composition of some smaller web services and it's called web service composition.
Sometimes there are more than one web service in order to use as the mentioned small web services, so we choose them based on QoS (Quality of Service) and many researches have been done on this subject.
Web service composition involves integration of two or more web service to achieve more added value of business functionality. A work flow composer is responsible of aggregating different web services to act as a single service according to functional requirements as well as QoS constrains. BPEL is one of the popular composers uses XML language to perform service composition. Fine-grained services perform single business task and provides higher flexibility and reusability. However, coarse-grained service involves performing complex business functionality leading to lower flexibility
I’ve been trying to wrap my head around how to expose my domain objects to the client. Whether I’m using a rich client or I’m using the web, I want to use the MVP and repository patterns.
What I’m trying to wrap my head around is how I expose my repository and model, which will be on the server. Is it even possible to expose complex business objects that have state via a web service, or will I have to use a proprietary technology that is not language/platform agnostic, like .Net remoting, EJB, COM+, DCOM, etc?
Some other constraints are that I don’t want to have to keep loading the complex domain object from the database or passing it all over the wire every time I want to do an operation. Some complex logic might be that certain areas of the screen might be disabled or invisible based on the users permissions in combination with the state of the object. Validation and error message information will also need to be displayed to the user. I want to be able to logically call a lot of my domain object operations as if it were running on the same machine.
With the web, you have free rein. You don’t have to expose your objects across service boundaries, so you can make them a rich as you would like. I’m trying to create an N-teir architecture that is rich and works when the client calling the model is on a different machine.
You can expose your domain objects like any other object through REST or web services. I think key is to understand that you will have to expose services that provide business value in a single call, and these do not necessarily map 1:1 to your repositories. So while you on the server may expect a single service call to use multiple repositories and perform various aggregations, the things you expose over any kind of web-service should be more or less complete results. The operations you expose on the service should not expose individual repositories but rather focus on meaningful operations that provide a given business value.
I hope this helps somewhat.
You can use a SOAP formater for .Net remoting,
but the resulting service will probably be hard
to consume as a service, and it will surly be very chatty.
If you want your domain model to be consumed as a service,it should be designed as a service.
As stated in domain driven design, a service is stateless, so it won't expose your objects directly. Your service should expose methods that provides meaningful business operations that will be executed as a single unit.
Usually consider that the model in your client is in a different bounded context because its concerns will be a bit different from the one on the server.
What I’m trying to wrap my head around
is how I expose my repository and
model, which will be on the server. Is
it even possible to expose complex
business objects that have state via a
web service, or will I have to use a
proprietary technology that is not
language/platform agnostic, like .Net
remoting, EJB, COM+, DCOM, etc?
A good domain model is going to be highly behavioral and designed around the problem domain (and your discussions with domain experts), I'd thus argue against designing it to be exposed to remote consumers (in the same way that designing it from the database or GUI first is a bad idea).
Instead I'd look at using a style like REST or messaging and decide on the interface you want to expose and then map to/from the domain. So if you went with REST you'd design your resources and API (URL's, representations, etc.) and then you'd need to fulfill it from the domain model.
If this becomes un-natural then you can always have multiple models, for example mapping a seperate read-only presentation specific model to the same data-source (or which wraps the complex behavioral domain model) is an approach I've used several times.
Some other constraints are that I
don’t want to have to keep loading the
complex domain object from the
database or passing it all over the
wire every time I want to do an
operation
Look at caching in HTTP and supporting multiple representations for a resource, also look at caching within your data-access solution.
Validation and error message
information will also need to be
displayed to the user. I want to be
able to logically call a lot of my
domain object operations as if it were
running on the same machine.
You can either represent this as a resource or more likely look at HTTP status codes and the response bodies you'd want to use in those situations.
a. What are the things I must consider?
b. I have several Stored Procedures being execute by the current application. If I create equivalent methods to execute these procedures, what would be the risk or the challenge.
Architecturally, one thing you must consider in transforming a web app to a web service is that local access to methods and data is not the same as remote access. Remote access should be designed so that invocations are more course-grained and exchange more information at once.
Another thing you would need to think about is what your serialization protocol you will use. For example, SOAP vs a REST-based protocol.
Also, think about security - the security considerations are different between a web application and a web service.
Finally, think about how others will know about your web service (or if they will at all).
One risk is ensuring that your code remain the same.
What I mean by this is that there is a distinct possibility of code duplication in this situation, and as such means that you may inadvertently forget to modify one of the places where the Stored Procedure is used (say if you add a new variable to the stored proc call).
Then you also must consider security. For example, exposing a web service call that provides a list of users to the wild is probably not that good of an idea. you need to plan for how you're going to pass/receive authentication & authorization information.
Managing your code base as Stephen said is going to be a big challenge if you create equivlant methods. Your much better off extrapolating the methods into a new library, that both the web application and web service will use. Your web apps shouldn't have any data access code in them.
With a web service you need to consider your clients. Who is going to access your data and from where. If for example its from a .net windows client on the same network or machine a TCP binding might be best. Or if you need to support older .net framework clients or even java clients you need to be careful about what technology you use.
You will also want to choose between WCF or ASMX. Which the previous paragraph shouuld help answer.
It seems to me that the greatest challenge will be that you are obviously tempted to do this. I think you're making a mistake.
Your web application, and the web service you propose, have different requirements. By "transforming" the application into the service, you will burden the service with the requirements of the application.
Here's a "thought experiment": what if you were to write the service from scratch, ignoring the application. How similar would the service and application be? If they would wind up alike, then transformation would make sense. Otherwise, not so much.