Can anyone tell me the difference between these 3 IDs?
I want to identify a particular installation (per purchase/device and not counting minor updates) of my win8 app, which of them will best fit my need?
You'll probably need two of them:
App Specific Hardware ID (ASHWID) contains information about the device (it does not necessarily match the purchase since the latter is attached to a user account). Also you will probably need to account for the hardware drift as explained here.
Package.Current.Id identifies your application, including its complete version, so you'll need to ignore the parts which you allow to change with minor updates.
EDIT:
I don't think CoreApplication.Id will be any use to you. It is only unique within a package to differentiate between multiple application within a single package. I don't think you van edit it through VS designer, but you can see the value if you open the appxmanifest file in editor, e.g.:
<Package>
<Applications>
<Application Id="App" />
It's probably best documented here.
If you want to identify a device, ASHWID is the way to go (you might want to use it in combination with a Device Guid generated on the user local storage to ease server lookup of the known device ASHWID)
If you want to identify a purchase you definitely want to take a look at CurrentApp.GetAppReceiptAsync (and similar methods) . http://msdn.microsoft.com/fr-fr/library/windows/apps/jj649137.aspx
You can also use combination of the two depending on your scenario.
Related
I am developing a library to edit contacts on a CardDAV Server and I wonder what is the proper way to sync contacts.
So when I find an etag for a specific contact changed: How do I sync both?
Do I just combine the changed data, e.g. phone numbers? Or must one side (Server or client) win? And how to I detect if a number changed or was added?
The Building a CardDAV client document explains all this very well.
But to address your questions:
So when I find an etag for a specific contact changed: How do I sync both?
You load the vCard from the server. Then it depends on the logic of your client. Do you want to auto merge? Do you want to prompt the user whether he wants to merge? Etc.
Usually you want to auto-merge. So do this. After you have the merged vCard, PUT that again to the server, but make sure to use the If-Match header to ensure that it didn't change again on the server side.
Do I just combine the changed data, e.g. phone numbers?
What you consider useful is entirely up to your application. But just combining fields may not be what you want. For example you wouldn't be able to detect deletes.
So in most cases this is going to be a three-way merge:
old version of the server (stored locally)
new version of the server (that you just fetched)
current version of the local application
Or must one side (Server or client) win?
Some clients do it like that, but this is not required. However, if you modify after a change, you need to be VERY careful with sync cycles!
And how to I detect if a number changed or was added?
You store the old copy you know and diff.
In general it is a good idea to store the (last known) opaque server copy locally and just pick out the fields your client cares about. Then when uploading the item again, you just patch the ones again. (and preserve the rest of what the server sent you).
Summary: A proper vCard diff and local cache is non-trivial. Many clients fail on that and loose or dupe user data.
So unless you plan to put the necessary work and testing into this, an easier way is to detect the changes and ask the user what he wants to do (let server win, force user copy, merge).
I have a question on how we can import/synchronise products from our back-office to CQ5 front end.
The architecture to be is pretty simple - custom back-office managing all the products( basically it will be the source of truth). CQ5 driven web-site to show search results(driven by Adobe SearchAndPromote) and product details. Purchase transactions will be handled outside of CQ5.
I went through http://dev.day.com/docs/en/cq/current/ecommerce/eCommerce-framework.html and I think have some idea in which direction we should move, but I would like someone to confirm that my understanding is correct.
1) I need to create scheduled job running on Author node that would call back-office and import products as json feed. I use annotation based #Service(Runnable.class) - Is there a way to set it so it rund on Author node only?
2) Create custom service(called my service above) that will actually create all the nodes in crx. If I have desktop and mobile versions of the site do I need to create all those dones twice? Are there any tips on easier way to create those?
3) Let CQ5 replicate those products to publish nodes.
Is there a easier way? I mean if I was using more standard web-app I would have one controller to show product details, two templates(one for mobile, one for desktop) and a service that would call back-office and return details for requested product. But Sling world is very different, and I want to check if I understand it correctly.
Cheers.
Here are some answers:
1) Here is a good article about different configs for different runmodes: http://helpx.adobe.com/cq/kb/RunModeSetUp.html you can create configs for pub and auth runmodes with certain flag your code will look for which will tell whether to execute import or not.
2) It depends. CQ tends to have copies of content for mobile site so it may make sense to do copies of nodes for mobile site but only in case you those nodes are pages (cq:Page and cq:PageContent) you create based on imported data. Otherwise you just need to save imported data somewhere and obtain it at some moment (via JCR queries or methods like .getNode()). In this case of course it makes sense not to copy your data.
3) It depends here as well. I would consider following forces you may have: should imported data be editable? how frequent are updates? how massive are updates? how critical is consistency across pubs? In case updates are not massive, not frequent and consistency matters import to auth followed by replication can work. Also it may be the case if you need to be able to edit imported data. In case updates are massive and/or frequent and consistency across pubs do not matter much (you can afford that some people may see different results from different pubs during import) I'd suggest run import on all pubs at the same time since massive replication of imported data may affect regular page/images replications.
Thanks,
Max.
I wonder what is the best way to implement global data version for database. I want for any modification that is done to the database to incerease the version in "global version table" by one. I need this so that when I talk to application users I know what version of data we are talking about.
Should I store this information in table?
Should I use triggers for this?
This version number can be stored in a configuration table or in a dedicated table (with one field).
This parameter should not be automatically updated because you are the owner of the schema and you are responsible for knowing when you need to update it. Basically, you need to update this number every time you deploy a new application package (regardless of the reason for the package: code or database change).
Each and every deployment package should take care of updating the schema version number and the database schema (if necessary)
I tend to have a globals or settings table with various pseudo-static values stored.
- Just one row
- Many fields
This can include version numbers.
In terms of maintaining the version number you refer to, would this change when the data content changes? If so, the a trigger would be useful. If you mean for the version number to relate to table structures, etc, I'd be more inclined to manage this by hand. (Some changes may be irrelevant as far as teh applications are concerned, or there maybe several changes wrapped up into a single version upgrade.)
The best way to implement a "global data version for database" is via your source control system and build process. When all the changes have been submitted and passed testing your build process will increment your versioning number schema.
The version number could be implemented in a stored procedure. The result of the call to the stored proc could be added to a screen in your app so you can avoid users directly accessing a table.
To complete the previous answers, I came across the concept of "Migrations" (from the Ruby on Rails world apparently) today, and there was already a question on SO that covered existing frameworks in .Net.
The concept is still to store DB versioning information as data in a table somewhere, but for that versioning information to be managed automatically by a framework, rather than manually by your custom deployment processes:
previous SO question with overview of options: https://stackoverflow.com/questions/313/net-migrations-engine
Every week I access server logs processed by WebTrends (for about 7 profiles) and copy ad clickthrough and visitor information into Excel spreadsheets. A lot of it is just accessing certain sections and finding the right title and then copying the unique visitor information.
I tried using WebTrends' built-in query tool but that is really poorly done (only uses a drag-and-drop system instead of text-based) and it has a maximum number of parameters and maximum length of queries to query with. As far as I know, the tools in WebTrends are not suitable to my purpose of automating the entire web metrics gathering process.
I've gotten access to the raw server logs, but it seems redundant to parse that given that they are already being processed by WebTrends.
To me it seems very scriptable, but how would I go about doing that? Is screen-scraping an option?
I use ODBC for querying metrics and numbers out of webtrends. We even fill a scorecard with all key performance metrics..
Its in German, but maybe the idea helps you: http://www.web-scorecard.net/
Michael
Which version of WebTrends are you using? Unless this is a very old install, there should be options to schedule these reports to be emailed to you, and also to bookmark queries. Let me know which version it is and I can make some recommendations.
There are parameters that I would not want to be transferred from production environment to QA system. Staff like network path and url's. The problem is that in ABAP everything is in the database and when the database is copied to the QA system you have to manually change those parameters. And this is prone to errors.
Is there a way to store configuration information in a way that won't get transferred with the database?
Thanks.
In short: no - at least that would be very unusual in a SAP environment.
If your QA system is set up as a system copy of your production environment (which is the usual path), there are quite a few steps to do to make the system work correctly. This includes some configuration, which can be as simple as filepaths such as you mention, but also the addresses and names of "partner systems". For example, one of my customers is a bank, so when copying his production system, he makes triply sure that no activity on the QA side accidentally trickles to the production side. Some other changes are made as well, for example obscuring peoples names and addresses so no mail gets accidentally sent etc.
There are a few ways to make applying these changes as easy as possible (look for some SAP documentation or books on SAP Transport and Change management, I had one by Sue McFarland Metzger or so that was quite good). From what I've seen, there is usually a set of transports that change the configuration and customizing etc. on the QA system to the
appropriate values.
Hope that helps.
You cannot prevent the configuration stored in the database from being copied to the cloned instance. However, you can design the configuration storage in a way that will prevent the copied entries from being used. You should check with your basis administrators if they can guarantee that the cloned system will get a new system ID (SID). If this is the case, then you can simply use the SID as key field in your configuration table. After the system copy, the SID will be changed and the cloned system will no longer access the original entries.
your question is not clear, are you talking about standard or custom config ?
Greetings, assuming you are storing these paths in a Z table, then some shops put the sy-sysid ( system id ) as one of the columns. Maintain all systems in your dev and transport to production. This becomes painful after a while, so I would only suggest this for information that does not change a lot ( file paths might be good ).
T.