What WMI class stores Deployment Type installation program on MECM - wmi

I need to retreive a data related the MECM Application via WMI classes, more specifically, I need to get Application Deployment Type properties - Installation / Uninstallation programs.
Could you please help me, what exact WMI class can I use to obtain this information.
Thank you for any help.

This is unfortunately not very easy to get information afaik, but with some help from powershell (or any programming language that can access wmi really) it can be done.
The information itself is stored within the Class SMS_Application in the Property SDMPackageXML.
Now the first thing you will notice if you query this is it is probably empty. That is because it is a lazy property. To work around this in PS you have to for example call an extra get() on your wmi object.
If you do this (or have some tool that just shows all lazy parameters anyway) you will notice it is - as suggested by the name - basically an XML document, that stores the information you need deep inside. So you have to extract it from within the XML.
Some example code on how to do this for a single app would be:
$app = Get-WmiObject -Class SMS_Application -Namespace "root\SMS\site_sitecode" -computer "your site server" -Filter "LocalizedDisplayName='your app name'"
$app.Get()
$installCMD = (([xml](($app).SDMPackageXML)).AppMgmtDigest.DeploymentType.Installer.InstallAction.Args.Arg | where {$_.Name -ieq "InstallCommandLine"}).'#text'
$uninstallCMD = (([xml](($app).SDMPackageXML)).AppMgmtDigest.DeploymentType.Installer.InstallAction.Args.Arg | where {$_.Name -ieq "UninstallCommandLine"}).'#text'
I'm not great with xml parsing so there might be a better way to do it or maybe you don't need the parsing but can just string compare the xml digest. Just start by looking at a SDMPackageXML and then you will probably see how to best analyze it for your own needs.

Related

Storing CiviCRM extension specific configuration in database

I'm building a CiviCRM extension, which would also have an admin section with UI for setting various configuration specific to the extension. I'm looking for a recommended approach for storing the configuration in the database.
One way is to create a new table in the database specifically for this purpose, but this seems like an overkill if there are only a couple of options to be saved.
Another way could be to use the civicrm_setting table, which kind of makes sense at first, but I'm not sure if this table is meant to be used for this purpose.
Any advice would be appreciated.
Yes, you can and should definitively use civicrm_setting.
civicrm_setting has a column group_name that should contain a unique identifier for your extension. I usually put the full name of the extension, like org.example.extension but it could be any string, and in core they use label name (e.g., Preference settings).
To interact with those settings, you can do the following :
// save the setting
CRM_Core_BAO_Setting::setItem($value, 'My group name', 'my_setting_name');
// get the setting
$setting = CRM_Core_BAO_Setting::getItem('My group name', 'my_setting_name');
// get all the setting for you extension
$settings = CRM_Core_BAO_Setting::getItem('My group name');
There seems to be an API for Setting but it doesn't seem to work well in CiviCRM 4.4.x. Don't know if it is better in CiviCRM 4.5.
What you could also do (our current practice) is store your configuration logic in a special class using the singleton pattern (as CiviCRM does itslef). If you want to see an example check this:
https://github.com/CiviCooP/no.maf.oppgavexml/blob/master/CRM/Oppgavexml/Config.php

Create complex-type variables for a Web Service Task

In SSIS, I already have a Web Service Task using a WSDL for sending SMS. I am indeed able to send SMS using this task.
I want supply values to this task from the database, such as Mobile Number, Message body, User ID, etc.
How can I create a complex type user variable that can be passed as input to a Web Service task?
It looks like the only answer is to change the web service to accept only simple types as parameters. I have scoured the web and there seems to be no way to dynamically create complex types for consumption by the input values in the web service task.
The more 'easy' way is to use the script component for bypassing variables to a web service. Check http://amolpandey.com/2016/09/26/ssis-script-task-to-obtain-geo-cordinates-from-address-text-via-google-api/ & http://www.sqlmusings.com/2011/03/25/geocode-locations-using-google-maps-v3-api-and-ssis/.
Tested and working. Using this task you can bypass the SSIS variables/parameters.
Example: Getting ID, addreess, zipcode, city, country from a table with an execute SQL Task. Change Resultset:Full result set on General tab. Then on resultset tab add Result_Name:0 & Variable_Name: User::YourObject. Then the next task will be a Forlooptask editor (Foreach ADO Enumerator ,Collection tab - Ado object source variable: User::YourObject, enumeration mode: rows in the first table, variable Mapping tab - Variable User::Id, 0 | address,1 etc.). Inside the Forlooptask editor you add a data flow task, which the source of this task will be a script component. If you be more specific about your logic,we may assist you more.
Okay so I came across the same problem. I needed to pass one parameter as complex type.
Create a Web Service task in your package.
Fill all the needed properties at General tab: HttpConnection and WSDFile
Fill properties in Input tab: Service, Method
Below click on Value, manually enter the value you need (mine is 2021-11-15)
Deploy and execute package to be sure everything is OK
After this easy steps go into folder where package is localated. Right click on package file (Package.dtsx) and select Open with > Notepad. With find function in notepad search the value you manually inserted.
The part which we are looking for looks in my case like this
<WSTask:ComplexValue>
<WSTask:ComplexProperty
WSTask:Name="date"
WSTask:Datatype="dateTime"
WSTask:ParamType="Primitive">
<WSTask:PrimitiveValue>2021-11-15</WSTask:PrimitiveValue>
</WSTask:ComplexProperty>
</WSTask:ComplexValue>
Finally I found what I was looking for. Now for the second part I needed to be that parameter changing by current date when I execute that package. In powershell I managed to write a code that change date part in string: <WSTask:PrimitiveValue>2021-11-15</WSTask:PrimitiveValue> to current date, everytime when the package is executed. The code looks like this:
$Now = Get-Date -Format "yyyy-MM-dd"
$Yesterday = (Get-Date).AddDays(-1).ToString("yyyy-MM-dd")
$file = ((Get-Content -path "C:\Package.dtsx" -Raw) -replace "<WSTask:PrimitiveValue>$Yesterday</WSTask:PrimitiveValue>", "<WSTask:PrimitiveValue>$Now</WSTask:PrimitiveValue>")
[System.IO.File]::WriteAllText("C:\Package.dtsx",$file)
# This part will execute the package #
dtexec.exe /f "C:\Package.dtsx"
After all this, I planned this script in Task Scheduler and it works.
In my case changing the type of request from complex to simple wasn't an option and all I needed was just one parameter to pass.
Hopes it gonna help somebody.

s9api versus trax with saxon-b

I was handed a shell script containing both:
java -cp $(CLASSPATH) net.sf.saxon.Transform -xsl:$(CMS_ROOT)/$(TRANSFORMS_DIR)/$(LOCALE_STYLESHEET) \ -it:root
and other cases that an output.
It wasn't obvious to me how to specify the initial transform through trax, so I went with the s9api.
Come to discover that passing a Serializer based on an output file to an XmlTransformer does not result in setting the base output URI to that file. I had to add:
transformer.getUnderlyingController().setBaseOutputURI(outputFile.toURI().toString());
All this suggests to me that I might be better off just talking to trax and figuring out how to specify an initial transform and anything else I need. Can anyone shed light one way or the other?
Saxon 9.2 and later have a setBaseOutputURI() method on the s9api XsltTransformer class.
For 9.4 I will make the change you suggest, of using the destination URI of the Serializer as a default for the output base URI when possible.

SharePoint Web Services - Updating ContentType field Required property?

I've been trying to programmatically reproduce the behavior of editing a Content Type's field properties in the SharePoint site management screen and selecting the "Required" radio button with no sucess using the WSS 3.0 web service's Webs.asmx "UpdateContentType" method.
The first difficulty was the issue with the MSDN documentation that said fields should be of a FieldRef type when in fact they need to be of a Field type (reference). Adding fields and deleting fields works fine after the fix, but updating fields seems to not function at all. (It should also be noted that I followed the recommendation on the previous link to use Method="2" for updating fields but it changes nothing, and using Method values other than 1 for adding or other than 3 for deleting also function correctly).
Here's the web service call (slightly modified with strings instead of XmlNode objects for readability):
SharePointWebServices.Webs webService = new SharePointWebServices.Webs();
webService.Url = "http://mysharepointserver/site";
webService.UseDefaultCredentials = true;
webService.UpdateContentType(
#"0x01005A089D9EC8A382458FB1F6C72096D52A",
#"<ContentType />",
#"<Fields />",
#"<Fields><Method ID=""1""><Field Name=""SomeField"" ID=""{8a4803c4-6545-4a7a-804d-237eebff0ce3}"" Required=""TRUE"" Hidden=""FALSE"" ReadOnly=""FALSE"" PITarget="""" PIAttribute="""" PrimaryPIAttribute="""" Aggregation="""" Node="""" /></Method></Fields>",
#"<Fields />");
After the call, the field is still Required="FALSE".
A quick look into the stssoap.dll assembly indicates that the "Required" property is apparently ignored during the update process. Is this normal behavior? If so, what is the recommended method for programmatically changing the "Required" field from client code (not executing on the SharePoint server)?
Any help would be greatly appreciated.
I've investigated this and found the same thing. I also tried adding the attribute Cmd="Update" to the Method element without success. This example of how to use UpdateContentType was helpful too.
I don't believe you will be able to do this with the out-of-the-box SharePoint services. You've verified from looking at stssoap.dll that this doesn't appear to work correctly. Another 'client'-style option is to use RPC methods but none appear to provide functionality for content types at all.
The web services are particularly frustrating because this type of not-so-edge case regularly comes up. It is very rare that I consider using them because of the time wasting involved with their limitations.
Do you have any option of deploying custom code to the server? You could develop this functionality using the object model and wrap it in your own custom web service (there is a walkthrough here) quite easily.
Here is an example adapted from Gabe Wishnie that does what you require:
SPContentType myContentType = myWeb.ContentTypes["myContentType"];
string internalName = myContentType.Fields["fieldToUpdate"].InternalName;
myContentType.FieldLinks[internalName].Required = false;
myContentType.Update(true);
Sorry this isn't more helpful but it's a common story when using the WSS 3.0 / SharePoint 2007 web services.

ie useragent wxWidgets

Im currently using ie as an active x com thing on wxWidgets and was wanting to know if there is any easy way to change the user agent that will always work.
Atm im changing the header but this only works when i manually load the link (i.e. call setUrl)
The only way that will "always work," so far as I've been able to find, is changing the user-agent string in the registry. That will, of course, affect every web browser instance running on that machine.
You might also try a Google search on DISPID_AMBIENT_USERAGENT. From this Microsoft page:
MSHTML will also ask for a new user
agent via DISPID_AMBIENT_USERAGENT
when navigating to clicked hyperlinks.
This ambient property can be
overridden, but it is not used when
programmatically calling the Navigate
method; it will also not cause the
userAgent property of the DOM's
navigator object or clientInformation
behavior to be altered - this property
will always reflect Internet
Explorer's own UserAgent string.
I'm not familiar with the MSHTML component, so I'm not certain that's helpful.
I hope that at least gives you a place to start. :-)
I did a bit of googling today with the hint you provided head geek and i worked out how to do it.
wxWidgets uses an activex rapper class called FrameSite that handles the invoke requests. What i did was make a new class that inherits from this, handles the DISPID_AMBIENT_USERAGENT event and passes all others on. Thus now i can return a different user agent.
Thanks for the help.
Head Geek already told you where in the registy IE will look by default.
This is just a default, though. If you implement [IDocHostUIHandler::GetOptionKeyPath](http://msdn.microsoft.com/en-us/library/aa753258(VS.85%29.aspx) or [IDocHostUIHandler2::GetOverrideKeyPath](http://msdn.microsoft.com/en-us/library/aa753274(VS.85%29.aspx), IE will use that registry entry instead.
You'll probably want to use SysInternal's RegMon to debug this.