I've created a process to be able send email to the user on order confirmation.
The problem is that on the DEV environment everything goes well but when I did a deploy to UAT server
I got an exception during the task execution ( " Media not found (requested media location: hf0/h27/8861015965726.bin) ").
Any Ideas what could be happening ?
How can this issue be resolved and what causes this issue.
hybris creates emails using Velocity templates. Those Velocity Templates are stored as Medias on the hybris Servers. hybris Medias consist of two parts: an entry in the respective table in the database and a file on the hard drive. The database entry stores metadata about that media while the file stores the actual content.
Now what hybris is telling you, is that the file on the hard drive is missing. The database entry directs to a file that is not existing. There could be a lot of reasons why that file is missing:
It was deleted during deployment.
It wasn't created during deployment.
The hybris server has no access/access rights to that directory.
In a clustered environment the file could have been stored on another node and is not accessible on the current node.
Media could be the email itself as Johannes stated, but it can also be a part of the email, an image set from the CMS cockpit for example.
To fix this issue you have to master your impex flows.
First be sure that impex contain all the data needed to create properly the email.
Then know what is imported when you deploy and update your system.
Be sure that mandatory files are imported during initialization.
Be sure that data that can be managed by webmasters are not reset by impex during update.
If a data is created during the update because init is already done then be sure that is won't be played after each update.
As the media file is not found, you can
1. go to hmc-->Multimedia-->Media, in search panel,
2. click "search additional attributes" dropdown box, select "PK of file"
3. use "8861015965726" as PK of file to search
Then you can find out what file is missing and you can import impex or upload using hmc to fix this problem.
Spring cloud config server supports reading property files with name ${spring.application.name}.properties. However I have 2 properties files in my application.
a.properties
b.properties
Can I get the config server to read both these properties files?
Rename your properties files in git or file system where your config server is looking at.
a.properties -> <your_application_name>.properties
a.properties -> <your_application_name>-<profile-name>.properties
For example, if your application name is test and you are running your application on dev profile, below two properties will be used together.
test.properties
test-dev.properties
Also you can specify additional profiles in bootstrap.properties of your config client to retrieve more properties files like below. For example,
spring:
profiles: dev
cloud:
config:
uri: http://yourconfigserver.com:8888
profile: dev,dev-db,dev-mq
If you specify like above, below all files will be used together.
test.properties
test-dev.properties
test-dev-db.prpoerties
test-dev-mq.properties
Note that the provided answer assumes your property files address different execution profiles. If they dont, i.e., your properties are split into different files for some other reason, e.g., maintenance purposes, divided by business/functional domain, or any other reason that suits your needs, then, by defining a profile for each such file, you are just "abusing" the profile feature, for achieving your goal (multiple property files per app).
You could then ask "OK, so what is the problem with that?". The problem is that you restrain yourself from various possibilities that you would otherwise have. If you actually want to customize your application configuration by profile you will have to create pseudo, sub, profiles for that since the file name is already a profile. Example:
Your application configuration could be customized by different profiles, which you use inside your springboot application (e.g. in #Profile() annotation), let them be dev, uat, prod. You can boot your application setting different profiles as active, e.g. 'dev' vs 'uat', and get the group of properties that you desire. For your a.properties b.properties and c.properties file, if different file names were supported, you would have a-dev.properties b-dev.properties and c-dev.properties files vs a-uat.properties b-uat.properties and c-uat.properties files for 'dev' and 'uat' profile.
Nevertheless, with the provided solution, you already have defined 3 profiles for each file: appname-a.properties appname-b.properties, and appname-c.properties: a, b, and c. Now imagine you have to create a different profile for each... profile(! it already shows something goes wrong here)! you would end up with a lot of profile permutations (which would get worse as files increase): The files would be appname-a-dev.properties, appname-b-dev.properties, app-c-dev.properties vs appname-a-uat.properties, appname-b-uat.properties, app-c-uat.properties, but the profiles would have been increased from ['dev', ' uat'] to ['a-dev', 'b-dev', 'c-dev', 'a-uat', 'b-uat', 'c-uat'] !!!
Even worse, how are you going to cope with all these profiles inside your code and more specifically your #Profile() annotations? Will you clutter the code space with "artificial" profiles just because you want to add one or two more different property files? It should have been sufficient to define your dev or uat profiles, where applicable, and define somewhere else the applicable property file names (which could then be further supported by profile, without any other configuration action), just as it happens in the externalized properties configuration for individual springboot apps
For argument completeness, I will just add here that if you want to switch to .yml property files one day, with the provided profile-based naming solution, you also loose the ability to define different "yaml document sections per profile" inside the same .yml file (Yes, in .yml you can have one property file yet define multiple logical yml documents inside, which its usually done for customizing the properties for different profiles, while having all related properties in one place). You loose the ability because you have already used the profile in the file name (appname-profile.yml)
I have issued a pull request with a minor fix for spring-cloud-config-server 1.4.x, which allows defining additionally supported file names (appart from "application[-profile]" and "{appname}[-profile]", that are currently supported) by providing a spring.cloud.congif.server.searchNames environment property - analogous to spring.config.name for springboot apps. I hope it gets reviewed and accepted.
I came across the same requirement lately with a little more constraint that I am not allowed to play around the environment profiles. So I wasn't allowed to do as the accepted answer. I'm sharing how I did it as an alternative to those who might have same case as me.
In my application, I have properties such as:
appxyz-data-soures.properties
appxyz-data-soures-staging.properties
appxyz-data-soures-production.properties
appxyz-interfaces.properties
appxyz-interfaces-staging.properties
appxyz-interfaces-production.properties
appxyz-feature.properties
appxyz-feature-staging.properties
appxyz-feature-production.properties
application.properties // for my use, contains local properties only
bootstrap.properties // for my use, contains management properties only
In my application, I have these particular properties set that allow me to achieve what I needed. But note I have the rest of needed config as well (enable cloud config, actuator refresh, eureka service discovery and so on) - just highlighting these for emphasis:
spring.application.name=appxyz
spring.cloud.config.name=appxyz-data-soures,appxyz-interfaces,appxyz-feature
You can observe that I didn't want to play around my application name but instead I used it as prefix for my config property files.
In my configuration server I configured in application.yml to capture pattern: 'appxyz-*':
spring:
cloud:
config:
server:
git:
uri: <git repo default>
repos:
appxyz:
pattern: 'appxyz-*'
uri: <another git repo if you have 1 repo per app>
private-key: ${git.appxyz.pk}
strict-host-key-checking: false
ignore-local-ssh-settings: true
private-key: ${git.default.pk}
In my Git repository I have the following. No application.properties and bootstrap because I didn't want those to be published and overridden/refreshed externally but you can do if you want.
appxyz-data-soures.properties
appxyz-data-soures-staging.properties
appxyz-data-soures-production.properties
appxyz-interfaces.properties
appxyz-interfaces-staging.properties
appxyz-interfaces-production.properties
appxyz-feature.properties
appxyz-feature-staging.properties
appxyz-feature-production.properties
It will be the pattern matching pattern: 'appxyz-*' that will capture and return the matching files from my git repository. The profile will also apply and fetch the correct property file accordingly. The prioritization of value is also preserved.
Furthermore, if you wish to add more file in your application (say appxyz-circuit-breaker.properties), we only need to do:
Add the name pattern in the spring.cloud.config.name=...,appxyz-circuit-breaker
The add the copies of the file locally and also externally (in the git repo.
No need to add/modify more or restart your configuration server later on. For new application, it's like a one time registration thing to add an entry under the repos of application.yml.
Hope it helps in one way or another!
In your application bootstrap.properties, you have to specify like below:
spring.application.name=a,b
I am trying to add service reference to Visual Studio for REST API.
The demo URL given to me by a DocuSign support engineer is as below.
https://demo.docusign.net/restapi/v2
But when I try to add it, I get the following error.
Do I need to add anything to web.config? Thanks in advance. I already have details related to SOAP in web.config. I added a second API URL string.
The document at the url https://demo.docusign.net/restapi/v2 was not recognized as a known document type.
The error message from each known type may help you fix the problem:
- Report from 'XML Schema' is 'Data at the root level is invalid. Line 1, position 1.'.
- Report from 'DISCO Document' is 'Data at the root level is invalid. Line 1, position 1.'.
- Report from 'WSDL Document' is 'There is an error in XML document (1, 1).'.
- Data at the root level is invalid. Line 1, position 1.
Metadata contains a reference that cannot be resolved: 'https://demo.docusign.net/restapi/v2'.
There was no endpoint listening at https://demo.docusign.net/restapi/v2 that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
The remote server returned an error: (404) Not Found.
If the service is defined in the current solution, try building the solution and adding the service reference again.
I recommend using the open source DocuSign NuGet package if you're using .NET / Visual Studio:
https://github.com/docusign/docusign-csharp-client
You can install it in seconds from the Tools menu and it will install the dependencies and references for your project automatically, then you can add your using statements in your code.
To get started follow the README.
I'm experiencing some strange behaviour with a ColdFusion 11 server, which (among other things) publishes some web services accessed via both SOAP and HTTP. The server itself is Windows 2012, running IIS. Actual folder config is as follows:
IIS has two websites configured, 'BOB' and 'BOB_Services'. Both have been configured with the CF Server Config tool so that CF handles .cfc, .cfm files. They share a common CFIDE config.
BOB's root is I:/inetpub/BOB
BOB_Services's root is I:/inetpub/BOB_Services
There is a folder mapping configured in CF Admin from '/' to 'I:/inetpub/BOB'. Don't ask me why, no one seems to know.
Normally there is a services.cfc file in BOB_Services ONLY. Yesterday we accidentally copied that same file into the BOB root folder, and all of our SOAP services using BOB_Services\services.cfc started throwing errors. Yet I can query the same webservice via HTTP (eg. using http://bob/services.cfc?method=function1¶m1=0 ....etc) and get a valid result.
This is a reference answer in case anyone else comes across this strange behaviour.
It appears that when BOB_Services/services.cfc is called using HTTP GET, the folder mapping
'/' -> 'I:/inetpub/BOB'
is ignored and the actual file used to process the request is I:/inetpub/BOB_Services/services.cfc.
When a function in BOB_Services/services.cfc is called using a SOAP client, the folder mapping is invoked and the file used to process the request is I:/inetpub/BOB/services.cfc, IF IT EXISTS. If it does not exist, the file I:/inetpub/BOB_Services/services.cfc is used as expected.
This behaviour appears to be entirely repeatable - I can make a SOAP request, get one result, change the mapping, make another request and get the other result.
Refresh error: Entity of type 'WorkflowFieldUpdate' named 'Case.ISHERE' not found Project/src package.xml line 1 1248190153153 205
any ideas what this means?
It's stopping us from deploying, as workflows don't appear on the deployment candidate list in Eclipse.
The fieldUpdates, definitely do exist in the Sanbox, when it says "not found" does in mean on the server or in the src\workflows\Case.workflow file?
It means that your package.xml file references a workflow field update on Case called "ISHERE", but there is no corresponding file on your local filesystem. You should either remove the reference in package.xml if you don't care about that being deployed or you should do a refresh from server to get the latest metadata (watch out for any local changes you've made!).