I want to configure IIB 10 and MQ 8 so that the published monitoring-event messages are persisted in a persistent MQ queue.
The manual at : https://www.ibm.com/support/knowledgecenter/SSMKHH_10.0.0/com.ibm.etools.mft.doc/ac37850_.htm
has a Note to say:
Publications resolve to be nonpersistent by default, but you can change a publication to be persistent by configuring named topics in WebSphere® MQ. For more information, see the Subscriptions and message persistence topic in the WebSphere MQ Version 7.5 product documentation online.
Unfortunately, this weird ref to an old version of MQ leads nowhere.
I went through the MQ manual that defines the fields in the Topic definition in Explorer and that doesn't help, since the 'Default persistence' requires the publisher to use MQPER_PERSISTENCE_AS_Q_DEF. As IIB's default is 'not persistent', I have to assume it doesn't use this.
I'd be really grateful if someone could tell me how to override this and have persisitent messages written to a persistent queue.
FWIW
I originally assumed that defining the queue to receive the event messages as persistent would do the trick - it doesn't.
Next, I tried defining a topic XXX with topic string $SYS/Broker/int-sver/monitoring/+/+ with 'Default persistence' set to 'Persistent' - that doesn't work, either.
You mentioned the docs state "Publications resolve to be nonpersistent by default", this does not mean that they use MQPER_NOT_PERSISTENT, likely they use MQPER_PERSISTENCE_AS_Q_DEF or specify nothing at all in which case it defaults to the same as if MQPER_PERSISTENCE_AS_Q_DEF was specified.
The problem is with your topic string. A TOPIC object is a anchor to a leaf in the tree. It applies to anything below that leaf unless a more specific TOPIC object applies. So in your case the string should be $SYS/Broker/int-sver/monitoring with out the /+/+ at the end.
+ is a wildcard and wildcards only come into play on subscriptions not on topics.
You can find more information in the IBM MQ v8.0 Knowledge Center page IBM MQ>Technical overview>IBM MQ objects>Object types>Topic objects:
A topic object is an IBM® MQ object that allows you to assign
specific, non-default attributes to topics.
A topic is defined by an application publishing or subscribing to a
particular topic string. A topic string can specify a hierarchy of
topics by separating them with a forward slash character (/). This can
be visualized by a topic tree. For example, if an application
publishes to the topic strings /Sport/American Football and
/Sport/Soccer, a topic tree will be created that has a parent node
Sport with two children, American Football, and Soccer.
Topics inherit their attributes from the first parent administrative
node found in their topic tree. If there are no administrative topic
nodes in a particular topic tree, then all topics will inherit their
attributes from the base topic object, SYSTEM.BASE.TOPIC.
You can create a topic object at any node in a topic tree by
specifying that node's topic string in the TOPICSTR attribute of the
topic object. You can also define other attributes for the
administrative topic node. For more information about these
attributes, see the The MQSC
commands,
or the Automating administration
tasks.
Each topic object will, by default, inherit its attributes from its
closest parent administrative topic node.
topic objects can also be used to hide the full topic tree from
application developers. If a topic object named FOOTBALL.US is created
for the topic /Sport/American Football, an application can publish or
subscribe to the object named FOOTBALL.US instead of the string
/Sport/American Football with the same result.
If you enter a #, +, /, or * character within a topic string on a
topic object, the character is treated as a normal character within
the string, and is considered to be part of the topic string
associated with a topic object.
For more information about topic objects, see Publish/subscribe
messaging.
The closest page I could find to the link in the IIB KC on MQ v8.0 is the IBM MQ Knowledge Center page IBM MQ>Developing applications>Developing MQI applications with IBM MQ>Writing a procedural application for queuing>Writing publish/subscribe applications>Subscription options:
Message persistence
--
Queue managers maintain the persistence of the publications they
forward to subscribers as set by the publisher. The publisher sets the
persistence to be one of the following options:
0
Nonpersistent
1
Persistent
2
Persistence as queue/topic definition
For publish/subscribe, the publisher resolves the topic object and
topicString to a resolved topic object. If the publisher specifies
Persistence as queue/topic definition, then the default persistence
from the resolved topic object is set for the publication.
This article explains how to generate and subscribe to broker generated event messages.
It is not in the text, but I think the generates messages are persistent.
https://www.ibm.com/developerworks/websphere/library/techarticles/0911_fan/0911_fan.html
At the subscription queue one could also set DEFPSIST(YES)
Related
The documentation mentions that extended properties are a finite resource in a user's mailbox, and exceeding this limit will result in unexpected errors when trying to create new properties.
It is not mentioned explicitly anywhere that I could if item customProperties, as written to through the Office.js client, has the same limitation. Does it?
We plan to optionally write a small amount of data to item customProperties if the user modifies inputs exposed in our Add-in Taskpane in the Outlook client. These properties will later be read by a server consuming changed events through the events delta API.
Will we eventually run into issues with this approach if we don't implement some sort of "garbage collection" of no longer used customProperties?
Item custom Properties are extended properties https://learn.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxcext/4cf1da5e-c68e-433e-a97e-c45625483481?redirectedfrom=MSDN
So you have one extended property and then the value is a Json Key pair so one Extended property provides multiple custom properties (up to the limitation of the size of the Extended property)
Even if you don't want to use Item Custom properties its a good idea to follow the same approach eg create one extended property for your app and then store what ever combination of property values you need as a JSON structure in the value on the property. Its not a good idea to have your application creating random/multiple custom properties as you will easily exhaust them/create a mess and there is no advantage in doing it that way.
We are working with schools who use Microsoft Education and School Data Sync (SDS) to load their teachers, students and groups. In SDS there are some properties such as Grade, GraduationYear etc. and we´ve been trying to figure out if these are accessible via the Microsoft Graph API.
With a bit of experimentation and via this article, we can see on Groups and Users certain properties we can get prefixed with extension_fe2174665583431c953114ff7268b7b3_Education_. fe2174665583431c953114ff7268b7b3 seems to be the app id for SDS.
We were wondering if this is a sensible route to get at these properties from SDS or if there is a better route for getting these? We can, for example, see the term information available in classes but we don´t see the subject information there.
For groups:
Groups: https://graph.microsoft.com/v1.0/groups/{Id}?$select=extension_fe2174665583431c953114ff7268b7b3_Education_{Name}
Note: Groups in SDS are called sections
Status (e.g.extension_fe2174665583431c953114ff7268b7b3_Education_Status)
Period - This seems to be called periods in the import files
CourseSubject - e.g. History
CourseDescription - e.g. History of the World
CourseName
CourseNumber
TermEndDate
TermStartDate
TermName
SyncSource_CourseId
SyncSource_TermId
SectionName - this is the name that comes from the SDS file
Users: https://graph.microsoft.com/v1.0/users/{Id}?select=$extension_fe2174665583431c953114ff7268b7b3_Education_{Name}
Grade
GraduationYear
SyncSource_StudentId
ObjectType - Shows if this a teacher or a student
DateOfBirth
The only supported route to access this information is through the Education Graph APIs documented here. Right now that is a subset of the properties imported by School Data Sync. The underlying extension properties should be considered a point-in-time implementation detail and not relied upon in production apps.
Current plan as of Feb 2019 is to add the course information to the educationClass object in the next couple of months. That just leaves a few properties different across the education entities which we don't have a concrete plan for yet.
https://facebook.github.io/relay/graphql/objectidentification.htm is very clear around what Node is and how it behaves, but it doesn't specify which objects must implement it, or what the consequences are if your object doesn't implement it. Is there a set of features that don't work? Are such objects completely ignored? Not all objects in the existing spec (e.g. pageInfo) implement it, so it's clearly not universally required, but pageInfo is somewhat of a special case.
Another way of thinking about the Node interface is that objects that implement it are refetchable. Refetchability effectively means that an object has an ID that I can use to identify the object and retrieve it; by convention, these IDs will usually be opaque, but will contain type information and an identifier within that type (eg. a Base-64 encoding of a string like "Account:1234").
Relay will leverage refetchability in two ways:
Under a process known as "diffing", if you already have some data for an object identified by ID QWNjb3VudDoxMjM0 (say, the name and address fields), and you then navigate to a view where we show some additional fields (location, createdAt) then Relay can make a minimal query that "refetches" the node but only requests the missing fields.
Relatedly, Relay will diff connections and will make use of the Node interface to fill in missing data on those (example: through some combination of navigation you might have full information for some items in a view, but need to fill in location for some items within the range, or you might modify an item in a connection via a mutation). So, in basic pagination, Relay will often end up making a first + after query to extend a connection, but if you inspect its network traffic in a real app you will also see that it makes node queries for items within connections.
So yes, you're right that pageInfo doesn't implement Node, and it wouldn't really make sense for it to do so.
I am attempting to implement zookeeper as a shared state engine for an application I am creating in erlang. The structure for the state would be like the following:
/appRoot
/parent1:{json}
/child1:{json}
/child2:{json}
/parent2:{json}
/child1:{json}
/child2:{json}
I would like to be able to have a single method that returned all parent nodes when provided /appRoot along with it's data. Say in a list of tuples [{parent1,{json}}, {parent2:{json}}]. Or, if provided /appRoot/parent1 a list of it's subnodes with the data. So far, all I see is a way to get the keys (getChildren) then recursively retrieve the data with the key. It seems like I should be able to just make one call to do this.
I am currently using the ezk erlang client library. If anybody knows a better solution, that would be appreciated as well.
TIA
AFAIK there is no way to atomically list node children along with its data in zookeeper wire protocol. Seems, there is only way to do this is following:
List all node children and monitor children changes.
For each child node read it data and monitor data changes.
Update corresponding values on each children change happened after you started traversal.
This can be easily done over ezk, but I've not provided any example code because it heavily depends on guarantees of atomicity that your app logic demanded.
Example: I want to use the interface of nsILocalFile in Javascript, how to find the corresponding Contract ID("#mozilla.org/file/local;1")? Is there a map in the source code?
You don't. This isn't a one-to-one relationship between contracts and interfaces but a many-to-many one:
A single component as accessible by a contract can implement multiple interfaces.
A single interface can have multiple components implementing it and therefore multiple contracts.
But, often it is a one-to-one relationship in practice. E.g. if I wanted to find out about what components implement nsILocalFile, I'd search it in the sources, for instance:
MXR: http://mxr.mozilla.org/mozilla-central/ident?i=nsILocalFile&tree=mozilla-central
A glance over the result list already tells me: line 1255 -- let file = Cc["#mozilla.org/file/local;1"].createInstance(Ci.nsILocalFile);
Else I'd have to look at the files the different results link, starting with the .js ones.
Other times, the contract ids are even specified in the idl itself, e.g. in nsITimer.idl (at the bottom).
The most commonly used interfaces usually are also present on MDN incl. contracts, e.g. nsILocalFile.