Explore the the Oracle Hospitality Innovation Center FAQs to gain better insight into the partner opportunities. Questions are collected and added after each Oracle Hospitality Live! Partner Innovation Enablement session.
Existing installations will not stop working. We are not going to shut off hotels because of it. However, if you don’t renew your OPN membership, your solution won’t be listed on Oracle Cloud Marketplace or the published list of interfaces. This means that if a hotel comes to us and asks about an integration with your product, sales will say ‘we don’t have an interface.’ Nobody wants that. We certainly don’t want that and customers don’t want that, so make sure your OPN membership is up to date. If you have questions, feel free to reach out and ask. You can check the status of your membership online, or reach out to the OPN team at oracle.com/partnernetwork.
I don’t believe we have anything officially published on this issue. There has been a bit of confusion over the years about what is supported and what is not supported with a non—validated interface. The way it’s been interpreted in the field is that it’s completely unsupported if it’s not validated—which isn’t entirely true. Of course, if Oracle sells software to a hotel we are going to support our software—it’s not like we are going to install it and walk away. With a validated interface, Oracle and the partner warrant that we’ve tested it and that we know it’s going to work within this scenario—that’s why we do the testing – we know that this configuration is going to work, we understand the parameters under which it will work, and we warrant that that’ll work. We’ll check that the OPERA configuration matches what it’s supposed to be with this particular interface. That’s part of the support piece and we’ll troubleshoot what is not working.
For a non-validated interface, Oracle will only support the Oracle side of it. If we’ve installed OWS and the hotel has made a private, custom connection with a partner, it’s an un-validated interface to our point of view. It’s customer-driven configuration that has very little, if anything to do with Oracle. We support OWS generically, so if the hotel calls and says it’s not working we will certainly dial in and see how everything is running but that’s where it stops. What we won’t do is go the next step and double check the messages are formatted properly or see which functionalities need to be turned on or off.
We are building an option for the cloud and are close to releasing it. But it’s also possible to use on-premises demo systems with OPERA 5. The only requirement is to have a current and valid OPN membership and also the License and Hardware track. Of course, it can be expensive to maintain that on your own, but some that do very well by it. We’re working on OPERA Cloud labs, and should be announcing that very shortly. If you are interested in purchasing an OPERA Cloud lab or if you’re interesting in more information about it, email me (firstname.lastname@example.org).
The new rest AP’s will be available initially for OPERA Cloud hotels, and we’ll be expanding that to our OPERA 5 hosted environments. At the moment we don’t have immediate plans to expand that functionality to on-premises sites. Your existing interfaces, for example, your OXIs and OWSs, will work for all three of those different deployment scenarios, but for the time being, the new rest APIs and platform will only connect to our cloud and hosted instances.
We actually have a number of different options for this. One would be to purchase your own OPERA Cloud environment. But that’s your own persistent environment, not a shared sandbox, so that’s the one that’s going to be the more expensive option.
There are some lower-cost options coming as well. We are going to be introducing a shared sandbox environment, available through the developer portal on OHIP. This is not going to be full UI access; it’ll be just API access, but of course we’ll have folks available to help out with the application side as needed. Access to the sandbox will be charged by call. This is a great option if you only need occasional access to test some calls. You’ll just pay for what you need, by the transaction, and those will help us offset the cost of providing the shared framework, but you don’t have the cost (and time) of maintaining your own environment.
Another option would be to simply engage with the Oracle Consulting team for a couple of hours of their time to use their lab. You contract for the time you need, then use their lab and get one-on-one help during the time. You could also partner with a hotel that already has a UAT or other non-production environment. Make a deal with them in exchange for using their lab. Some of our partners have done this outside of the OHIP scenario, using OXI or OWS for example. It can be a little more complicated, but it’s an option if you have some customers with which you tend to work closely.
The confirmation number is not unique and the reason is because of the the leg numbers within OPERA. You can have an itinerary reservation for different dates and different hotels in the environment that have different leg numbers, but the same confirmation number. So, you can have confirmation number 1234 leg 1 leg 2 leg 3 leg 4. In that instance, a confirmation number is not necessarily unique. However, in an environment the resv_name_id is definitely unique per environment. If it’s two separate environments, then confirmation numbers and resv_name_ids could be similar because they’re separate databases. But in one database, one environment, the resv_name_id is definitely unique.
We have a couple of options on how we might be able to assist, and this will be included in the information when we roll it out. We are still working on this.
Right now no. It’s something we can look at in the future, but it’s not part of our first focus. Part of the reason for that is simply architecture—the architecture for these REST APIs exists with the versions of OPERA that are in the cloud. Getting all those REST APIs on-premises would have to be done on property. There are many reasons why that’s a little more complicated, not the least of which is there are thousands and thousands of hotels which would need to be individually managed with cloud-level systems.
OPERA does actually have APIARY but APIARY is only going to be available with our new integration platform—Oracle Hospitality Integration Platform. The platform includes a self-service developer portal where you can register and browse our API catalogue. APIARY is embedded into this developer portal so you don’t have to go into the cloud separately; you’ll be able to browse our REST API catalogue from the developer portal itself, with the APIARY look and feel. This is going to be only for OPERA Cloud and OPERA 5 hosted, not on-premises. For on-premises OPERA deployments you will need to use the existing interfaces (for example OXI and OWS), the specs for which are available on docs.Oracle.com
Unfortunately, that is not possible with OXI logic,. When the business event is created, it does contain the old and new value, but when OXI goes to pick it up, it is designed to send the data as is at that exact moment (the new value).
Feel free to email email@example.com
The fetch booking call only returns a single reservation. Typically, the call requires confirmation number or internal resv_id. If you want to see all your due-ins, what you’re likely looking for will be in the Reservation service. But under future booking summary call, you’re able to call and get all your due ins, checked ins, names etc. The function you want to look is called future booking summary and it’s within the Reservation web service.
Right now, the roadmap is to expose Simphony APIs through OHIP. There are a few things we need to do in order to make that happen. They have their own usage terms and conditions and platform, so we need to reconcile all of that. What we really wanted to focus on was getting the OPERA CLOUD APIs out there first, so Simphony APIs aren’t in the 20.1 release, but it’s something we’ll consider down the road.