SAP IDM: How to change the repository type of a repo job

admin KnowHow & Samples

When implementing repository jobs, SAP seems to have forgotten a functionality to change the repository type linked to a repository job. The field has been greyed out in Eclipse even when you are in edit mode.

So how to cope with this? Re-creating all the repo jobs you have set up for e.g. ABAP Load Balanced Connections for the ABAP Dedicated Server connection? A bit much effort. Also when replacing the SAP Repo type by your own you might not want to run through creation again.

So the answer lies – as often – inside the database. The repo type is mapped inside the mc_jobs table and is determined by two columns, mcRepositoryTypeQN and mcRepositoryTypeId.

Example

update mc_jobs set mcRepositoryTypeQN ='customer.idm.connector.abap:reptype.ABAPLoadBalancedConnection',
mcRepositoryTypeId = 11 where jobid = 1234

The above statement will update job number 1234 to another repo type.

How to get the proper values for mcRepositoryTypeQN and mcRepositoryTypeId?

Well the easiest is to just create a new job for the other repo type, get the job number from Eclipse and then

select mcRepositoryTypeQN,mcRepositoryTypeId = 11 from mc_jobs where jobid = 2345

Happy IDM programming.

SAP IDM provisioning queue

admin KnowHow & Samples

Looking at the provisioning queue within SAP Identity Managment you might find our e.g.:

select count(*) from mxp_provision

15693

But what to do now with this absolute number. Several blogs and tutorials are covering the different states and potential resolving of issues but the main information required is: Do I have an issue right at this time? For that purpose it makes sense to combine provisioning with the state and also with the information whether the repository being considered in provisioning is active at all. Especially larger customers who are undergoing maintenance cycles on several systems are likely to be affected by this.

Joining states with active repositories and provisioning queue the following query might come up handy:

select state.name, rep.rep_name, prov.* from mxp_provision prov inner join mxp_state state on prov.state = state.statid inner join mc_repository rep on rep.rep_id = prov.repositoryid  where rep.rep_disabled = 0 order by state desc

The entries returned are those which might need some deeper inspection, sorted by highest state.

Jira configuration for SSL

admin KnowHow & Samples

The documentation for hosting Jira yourself is quite good concerning the keystore.

But for howto use the keystore within the Tomcat connector there are two things to concern:

Firstly, the java keystore shall be made available for the jira user (do not use root) and secondly the server.xml template file does not cover all necessary settings. Mine looks like this on CentOS:

<Connector port="8443" maxHttpHeaderSize="8192" SSLEnabled="true"
relaxedPathChars="[]|" relaxedQueryChars="[]|{}^&#x5c;&#x60;&quot;&lt;&gt;"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true" useBodyEncodingForURI="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="/home/jira/.keystore" keystorePass="changeit"
ciphers="TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" />

Permissions: orglevels for SAP EWM

admin News

It seems as if developers from SAP had been forgetting two orgvalues when establishing the authorization concept for SAP EWM.

I recommend defining the following two permission values as orglevels:

/SCWM/ORG and APO_LOC

This is achieved by report PFCG_ORGFIELD_CREATE

As a result, within all dependent roles, the values can be maintained via the orglevel popup and thus a proper role derivation shall be possible.

Side effects of SAP Note 2399477

admin News

With SAP note 2399477 and related notes, the ITS handler CL_HTTP_EXT_ITS is getting a facelift. But another thing that has been added is a correlation of the parameter sap-theme within the URI with ~theme parameter, well known from the ITS world. If you are embedding an IAC service e.g. inside a portal or calling the service directly with a link in the format of /…/IAC?sap-theme=xxx then XXX is the new ~theme the IAC will peek for when accessing it. Therefore if you have set things like ~theme=99 inside the IAC control file, the service will throw a RABAX.

My workaround was to not use ~sap-theme anymore and live with the impact on portal styles not being applied to the IAC.

Tame the beast – How to increase the performance of Seneca’s Z-GPRS3

admin News

The Z-GPRS3, made and distributed by the Italian Seneca company, is a state-of-the-art logging and control device which has the possibility to report via a GPRS interface. Reporting is based on modern technology which means for communications that the report shown in the browser window will update periodically without refreshing the entire webpage. The technology behind that is provided by a library called jQuery

When looking at the reports via internet we were observing quite a long initial load time. After that time of up to 3 minutes, the reports would function perfectly well without any further waiting required.

This made us look at the web trace within a conventional web browser. As you can see by the screenshot, there are three large files being loaded before the requests will begin. The loading is quite time consuming.

The three files are static files which might only change when the firmware of the Z-GPRS3 would be updated. So, our first thought was what about if we put these three files onto another server (with a better connection) and just load them before loading the constant figures for the reports.

By the first attempt, we had failed for what is called the same origin policy – for security reasons, the data has to come from the same server as from where the script is being loaded.

What to do now? One option is to upgrade the connection for Seneca to something like LTE. For us, this would have had the drawback of consuming more energy in a solar-powered, autonomous environment.

The other way is to connect the Seneca device via an intermediate server which will control loading from different sources. We have decided to run an Apache Webserver in reverse proxy mode so that all requests from the client will be routed via that web server to the Seneca device. Up to that part, the architecture has not been changing much.


But as soon as there is a server in between, it is possible to alter the means of loading for specific addresses.
So what we have done is to place the files in question to a publicly accessible directory on a public webserver and to tell the intermediate apache server to redirect the loading of these files from another directory on the same (! Important) server.

Coming that way, requests for these large files will never hit back to the Seneca device, but the requests for the individual measurements will be routed to the GPRS device every time.

Happy measuring!