Next we navigate to " Security > SSL certificate and key management > Key stores and certificates > CellDefaultTrustStore > Signer certificates > Retrieve from port": We connect a WAS admin console to BPM's deployment manager. This is effectively the inverse of the step we just performed where we imported BPM's signer certificate into Monitor. We need to import the signer certificate into BPM that is used by Business Monitor.The result is a new signer certificate contained within the Business Monitor definition. We click the "Retrieve signer information" button and then "OK" to commit. We call our new signer certificate retrieved from BPM "bpm_signer". In our example it is on localhost at SOAP port 8879. Now we enter the details of the location of the BPM server Deployment Manager. We attach a WAS admin console to Monitor and navigate to " Security > SSL certificate and key management > Key stores and certificates > NodeDefaultTrustStore > Signer certificates > Retrieve from port"
This is essential in a secured environment. This allows Monitor to trust that SSL requests initiated from BPM are valid. We need to import into Business Monitor the SSL certificate that is being used by BPM.We will take great care to call out very explicitly the environment upon which the step is being performed. Because both environments are WAS based, we can get confused very quickly on which environment a command or step is being performed. One is a BPM environment and the other is a Business Monitor environment. We will assume that we have two environments. There is a recipe that needs to be followed. As such, we need to configure communication between these two servers for events generated within BPM to make their way to Business Monitor for consumption and processing. IBM BPM 8.5.5 and Business Monitor 8.5.5 must exist in separate WAS cells. This means that from time to time, the DEF Receiver must tell the DEF Sender what it wants to receive. If we follow our story carefully, we see that the DEF Sender needs to know which events the DEF Receiver is interested in receiving. In this model of the world, the DEF Sender and the DEF Receiver are in communication with each other. When the events arrive at the DEF Receiver, they are made available to the consumer (Monitor). This "knows" what events the "DEF Receiver" is interested in receiving and filters the available events such that only those of interest are actually transmitted over the network. The source of the events (BPM) makes all its events available to the DEF Sender. If we think of DEF as two distinct logical parts, we have an event originator part and an event receiver part. From the perspective of a system that is the origination of events, it should not send any events other than those that are desired to be received. The core concept behind DEF is that Monitor knows what kinds of events it wishes to receive and there is no point in anyone sending in events other than those. With the arrival of Monitor 8.5.5, the old Common Event Infrastructure (CEI) technology has been deprecated and replaced with a new story called the "Dynamic Event Framework" or DEF.
We will discuss the new v8.5.5 mechanism only. Prior to Monitor v8.5.5 there was an old mechanism and at 8.5.5 and beyond there is a new mechanism. One of the primary considerations for using IBM Business Monitor is to receive events from an instance of IBM BPM.