it took me a while to realise that PFS is NOT a UI in its own right; it merely aggregates processes from other BPMs into one single Process Portal.
However, YOU need to provide that Process Portal :-)
So, in my limited test rig here, I have four VMs: -
BPM 8.5.5 This is my source environment, from which I am migrating, which has running instances which I need to drain down over time
BPM 8.5.7 This is my target environment, to which I am NOW going to send my users, upon which they will run new instances AND access their old instances
PFS This is running the ElasticSearch engine etc.
DB2 With three instances; db2inst1 (BPM 8.5.5), db2inst2 (BPM 8.5.7) and db2inst3 (PFS)
Interestingly, PFS is a WebSphere Liberty-based runtime, which is nice.
Each of the BPM servers also has a local instance of IBM HTTP Server, which helps me simplify things.
Five key things I've learned: -
- BPM 8.5.7 becomes the target UI; effectively PFS is "feeding" tasks from the BPM 8.5.5 box AND the BPM 8.5.7 box into the same Process Portal
- The two BPMs *and* PFS need to either share a common user-registry e.g. LDAP, or the users need to exist ( with identical IDs and passwords ) in all three systems
- SSL between the three components is important; this requires the exchange of self-signed certificates unless we're using CA-signed ( which I'm not in this particular PoC )
- LTPA keys need to be exchanged between all three components; I generated a LTPA key on the BPM 8.5.5 box, and then shared it with the other two
- Cross-Origin Resource Sharing (CORS) and XML HTTP Request (XHR) are now things I never knew I need to know - this is all related to the fact that the BPM 8.5.7 Process Portal is providing me with a list of tasks from BOTH BPMs, and has to generate URLs that relate to both
- Similarly, Apache mod_headers and the Access-Control-Allow-Origin header are also my new BFFs
This is fun ….
No comments:
Post a Comment