on 07-29-2015 11:45 PM
Hi
I am pretty new to the OData development. We have an existing system which has Odata services in DEV,QA & PRODUCTION environment.
We have created a new OData services in DEV system & have the System Alias set to DEV. Once we move this service to QA the system alias is not getting moved. When try to create a alias in QA we are getting a create request dialog. We are not sure whether this is the right way of moving the transport from DEV to QA. In case of the movement to PROD also we will might need to set the System Alias as PROD. Is there any alternative way where we don't have to set System Alias in QA & PROD once we are set in DEV .
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Gijo,
Do you have embedded deployment or Hub?
If it is embedded deployment, then you can create a system alias with a generic name like 'LOCAL' and move it.
If it is Hub, there is no use of moving the system alias as the system alias in Dev is pointing to Dev Backend.
When the table is marked as 'Current Settings', you do not have to create transports. This blog can help.
Regards
Krishna
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Krishna,
We are working on an existing system which has System Alias created for dev, QA & PROD from which I guess its a hub. We had created 2 new OData services for these services when moved to QA System alias is not present & we are asked to set the System Alias & create a new request. Same might be needed for PROD environment. Is there a way we can set the Odata services to take the current settings so that we don't have create system alias for different environment. I hope you are getting my problem.
Hi Gijo,
has suggested the right thing. You need to know about the deployment scenario in your case. Is the gateway service getting the data from the same system or developed/getting data from other backend system? If it is same system that means embedded deployment and you can create a generic alias that can be transported to all systems and would work without any change.
Otherwise in Hub, you create the RFC destination in Hub (all systems DEV, QA & PRD) pointing to their respective backend systems with some generic name like 'BACKEND_RFC' and create the generic system alias like, 'BACKEND_ALIAS' then transport the customizing entry from DEV to these systems. Since the BACKEND_RFC would be present in these systems, there should not be any change required.
Regards,
Ekansh
User | Count |
---|---|
85 | |
10 | |
10 | |
10 | |
7 | |
6 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.